What Are Non-Human Identities and Why Do They Matter?

A look at the explosion of Non-Human Identities in the Digital Landscape and the role they play in modern attack surfaces

Welcome to Resilient Cyber!

If you’re interested in FREE content around AppSec, DevSecOps, Software Supply Chain and more, be sure to hit the “Subscribe” button below.

Join 5,000+ other readers ensuring a more secure digital ecosystem.

If you’re interested in Vulnerability Management, you can check out my book “Effective Vulnerability Management: Managing Risk in the Vulnerable Digital Ecosystem” on Amazon. It is focused on infusing efficiency into risk mitigation practices by optimizing resource use with the latest best practices in vulnerability management.

---

There are a lot of sayings in cybersecurity that are used to emphasize the importance of Identity and Access Management (IAM).

This includes quips such as “identity is the new perimeter” or “hackers don’t hack in, they log in”.

These phrases have taken hold among experts due to the fact that reputable sources such as the Verizon Data Breach Investigations Report (DBIR) routine report compromised credentials as a core attack vector of incidents and data breaches, as well as the industry-wide push towards zero trust and the dissolution of the legacy network perimeter model in cybersecurity. 

The image below from the latest DBIR for example demonstrates that credentials still play twice as much of a role in security breaches as their closest competitors.

That said, while it is common to have discussions and focus in the industry around securing usernames and passwords and traditional identities associated with human users, the less discussed aspect of the identity landscape is what is commonly referred to as “Non-Human Identities” or “NHI’s”.

But what exactly are NHI’s and why should we even be discussing them?

When thinking about credentials as a core part of the modern attack landscape, NHI’s have an outsized footprint compared to human credentials. Some organizations have found that for every 1,000 human users, companies have 10,000 non-human connections/credentials, or even 10-50x the number of human identities in the organization. 

NHI’s may include identity types such as service accounts, system accounts, IAM roles, and other machine-based identities used to facilitate activities in the enterprise with authentication activities oriented around API keys, tokens, certificates and secrets.

We also know that secrets continue to be a rapidly growing challenge in the age of cloud-native environments and methodologies, with millions of secrets being detected in scans of public GitHub repositories and thousands of secrets being exposed in data breaches, such as that of Samsung.

This explosion in NHI’s has been led by factors such as the push towards microservices, Kubernetes clusters and containers, cloud-integrations and automations and the proliferation of third-party SaaS services organizations are consuming.  

Each of these identity types has their own unique way of facilitating and governing the use of NHI’s for machine-to-machine access and authentication. Not only are the NHI’s vast in number but their governance is even more complicated, as they exist across the entire enterprise, among different tools, services, environments and more, all often with security having limited visibility and control over their secure use or throughout their identity lifecycle.

The importance of securing NHI’s isn’t lost on CISO’s and security leaders either. Investment firm Felicis published their survey of over 40 leading industry CISO’s and found that the most cited top pain point that needed a satisfactory solution was NHI’s. This helps demonstrate that security leaders are looking to address securing NHI’s and realize many of them have gaps in their identity security stack for addressing this emerging risk. 

Securing machine identities is also emphasized in NIST’s foundational Zero Trust publication 800-27 “Zero Trust Architecture”. In the publication NIST discusses the importance of securing NHI’s, especially since they often have special privileges and are acting on behalf of developers and system administrators. 

When we think about traditional activities associated with human credentials and identities such as provisioning, least-permissive access control, scoping, decommissioning and robust security measures such as MFA are all exponentially more challenging due to both the scale and opaqueness of NHI’s in the enterprise, and beyond, as we also account for third-parties such as external service providers, partners, environments and more.

Developers, Engineers and End Users across the organization and broader ecosystem are often creating these NHI’s and granting access without a deep understanding of the implications for these long-lived credentials, their access, their potential exploitation by malicious actors and all without the governance or involvement of security teams. 

