Can an identity exist without being referenced by another identity? How would we know?
That might seem a bit philosophical for a security tech article, but it is an important point to keep in mind when tackling the subject of non-human identities. A better question around security would actually be, "Should an identity exist if it can not be interacted with?" While we might not be able to reach the answer to that first question, as proving the nature of reality is a little out of scope for us at GitGuardian. However, we have been hard at work building the NHI Governance tools to determine if a machine identity exists, why it exists, and answer the question of whether it should exist.
GitGuardian recently introduced Non-Human Identity (NHI) Security, our new product strategy built on two core pillars: Secrets Security and NHI Governance. We are proud to have helped so many long-time customers improve their secrets management maturity using our secrets detection and remediation platform, but working with so many different organizations has made us realize that without a wider, more contextual understanding of why and how these secrets are used, managed, stored, and rotated, we can only be reactive. The future of eliminating secrets sprawl means getting a handle on the lifecycles and interdependencies of the non-human identities that rely on secrets.
With this recent news, it is a good time to step back and re-examine some of our assumptions about NHIs and their existence.
What are Non-Human Identities?
Before we proceed, let's define NHI in the context of this conversation.
In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.
This could be a Kubernetes pod that needs to interact with a data source and send the processed data to a reporting system. This could be an Internet of Things (IoT) sensor feeding data to a central server. This could be a Slack-based chatbot. If no human input is directly needed after the initial creation for the entity to get work done, then we should consider that identity 'non-human.'
The one thing all these examples have in common is that they interact with another system. If we want them to communicate with the entire world, that is easy, as we simply point to the other non-human identities and programmatically describe how they should interact. However, we most likely want these systems to communicate securely, only authorizing specific identities under specific circumstances. This has driven the evolution of secrets for access management, from simple username/password pairs to API keys to certificates.
Admittedly, that is a broad definition of NHI. However, we can narrow down what we care about with machine identities by stepping back and considering how these entities relate to one another through the lens of their secrets, allowing access and communication.
All NHIs connect to other systems
Can you build a stand-alone application that does not take in any input, produce any output, and has no addressable interface? Does such an application exist outside of a thought experiment? While fun to think about, the reality is that all NHIs we care about exist to communicate with other identities.
NHIs inherently require connections to other systems and services to fulfill their purpose. This interconnectivity means every NHI becomes a node in a web of interdependencies. From an NHI governance perspective, this necessitates maintaining an accurate and dynamic inventory of these connections to manage the associated risks. For example, if a single NHI is compromised, what does it connect to, and what would an attacker be able to access to laterally move into?
Proper NHI governance must include tools to map and monitor these relationships. While there are many ways to go about this manually, what we actually want is an automated way to tell what is connected to what, what is used for what, and by whom. When thinking in terms of securing our systems, we can leverage another important fact about all NHIs in a secured application to build that map, they all, necessarily, have secrets.
All secure NHIs must have a secret
In order to establish trusted communication between any two NHIs, a unique secret, such as an API key, token, or certificate, must exist for those entities to authenticate. We can use the secret to prove an NHI's identity and map it in the ecosystem. The question becomes, where do we look for these secrets?
In the modern enterprise, especially larger ones, there are essentially only two places a secret can live. Your first option is the best practice and safest option: a secrets management system, such as CyberArk's Conjur, Vault by HashiCorp, or AWS Secrets Manager. The other option is much less secure but unfortunately all too common: outside of a vault, in code or configuration in plaintext.
Enterprise secrets management platforms, often referred to as vaults, are critical for storing and protecting secrets used by NHIs. Vaults can provide a single source of truth for all secrets, ensuring they are encrypted at rest, tightly access-controlled, and monitored for unauthorized access attempts. This assumes you have standardized on a single enterprise secret management platform. Most organizations actually have many vaults in use at the same time, making synchronization between all vaults an additional challenge.
GitGuardian has long been known for finding secrets in your codebase, project coordination platforms like Jira, and messaging systems like Slack and Teams. With our NHI Security launch, we can now tell you where all your secrets are, inside or outside your vaults. This means we can map all your machine identities based on the existence of these secrets.
For enterprises with multiple secret management solutions in place, we can also show which vaults do and do not contain a secret and help you reduce the overhead of storing the same key redundantly across several vaults.
All NHI secrets have an origin story
Machines can't grant themselves permissions and access. Every machine identity was created by or represents a human identity. Governance of NHIs must include secret creation tracking to ensure every secret is traceable to its origin, securely distributed, and linked to a legitimate identity. While this aspect could be accounted for with the proper use of a secret management platform, our data keeps telling us that a certain percentage of secrets leak year after year because we are not consistently using these vault solutions.
We know from years of experience helping teams remediate incidents that the creator of a secret will almost always be the person who first introduces the credential into an ecosystem. We can also tell from the code history or other system timestamp information when this was first seen, which is the most probable time for it to be created or at least come into existence in a meaningful way.
GitGuardian can help fill in this critical detail that might never have been properly logged or documented anywhere else. Once we understand who created a secret to be able to leverage an NHI, then we truly understand the beginning of our NHI lifecycle.
All NHI secrets must grant some set of permissions
When created, every NHI secret must be granted a certain set of permissions. The scope determines what actions an identity can perform and on which systems. This makes permission scoping and enforcement crucial components of governance.
Essentially, two risks make understanding the scope of a secret critical for enterprise security. First is that misconfigured or over-privileged secrets can inadvertently grant access to sensitive data or critical systems, significantly increasing the attack surface. Imagine accidentally giving write privileges to a system that can access your customer's PII. That is a ticking clock waiting for a threat actor to find and exploit it.
Also, just as troubling is that when a secret is leaked or compromised, a team can not replace it until they first understand how those permissions were configured. For example, suppose you know a mission-critical microservice's secret was accidentally pushed to a public GitHub repo. In that case, it is only a matter of time before it will be discovered and used by someone outside of your organization. In our recent Voice of the Practitioner report, IT decision-makers admitted it took, on average, 27 days to rotate these critical secrets. Teams should be able to act in seconds or minutes, not days.
This is why GitGuardian is developing our new Secrets Analyzer. This new feature offers additional context on detected secrets, including their roles and permissions. Rapidly understanding what assets are exposed when a leak occurs and what potential damage can be inflicted by a threat actor goes a long way when responding to an incident. Knowing exactly how to replace it from a dashboard view or API call can mean the difference between a breach and a frustrated attacker finding the key they have is invalid.
All NHI secrets need to be rotated
A machine identity can, and likely should, have many secrets in its lifetime. If credentials are left to live for months or years, or in the worst case, forever, NHI secrets exposure or compromise becomes increasingly likely. Manual rotation is error-prone and operationally taxing, particularly in environments with thousands of NHIs. Automating the secret rotation process is a cornerstone of NHI governance, ensuring that secrets are refreshed before they expire or are leaked.
For any of the secrets in your vaults, rotation should be a simple matter of scripting. Most secret management platforms provide scripts or some other mechanism to handle the delicate dance of safely replacing and revoking the old secret.
But what about the NHI secrets that live outside of these vaults, or perhaps the same secret that is spread across multiple vaults? GitGuardian's integration with these vaults means that your team can more easily find and safely store these secrets in the secrets manager and prepare the way for automated rotation. Our reference implementation with CyberArk's Conjur goes into more detail on how we can fully automate the entire storage and rotation process.
By identifying all the NHIs and knowing when they were created, we can also predict when they need to be rotated. While every team will judge exactly how long each secret should live, any secrets that have never been rotated after creation are ripe to be replaced. Any secret older than a year, or for some mission-critical systems, a few days should also be prioritized for rotation asap.
All NHIs will have an end-of-life
NHIs, like their human counterparts, have finite lifecycles. They may be decommissioned when a service is retired, replaced, or no longer needed. Without addressing the deactivation and cleanup of NHIs to prevent the persistence of unused secrets or stale connections, we are creating security blind spots. But how do we know when we are at the end of the road for an NHI, especially if its secret remains valid?
One answer is that it should no longer exist when an NHI no longer connects to another active system. This ensures attackers cannot exploit defunct NHI secrets to gain a foothold in your environment. Remember that attackers do not care how a secret should be appropriately used; they only care about what they can do with it.
By mapping all the relationships an NHI's secrets allow, GitGuardian's NHI Security can quickly identify when a system is no longer connected to any other identity. Once there are no more ways for an identity to communicate, then it and its secrets should no longer exist. It also means the secret no longer needs to be stored in your secrets managers, giving you one less thing to store and manage.
Understanding the world around your NHIs is critical to security
In 2022, CyberArk's research showed that for every human identity in an environment, at least 45 non-human identities need to be managed. That ratio today is likely closer to 1 to 100 and is ever-increasing. The best time to come to terms with your NHI governance and lifecycle management was years ago. The next best time is right now.
GitGuardian's full-cycle approach to non-human identity security can help you quickly map out not just where your NHI secrets are but, just as importantly, what other NHIs are connected. We can help you implement NHI governance at scale, working from our secrets security approach. Finding and properly storing your secrets is just the beginning of the story. GitGuardian will also show you the scope of your secrets, their age, who implemented them, and other contextual information, such as when they should be rotated.
We would be happy to work with you to map the next steps on your NHI security journey. Even though machine identities outnumber human beings, there is no reason to work alone to solve this problem; we are all in it together.
Read more about NHI Security in these blog articles:
Dwayne McDaniel
Dwayne McDaniel
