Recently, Mandiant published an in-depth look at PAM. We applaud Mandiant and Google as they continue to push toward a safer world, and their PAM guidance is packed with grounded, hard-won advice. It is also good to see non-human identities included in the scope. Service accounts APIs, workloads, and automation have real entitlements. Leaving NHIs out of PAM creates blind spots that attackers exploit and auditors eventually find.

We also appreciate their PAM levels of maturity guidance. Teams can use their four levels, uninitiated, ad-hoc, repeatable, and iterative optimization, to help organizations of any size find the next steps in the right direction. This approach aligns with what we have seen in our Secrets Management Maturity research.

GitGuardian is happy to help teams as they align with these objectives, no matter where you are on your path.

Start By Knowing What NHIs You Have

Traditionally, the field of privileged access management has focused on humans who require a higher level of privilege. As Mandiant defines it, "A privileged account is any human or non-human identity(NHI) whose entitlements can change system state."

Attackers love NHIs, as they tend to be long-lived and lack MFA. Worse yet, detecting unusual behavior from an entity when it logs in is much harder than if someone breaks in.

We must ask ourselves, can this NHI impact my organization? What would be affected if it were revoked? Is the data it accesses privileged?

But those questions are hard to ask if you don't know the NHI exists. GitGuardian is helping teams answer exactly this with out NHI Governance and Secrets Security platform. We help teams find access keys, commonly called secrets, in plaintext, where they likely should not be, and give visibility to vault contents, where secrets should safely live.

GitGuardian can help you discover all secrets leaked into code, but also when they get pasted and stored in Jira, Slack, Confluence, and any other system you need to monitor.

Automating Rotation Requires Cross-Vault Insight

One sign you are on your way beyond the "Unitiated" level of your PAM maturity is that any shared credentials are vaulted and rotated. Thankfully, every provider, from AWS Secrets to CyberArk, makes rotation easy once the secret is accounted for within the vault.

This assumes, though, that any particular secret exists in only one vault and is used only once throughout your code or infrastructure. What would the results be from rotating this secret in one vault, but not all vaults? Does anything actually call this secret? 

GitGuardian NHI's Governance platform can help you safely inventory all of your secrets across all of your vaults, mapping paths and usage throughout your systems. By tying into your IAM, CI, and other operational tools, GitGuardian can help you enforce rules around how these secrets are used and what state your NHIs are in. We want to help all teams get visibility into who accesses which credentials and from where. 

Have confidence when you do rotate those credentials; all instances and access are accounted for. This approach also gives you more certainty that a secret is being consumed by the right entities in the correct environments.

Aiming High While Dealing With Operational Reality

For mature organizations, Mandiant says that the PAM maturity path should result in "Human standing privilege trends toward zero; service/API identities move to group Managed Service Account (gMSA)/managed identities."

We strongly agree and support teams as they embrace Zero Trust Architectures and federated identities in their enterprise. We also know that improving security posture takes time. Teams should focus on the near-term goal of identifying which identities, human or NHI, can access and affect your most mission-critical systems.

Without visibility into your current NHI inventory, it is difficult to move towards a world of just-in-time (JIT) access, instead of the current world of  long-lived, overprivileged keys, connection URLS, and tokens. Getting a baseline of what exists is the first needed step before assigning any entity a tier or criticality score.

Combining GitGuardian's dual approach of both finding all secrets where they should not be in plaintext throughout your systems, and giving you insights into the state if the secrets which are properly housed in vaults, gives your team unprecedented visibility. This visibility is critical for administering any governance plans. 

And, with GitGuardian's Push to Vault feature, we can help your team move secrets found outside of your preferred secrets management platform into the right vault your governance processes require. 

Shifting Left On Credential Exposure

GitGuardian agrees with Mandiant that "uninitiated password reset or account setting change on a privileged account" is indeed a sign of compromise. Those credentials for those accounts should be rotated or revoked as soon as the danger emerges. However, we think that teams should be responding to exposed credentials much earlier: as soon as they are exposed in plaintext in the first place.

GitGuardian is helping teams shift left with credential exposure response in some major ways.

First, the platform can alert you instantly when any real-time incidents of credentials showing up in plaintext across code, messaging systems, ticketing platforms, documentation, and any other source. We are not limited to detecting NHIs, which the platform famously helps teams govern. Any password or credential that is contextually granting access will be detected in seconds, allowing you to respond before an attacker is ever aware it exists.

We know from research and experience that once a credential is exposed in plaintext, it is only a matter of time before it is exploited. This is extremely true of all the secrets that make their way into public GitHub repositories. But it is equally true that once an attacker gets inside your trusted systems, where we know secrets leak at a much higher rate, as much as 8x more often, according to our research.  

The other way GitGuardian can help teams towards better PAM security is by providing early warning canaries, which we call GitGuardian Honeytokens.

Offering attackers alluring decoy credentials, in the form of AWS keys, we can tell you instantly if someone is poking around and scanning for secrets within your private code and environments long before they attempt to reset the password or change privileges.

It is time to Harden Our Tactical Stance.

Towards the end of Mandiant's comprehensive guide is the advice to:"Prepare before an incident: Map every service account to owner and workload, run continuous discovery cycles to find systems and credentials, and onboard all human and non-human privileged identities into PAM; enforce unique credentials, MFA, and API-based rotation."

The time has come to bring non-human identities into our privileged access management strategy. We must realize that non-human identities have the same potential to affect our mission-critical systems as some of our administrators or domain access controllers.

The only real way we can move towards a future of "Iterative Optimization," the highest level of PAM access, is to deal with the operational realities of today. This starts with getting a baseline for your NHI security posture health today. Put GitGuardian on the front line where PAM cannot see. Stop secrets at the source. Rotate fast when exposure happens. Correlate across systems. Turn every response into proof.

Again, we thank Mandiant and Google for guidance that keeps the field moving forward. 

Your next move is clear. Widen the scope, get visibility, and move to a world where any leaks are caught well before an attacker can exploit them. GitGuardian is here to help you on your journey to PAM maturity.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Take Control of Your Secrets Security authored by Dwayne McDaniel. Read the original post at: https://blog.gitguardian.com/working-towards-improved-pam-widening-the-scope-and-taking-control/