The implications of this is manifesting in massively overly permissive identities, some with some cloud-native security companies finding that only 2% of granted permissions are actually used. That means there is a massive sprawl of ungoverned, often unsecured identities with far more access and permissions than needed sitting right for exploitation and abuse by attackers.

NHI’s are a core part of enabling activities, workflows and tasks in enterprise environments, often using widely pervasive and popular software and services such as Google, GitHub, Salesforce, Microsoft 365/Azure AD, Slack and more. 

These widely used SaaS services are often integrated with one another to facilitate everything from email, communications, software development and other routine and foundational digital business activities.

A lot of the machine-based programmable access is facilitated by a popular online authorization standard known as Open Authorization, or OAuth for short.

It can be used to facilitate delegated access for various client types such as browser-based applications, mobile applications, connected devices and more. OAuth utilizes access tokens which are pieces of data used to represent the authorization to access resources on behalf of end users in the enterprise or beyond. OAuth uses core components to facilitate this activity including resource servers and owners, authorization servers, and clients.

The visualization below demonstrates a basic OAuth Flow:

Source: Astrix Security

As mentioned in the source above, what makes the use of OAuth potentially problematic is that the consumer, or end user, in this case when it comes to dealing with external services, such as SaaS, have no control over how those OAuth tokens are stored. This is all handled by the external service provider or application speaking the longstanding Shared Responsibility Model (SRM) when discussing cloud security.

This isn’t inherently problematic, except we know that software supply chain attacks are on the rise, a topic I have written extensively on in both the Resilient Cyber Substack, as well as my book, Software Transparency from Wiley, which has a chapter dedicated to Cloud, SaaS and third-party software suppliers.

Attackers have realized it is far more effective to target widely used software suppliers than it is to target a single individual or customer organization. These attacks are not only focusing on widely used open source software components such as Log4j and xz utils, but also the largest software companies in the world, such as Okta, GitHub, and Microsoft. 

The last of which involved nation state hackers abusing Microsoft Office 365 and its use of OAuth. The incident even impacted the U.S. government leading to a Cybersecurity Safety Review Board (CSRB) report which made some damning claims about the security culture at one of the largest software companies on the planet.

In Microsoft’s own guidance for responders when dealing with the nation-state attack they discussed how the APT was “adept at identifying and abusing OAuth applications to move laterally across cloud environments”.

OAuth of course is but one focus in these attacks, as discussed above, attackers are also taking advantage of personal access tokens (PAT)’s, API keys, service accounts, tokens and other forms of secrets which can be used to compromise internal systems and data or target external customers and connections. 

This not only emphasizes the need to secure NHI’s but also for organizations to have a robust SaaS Governance plan in place, due to the fact that when it comes to cloud security most organizations may be using 2-3 IaaS providers but several hundreds of SaaS providers, often not under the purview of internal security teams and with little to no security or rigor in place with regard to the level of access, types of data or visibility into the external SaaS providers should they be impacted from a software supply chain attack.

I’ve written and spoken about SaaS Governance and Security for the last several years, including leading the publication of “SaaS Governance Best Practices for Cloud Customers” from the Cloud Security Alliance (CSA).

The role of NHI’s in material cybersecurity incidents is even making its way into SEC 8-K filings, such as one recently filed by Dropbox, which stated “The actor compromised a service account that was part of Dropbox Sign’s back-end, which is a type of non-human account used to executive applications and run automated services”. 

This shows that NHI’s are not just a buzzword, but an aspect of the modern digital attack surface that is even being utilized in material cybersecurity incidents against publicly traded companies with millions of customers worldwide.

The above discussion demonstrates both how pervasive NHI’s are in the modern enterprise and their increased role as a target for malicious actors. NHI’s are fundamental for the modern digital ecosystem and are used heavily both internally for cloud, development and automation as well as externally to integrate with the robust SaaS ecosystem all organizations now live in.

Without a comprehensive approach to securing NHI’s, CISO’s and security teams may find themselves vulnerable and with a critical gap in their identity security strategy.