Back

How to Close the Service Account Security Gap in GCP and Snowflake

Many security and IT teams are concerned about a substantial security gap in their data warehouses such as GCP’s BigQuery and Snowflake.

By now they understand that there are probably hundreds, if not thousands, of service accounts that are currently connecting their data warehouses to other cloud-services. Some of them are third-party cloud services, which may not be necessarily trustworthy.

These service accounts, which are essentially very powerful credentials, are usually created by employees like data analysts and DevOps practitioners in order to increase process automation and interconnectivity between systems. However, these app-to-app connections are created and granted powerful permissions under the radar of the security teams, and often increase organizations’ attack surface. 

So what is exactly this attack surface and how can you minimize it with the help of Astrix? 

Let’s start from the basics.

What are service accounts? 

We are all familiar with the concept of user accounts. These accounts are specific to individuals, and allow us to sign in using our own credentials or identities to computers, networks, applications and services. There is a wide range of identity platforms out there that organizations can use to help them manage their user accounts – Okta and Duo being two noteworthy examples.

Similar to humans having user accounts, services and applications can have service accounts. These accounts are designed to complete tasks on behalf of a particular application or automated service – without human involvement. As such, service accounts are a popular tool for connecting core systems to each other and to third-party applications.

Consider the following common use cases:

  • A data engineer creates a service account and uses it to connect the organization’s database to a third-party data transformation tool, such as Fivetran or dbt, giving it access to read and modify data. 
  • A business analyst creates a service account and uses it to connect to some third-party BI platform, such as Tableau or Power BI, giving it access to read sensitive data.
  • A DevOps engineer uses a service account to connect the company’s database to an internally created automated backup service, giving the service account full read access to the database.

Each of the above examples involves creating a service account and granting it sensitive permissions. This service account is then handed over to an application or service, either internal or external, that then uses the service account to access the database.

What makes service accounts an attractive attack target? 

Many service accounts require high exposure permissions, granting them access to read and modify sensitive data, and oftentimes even change configurations in your environment. These powerful credentials make these accounts a popular target of attacks; a single leaked service account can give a malicious actor access to vast resources, thus having catastrophic consequences for an organization. 

While most companies have become quite competent at managing their user accounts, the increasing use of service accounts introduces some unique challenges that security practitioners often struggle to cope with. 

How big is the attack surface?

Considering the increasing number of cloud applications and services that companies use nowadays (a large enterprise uses on average 1,400), the number of service accounts in an organization can easily match or even exceed the number of user accounts. In fact, in typical cloud-first customers we see up to 5 times more service accounts than human accounts. This fact emphasizes the importance of proper visibility and management of service accounts.

What are the cyber risks posed by service accounts?

Service accounts, just like OAuth and API keys, provide programmable access to your organization’s most critical systems. Improperly secured app-to-app connections massively increase the likelihood of supply chain attacks, data breaches, and compliance violations.

The recent attacks listed below reveal a new generation of supply chain attacks, in which attackers take advantage of the access granted to third-party cloud services as a backdoor into the companies’ most sensitive core systems. 

  1. Microsoft’s OAuth breach (Sep 22, 2022): Malicious OAuth applications were deployed on compromised cloud tenants and then used to control exchange servers and spread spam (Read more).
  2. GitHub OAuth breach (April 28, 2022): Attacker Breaches ‘Dozens’ of GitHub Repos Using Stolen OAuth Tokens (Read More).
  3. Mailchimp breach (April 4, 2022): Hundreds of customer accounts were compromised using stolen API keys (Read More).   

How can Astrix help?

Our researchers at Astrix put their minds to this very problem, and developed engines that help you keep your service accounts in check.

Astrix helps security teams take control of their tangled web of service accounts, by answering each of the following key questions: 

1. Which of these hundreds of service accounts belong to humans, and which of them are actually service accounts? In certain platforms, like Snowflake, user accounts and service accounts “look” exactly the same. Distinguishing between the two is crucial, since these are very different “creatures” that call for different management methods and security practices.

Astrix automatically distinguished between user accounts and service accounts in Snowflake. Distinguishing between the two types of accounts is crucial, since they are very different “creatures” that call for different management methods and security practices.

2. Which of these accounts are in use, and which are no longer needed? Many service accounts are created to address specific and timely needs, such as a POC or a trial, but remain connected even after they are no longer necessary and needlessly expand the attack surface.

3. Which of these service accounts are used by third-party cloud services, and which are used by an internal system? Consider a DevOps engineer creating an automated process that uses a service account to backup your database, and write the backups to some internal storage bucket. This service account is not as exposed to supply chain attacks as one that is handed over to a third-party service, and the two should be treated differently.

4. Which third-party cloud service uses this service account? Can the vendor behind this service be trusted?

About Astrix 

From Salesforce and Office 365 to GitHub,  and Snowflake, Astrix security platform ensures your XaaS core systems securely connect to third-party cloud services. Astrix’s agentless, easy-to-deploy solution provides you with holistic visibility into all app-to-app connections and automatically detects and remediates over-privileged, unnecessary, and malicious integrations exposing you to supply chain attacks, data leakage, and compliance violations.

Learn more at www.astrix.security

 

Request a demo

See how Astrix can help you take
control of your third-party integrations.



This will close in 0 seconds

Contact us



This will close in 0 seconds

The Ultimate Guide to Securing App-to-App Integrations

How to discover and remediate over-privileged, unnecessary, and malicious integrations to your most critical systems.

This will close in 0 seconds

Risk #3: Compliance violations
  • What it is: An act that compromises an organization’s ability to comply with relevant governmental, legal, or industry frameworks – for example, data privacy regulations (like GDPR) or security and governance (like SOC 2).
  • Recent example: Ticketmaster received a $1.6 million fine for GDPR violations after hackers exploited vulnerabilities in the code of a third-party chat app vendor on its checkout page, exposing customers’ personal and payment data.
  • Why third-party integrations increase the risk: Any third-party application involved in data processing is part of an enterprise’s regulatory purview – meaning that the organization is ultimately responsible (often financially and legally) for its handling of sensitive data.
Risk #2: Direct malicious access
  • What it is: Malicious actors seek direct access to core platforms by tricking users into providing consent (via OAuth permissions rather than explicit credential phishing) or by taking advantage of leaked API keys, certificates, webhooks urls, etc.
  • Recent example: Microsoft recently warned of a phishing attack in which Office 365 users received emails intended to trick them into granting OAuth permissions to a fake app.
  • Why third-party integrations increase the risk: With third-party applications increasingly integrated to core platforms, access tokens enable malicious actors access to data and operations on organization critical systems.
Risk #1: Supply chain attacks
  • What it is: A third-party app integrated to a trustworthy central platform may “leak” sensitive data into a less secure environment. Malicious actors abuse security vulnerabilities associated with a legitimate (but less secure) third-party application – and exploit its privileged access to sensitive information (like credentials or data).
  • Recent example: Hackers compromised the software development tool Codecov to gain access to – and rapidly copy and export to an attacker-controlled server – sensitive secrets,credentials and IP associated with software accounts at thousands of clients.
  • Why third-party integrations increase the risk: More and more third-party applications hold the “keys to the kingdom”: the most privileged credentials in the enterprise. Any third party application that can be compromised opens up the possibility of unauthorized intrusion (and data extraction, ransoming, and more) by malicious actors.