Part 1: Non-Human Identity Security – The Complete Technical Guide

Originally published by Astrix.

Written by Michael Silva, Danielle Guetta, and Tal Skverer.

“Identity is the new perimeter.” This catch phrase is present in almost every website of identity security vendors, and for a good reason. Human access, more commonly referred to as user access, is an established security program in most organizations – big or small. The realization that user identities and login credentials need to be vigorously protected with IAM policies and security tools like MFA or IP restrictions or via SSO happened long ago. However, when it comes to non-human access like API keys, OAuth tokens, service accounts, secrets and other programmable access credentials, the situation is very different. Lack of visibility, monitoring and governance to this permissive access is everywhere, and attackers have figured it out.

In this guide, we will deep dive into the non-human identities attack surface, how it’s created, how attackers exploit it, and what steps you can take to minimize your exposure now.

What are non-human identities and why they’re your biggest blindspot

These days, every employee delegates access to external entities to automate tasks and increase efficiency. This sprawl of third party non-human access to core systems like Salesforce, GitHub and Microsoft365 via service accounts, OAuth tokens and API keys creates a mostly ungoverned attack surface. Astrix has found that for every 1,000 users, companies typically have 10,000 non-human connections.

To make matters even more complicated, R&D teams regularly create secrets that connect internal services and resources to, for lack of better phrasing, “make stuff work”. These secrets are scattered all over different secret managers, with zero security visibility and context, and are usually over-permissive and abused by different services.

These together create a true wild west of ungoverned machine credentials that allow access to your crown jewels – from customer information and financial data to source code and production environments. Recent attacks on Okta, Slack and Microsoft prove that this threat is anything but theoretical.

Think about the following questions: How many third-party vendors can access your critical systems like AWS, Salesforce, or Office 365? How much control do these connections grant third party app vendors over business critical assets and data? Can you track an exposed secret and quickly rotate it?

The issue lies in the fact that tokens, secrets and other machine credentials do not benefit from the robust security measures extended to user identities, and, to make matters worse, they may have no expiration and are generally over-permissive. While expiration and proper scoping can alleviate some of this, the lack of human security measures such as MFA (multi-factor authentication) is still missing. Consequently, if a token is compromised, it provides an unrestricted access pass to attackers, which can remain virtually undetectable.

Threat actors, like all humans, look for the path of least resistance, and it seems that in 2023 this path was non-user access credentials (API keys, tokens, service accounts and secrets). These programmable access credentials are used to connect apps and resources to other cloud services, and what makes them a true hacker’s dream is that they have no security measures like user credentials do (MFA, SSO or other IAM policies). To make matters worse, these credentials are also often over-permissive, ungoverned, and never-revoked.

How did we get here?

Does the below screen look familiar?

This screen that you’re probably very familiar with is called the ‘consent screen’, and it brings us to one of the drivers to the non-human access issue – consent fatigue. Just like the days of “Next, Next, Next..” in Windows applications setup, end users have become accustomed to these prompts. Without a second thought on the permissions being granted, users allow access to third party apps in order to achieve a business need. Like with most technology movements to make business environments more agile, new security problems arise.

Turning end users into citizen developers and allowing them to integrate applications using the low-code/no-code models leads to the spread of connections, and consequently – ungoverned non-human access.

Access permissions are not always what they seem

Non-human access is usually extremely over-permissive. In fact, Astrix Research found that 23% of apps connected to Google Workspace environments have very wide access permissions (read, write, delete) to the organization’s most sensitive data (emails, documents and spreadsheets). In GitHub the numbers reach 25%. One of the reasons for that is that as an end user, even a security aware one, it can be very difficult to ascertain what are the permissions an application or tool is truly receiving. More often than not, the names of roles and permissions in these prompts can be misleading, which causes overscoped permissions.

In the example above, the permissions the app is requesting seem pretty straight forward. In reality, the app is actually being granted full access to a GCP account, even though it doesn’t phrase it that way; “View and manage customer related information”, what information? What is considered customer related? All of this can be very confusing for those granting the access. This access could be vague even for some technical users, so imagine the difficulty of non-technical business users to decipher what apps are truly asking for.

Security teams have little to no control over this process. You could decide to restrict end users from adding third party integrations altogether (if the platform even allows for restriction), or opt in for manual processes to try and keep up with new non-human connections. However, it’s pretty clear that with cloud speed and automation – none of these are a good enough option. In this digital age, it should never be the intention of security practices to deliberately slow down business agility and progress.

How programmable access works: OAuth apps

To truly understand the non-human access attack surface, we need to first understand how these access credentials work. A great place to start is a very common type of non-human access credential – OAuth apps.

When an OAuth app connects to another application, the user grants permission through a consent screen (much like the one we saw at the beginning of this article). After consent, the connected application issues an authorization code, which the OAuth app exchanges for an access token. This token acts as a secure credential, allowing the OAuth app to access specific resources or perform authorized actions within the connected application, on behalf of the user. It’s important to note that there is no usage restriction within this type of connection, and the credential can be used by the application’s owner at any time.

The issue here, like other third-party access tokens, is that you have no control over storing, securing or rotating these credentials. In the case of OAuth apps, they typically do not directly utilize a customer’s vault to store access tokens. Instead, to safeguard access tokens OAuth relies on secure token transmission and storage practices of the application’s owner.

When a vault is employed, it’s usually managed by the platform or application, not the consumer. This puts the vault beyond the control of your company, limiting your security teams’ ability to manage the vault’s posture, key rotation, and key usage visibility.

Access tokens rarely get offboarded

As mentioned at the beginning of this article, our observations show that a company with 1,000 employees typically has around 10,000 non-human identity connections. Each of these connections uses tokens, keys, and other authentication credentials to get access to what it needs to operate. While some tokens are directly tied to users and are removed with user deletion, the majority don’t go through any offboarding. In fact, our research shows that 50% of the active access tokens connecting Salesforce and third-party apps are unused. In GitHub and GCP the numbers reach 33%.

Orphaned tokens, lingering after the removal of the user account, pose huge risks due to their lack of visibility, documentation, and the difficulty in removal. Balancing the need to eliminate orphaned tokens without breaking anything is a delicate game that requires deep visibility as well as both risk and business context – all of which are very hard to achieve using existing security solutions or manual processes.

Coming next: Deep dives

In the next parts of this series we will dive even deeper into how non-human access credentials work and how to protect yourself from supply chain attacks.