Risk related to non-human identities: Believe the hype, reject the FUD

The hype surrounding unmanaged and exposed non-human identities (NHIs), or machine-to-machine credentials – such as service accounts, system accounts, certificates and API keys – has recently skyrocketed. A steady stream of NHI-related breaches is causing some of the chatter surrounding NHI risk to veer into FUD (fear, uncertainty and doubt). Given the rate at which NHis are outnumbering human identities – by some reports by as much as 45-to-1 – the hype seems warranted. The FUD, however, is not.

No doubt, NHIs are a serious risk vector. But it is possible to manage that risk and implement proper governance for doing so over the long term. And, let’s not forget, human identity management has never been a walk in the park: it’s taken decades for IAM tools to mature. Compared to the time it took for companies to get a handle on their human identities, we are way ahead of the curve when it comes to managing machine identities.

That said, the first step in thwarting attacks leveraging non-human identities is to inventory all the identities in your organization, human and non-human. You cannot secure what you cannot see, and in the case of NHIs, this is gospel. Because NHIs are commonly used to access sensitive data and services across applications, allowing exposed, unmanaged NHIs to proliferate is akin to leaving all your doors and windows unlocked when you leave your house. You may as well invite attackers in for a cup of tea.

NHI risk: A “typical” scenario

Consider a developer that connects some third-party (SaaS) integration to your organization’s Github repository, or a productivity tool that’s granted permission to access your Google Drive. In these cases, a new NHI (in the form of an access token) would have been created, which delegates access on behalf of the human user. CISOs will have no knowledge of this.

Now imagine that this third-party provider has a data breach, and these access tokens get stolen. The threat actor may now connect to your Github or Google Drive, on behalf of the employee that granted the access, and leak all your code or documents. Sure, some access tokens are short lived (i.e., valid for several hours or days), but some are not, and CISOs have no control over that. It’s up to the third-party provider (e.g., Github) to decide how long the token is valid for.

Therefore, knowing your exposure once a third-party provider is breached is crucial. You can revoke access for certain users or services, to prevent threat actors from making use of their stolen credentials, but you risk breaking production systems (e.g., revoking Github tokens might break your CI/CD pipelines) and given the sheer number of access tokens in circulation, even the best players might miss one.

Knowing what’s been compromised and revoking these access tokens – all of them, but only them – is key to keeping your organization both safe and functioning. Keeping such an inventory gets exponentially harder, of course, when multiple cloud providers or third-party SaaS are used, as each one may use different authentication mechanisms.

Anomaly detection is key to preventing NHI exploits

The next step after a full and correct inventory is moving to monitor for NHI anomalies in runtime.

For human identities, we already have systems that do this (“John” is connecting from North Korea at 2AM on a Sunday?), but not so much so for NHIs. To keep NHI risk in check, we need systems that can detect NHI anomalies. Otherwise, there is no way to know if they have been compromised.

The fact that this capability is not yet ubiquitous is what makes NHIs such a “prolific” attack vector. Compromised NHIs are hard to detect (the attacker was using the correct credentials, so no events were logged), have a huge blast radius (leaking large volumes of sensitive data easily/silently), and it’s usually a blind spot for security teams. Plus, they are impossible to secure with two-factor authentication, making them ideal targets.

For example, suppose a threat actor has somehow gained access to one of your containers (applications) running in the cloud and extracted an access token that’s used by the app to connect to an S3 bucket. The threat actor may then try to connect to this bucket from outside the organization, to exfiltrate data. Using this access token from the “wrong location” should raise a red alert, and action must be taken to revoke the token immediately.

The same goes for connecting to this S3 bucket from within your organization, but from a different application: each application should be using a private, short-lived access token. To truly and effectively manage NHI risk, companies will need to establish a comprehensive NHI management program that covers the whole NHI lifecycle.

What does that look like? At a high level, the process for doing this is:

1) Creating NHI inventories

2) Rein in NHI and secrets sprawl

3) Baseline identities and roles in cloud environments

4) Continuously monitoring them for anomalies

Whatever tools you use, these are the steps involved with establishing a sustainable protocol for mitigating NHI risk. It is a complex endeavor, but the governance process itself is straightforward enough and the toolsets needed to accomplish this are capable enough that NHI FUD is not warranted.