Security comes down to trust. In DevOps and in our applications, it really is a question of "should this entity be allowed to do that action?" In an earlier time in IT, we could assume that if something was inside a trusted perimeter, be it in our private network or on a specific machine, then we could assume entities were trustworthy and naturally should be able to access resources and data. However, as applications became more complex, spanning not just machines but also different data centers and continents, and reliance on third-party services via APIs became the norm, we could no longer rely on trusted perimeters.
. The full scope of the NHI trust issue becomes very concerning when you consider the sheer volume involved. According to research from CyberArk, in 2022 the number of and are . In this article, we will take a closer look at achieving zero trust architecture for hour NHIs based on NIST's advice.
Defining zero trust architecture and NHIs
Starting with an agreed-upon definition is always a good idea when contemplating any new approach or term. , the majority of which were for machine identities, the full scope of this problem starts to come into focus.
Adding to the issue is over-permissioned NHIs, which utilize only a fraction of their granted access, greatly expand the attack surface and heighten the risk of privilege escalation. When an attacker does find a leaked secret, they are often able to use it to laterally move throughout your systems and escalate privileges.
Inadequate lifecycle management leaves stale credentials like unused service accounts and outdated certificates vulnerable. This is how the problem of "zombie leaks," when a secret is exposed but not revoked, happens in so many codebases, project management systems, and communication platforms. For example, a commit author may believe that deleting the commit or repository is sufficient, overlooking the crucial revocation step and, therefore not completing the needed end-of-life step for managing an NHI.
What NIST has to say about securing NHIs
NIST publishes many documents with guidance on properly securing credentials, but most of their publications focus on human identities, such as user accounts. They use the term non-person entities (NPE) in some of their work, but across the current enterprise landscape, these are much more commonly called NHI. We will stick with that current naming convention for this article.
Non-human identities security consists of multiple strategies. The following points should be seen as a partial list of recommendations.
Eliminate long-lived credentials
" gives even more pointed advice. When discussing service authentication, it says, "Each service should present a short-lived cryptographically verifiable identity credential to other services that are authenticated per connection and reauthenticated regularly."Mature teams can also consider routes for replacing credentials with automatically rotated certificates.
Teams already embracing service meshes can easily adopt systems like SPIFFE/SPIRE. For teams that have not already looked at
Least Privilege for NHI
SP 800-207A also encourages embracing the "principle of least privilege." This ensures that NHIs operate with only the permissions necessary for their specific tasks. By minimizing access scope, organizations can significantly reduce the attack surface, limiting potential damage if an account is compromised. This requires regular audits of permissions to identify unused or excessive privileges and a continuous effort to enforce access restrictions in alignment with actual operational needs. Least privilege is particularly critical for service accounts, which often have elevated permissions by default, creating unnecessary risks in automated environments.
Centralized Secrets Management
Referred to in both NIST publications is a clear call for managing secrets in a centralized secrets management platform. Enterprise secret management tools such as , or is designed to combat. GitGuardian scans repositories, including private and public GitHub repos, for exposed API keys, tokens, certificates, and other sensitive credentials. This aligns with NIST SP 800-207's recommendation to eliminate long-lived credentials and enforce strict policies for credential management. With real-time alerts for leaked secrets, GitGuardian ensures quick remediation, minimizing the risk of unauthorized access.
Ensuring centralized secrets management
While GitGuardian is not a secrets management tool itself, it integrates seamlessly with leading platforms such as HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault. This enables organizations to centralize their secrets storage and management, fulfilling another critical NIST requirement. GitGuardian's integration can ensure that secrets found . This not only protects NHIs in real-time but also enforces security best practices among developers, aligning with NIST's principle of continuous improvement.
Securing NHIs together
NIST has provided invaluable guidance for organizations striving to adopt a zero trust architecture and secure NHIs. Their meticulous research and recommendations, such as eliminating long-lived credentials, enforcing least privilege, and advocating for centralized secrets management, have set a strong foundation for tackling the growing complexities of securing NHIs in modern infrastructures.
At GitGuardian, we deeply appreciate NIST's contributions to advancing cybersecurity. We are committed to helping you operationalize these principles and rise to the challenges posed by evolving threats. Whether it's detecting hardcoded secrets, monitoring credential usage, or integrating with secrets management platforms, GitGuardian is here to ensure your systems remain secure and compliant.
Together, we can strengthen your defenses and secure your future.
SOCIAL SHARE CARD GENERATOR