The Purpose of the Hypersurface Is to Keep Expanding: The Non-Human Identity Explosion
Dropbox was recently hacked and non-human identities were involved. How cyberpunk! Identity in the cloud is extremely complex and can only be managed by modelling with tools. This complexity has contributed to the continued growth of the attack hypersurface.
Dropbox was recently hacked, and non-human identities (NHIs) played a part.
The [malicious] actor compromised a service account that was part of Sign’s back-end, which is a type of non-human account used to execute applications and run automated services. As such, this account had privileges to take a variety of actions within Sign’s production environment. - https://investors.dropbox.com/node/11526/html by way of https://resilientcyber.substack.com/p/what-are-non-human-identities-and
The number of NHIs has exploded and vastly outnumbers human identities.
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. - https://resilientcyber.substack.com/p/what-are-non-human-identities-and
IAM is complex, no doubt about it.
What is Non-Human Identity?
Back in 2012, AWS introduced IAM roles for EC2 instances.
Today we are introducing AWS Identity and Access management (IAM) roles for EC2 instances, a new feature that makes it even easier for you to securely access AWS service APIs from your EC2 instances. You can create an IAM role, assign it a set of permissions, launch EC2 instances with the IAM role, and then AWS access keys with the specified permissions are automatically made available on those EC2 instances. - https://aws.amazon.com/blogs/aws/iam-roles-for-ec2-instances-simplified-secure-access-to-aws-service-apis-from-ec2/
In the old days, before the cloud, we mostly had workloads running in our own data centres, on our own servers, in our own operating systems. There might have been a virtualization system, like VMware or whatever, as a virtualization layer, but that was it. Pre-cloud we had fewer Lego blocks to manage. Maybe we weren't as fast, maybe we weren't safer, but certainly "machine identities" were a lot simpler, if not non-existent.
Back in the day, each OS instance was on its own, and there were only the users that were on that "box"–on that OS instance–and while workloads would run as a user and group, it would be something like "tomcat" and that user and group would have a few permissions based on good read, write, and execute permissions. In this model there is not that many combinations. The diagram is a lot simpler.
As well, traditionally, in Linux, there was no Role Based Access Control (RBAC) or IAM such as what we are used to now and, in fact must use, in the cloud today. Linux does have SELinux available, which can provide RBAC, but it is rarely used, in part because of the underlying complexity and learning curve. Because SELinux is complex to use, and in part because there was no forcing mechanism, we didn't have an explosion of machine identity complexity until the public cloud.
Even when a policy is considered both safe and functional, each addition, deletion or modification of the policy has the potential to break the baseline. The need for analysis tools for SELinux policies has been recognized from almost the very beginning with the expectation that such tools would be the silver bullet for SELinux security administrators. - https://www.site.uottawa.ca/~afelty/dist/mcetech17.pdf
With AWS and other clouds we have IAM, Identity and Access Management, where we can build our own custom roles with specific permissions, and in doing so, it's not just human beings that get those permissions, it's virtual machines or containers or even processes that can have their own identities with their own inherent permissions and access levels and automatically access any required credentials, which can be automated and easily rotated by the underlying infrastructure. This is because the "cloud" is smart enough to know where, for example, an API call is coming from, whether it's originating from an EC2 virtual machine or a Kubernetes workload or what have you.
Today, almost any application or service or virtual machine can have its own identity with its own access to credentials that it can use to perform work on the behalf of the organization running it.
The Major Benefit of NHI: Less Credentials to Manage
One benefit of NHIs is a reduction in credentials to manage–more specifically to rotate. It is a key security practice to be able to rotate all credentials in an automated fashion, but saying is much more difficult than doing because it means being great at automation, which, you know, we aren't.
An example is shown below of storing secrets in the continuous integration (CI) system Jenkins. This pattern is repeated across many tools not just CI systems. This is a huge pain, and a massive security risk.
NHI is powerful because you no longer need to "hardcode" or some how store and manage IAM users' API keys in your workloads. Thus, if there are no "hardcoded" secrets in those workloads, then the secrets don't need to be rotated. The reason there are no secrets is because, effectively, the cloud is able to "authenticate" workloads for you, to provide them identities and credentials based on the fact that the cloud is aware, to some extent, of what is running in it. The downside is that if that workload is "hacked" then whoever broke it may be able to use that NHI to access other systems and data (and this is exactly what happened in the 2024 Dropbox hack).
To Add to the Complexity: Each of the Clouds Has Its Own IAM System and Design
Above I showed the AWS IAM policy flow, and below is Google Clouds. Also quite convoluted.
Few companies utilise only one cloud, so effectively the complexity is multiplied by the number of clouds in use, some of which may have chosen a different IAM model, such as one based on projects.
More Explosions: Predefined Roles
Even when assigning users "small roles", we're still not following the principal of least privilege. Also the roles don't remain static. As new services come online permissions are added to roles - IAM is the Worst - https://matduggan.com/iam-is-the-worst/?utm_source=substack&utm_medium=email
Below are the results for GCP in terms of IAM components. Notice the 1623 predefined roles. Ultimately, because IAM is so complex, the clouds created predefined roles for us so we don't have to make them. But now we need to know which roles to use. Somehow we have to determine which of these 1623 roles–a number that is constantly changing–are the correct roles for a particular project. And how do we know when a role is changed or a new, better, more appropriate role is created?
GCP
Azure
AWS
Based on the Number of Solutions Out There, We Know This Is an Evolving Area
From the meme above, we can see that there are many startups focusing on this area and trying to win business. Few of these companies will succeed, most will be acquired by security and identity incumbents looking to enhance their own offerings with new identity management thinking.
Ultimately, the Cloud, and NHI, Is Too Complicated; The Only Way to Deal with It Is to Model It
The cloud is too complicated for humans to configure safely. The only way to manage the cloud and its millions of options (multiplied by the number of clouds) is to model the work with tools, new tools that we'll have to invent as we learn about the underlying technology, how we want to use it, and the security ramifications therein.
I want to reiterate this quote from the Dropbox SEC filing around their recent hack, specifically the part about the compromised service account, AKA a Non-human Identity or machine identity. (Emphasis added.)
The [malicious] actor compromised a service account that was part of Sign’s back-end, which is a type of non-human account used to execute applications and run automated services. As such, this account had privileges to take a variety of actions within Sign’s production environment. - https://investors.dropbox.com/node/11526/html by way of https://resilientcyber.substack.com/p/what-are-non-human-identities-and
The purpose of the hypersurface is to keep expanding, and it's doing a great job!
Further Reading
Mathew Duggan
Chris Hughes
Darwin Salazar
Xavier Garceau-Aranda
Chris Hughes