I was having a conversation with a colleague recently and he brought up an interesting point. Essentially, the question came down to how do we audit and attest compliance when there isn’t an account or access to discover? More importantly, how do we reconcile and attest to access that is not there? So, lets dig into this shifting paradigm.
But, before we get there, let’s go through some background first. Whether it be Cyber Insurance, regulatory compliance, or general due diligence, there is going to be some kind of requirement around Privileged Access Management (PAM) and appropriate program and controls around that within your organization. (apologies, my auditor side is going to come out for a bit). To appropriately attest to this, we need to look at this from an audit and compliance perspective and define what this means, and more importantly how do we attest and validate this.
From a compliance perspective, this is going to break down into a couple functional items for an organization (to do this appropriately).
- Do you have a policy statement and standards for what PAM is in your organization and the requirement for it.
- Document controls around your PAM program, privileged accounts, and ‘periodic’ reviews of such access.
- Run your program and discover, attest, and manage privileged access in your environment. Most importantly, gather evidence of such when doing this to show compliance and adherence to your policy and standards.
(BTW, you can do a quick search of google and find templates / documentation to support this if you need it internally)
From an accepted standards and audit guidance perspective, in a traditional PAM approach and environment, this meant discovering privileged accounts, vaulting, rotating passwords and managing that access appropriately. On top of that, having a governance platform and approach for managing requests for privileged access / accounts, certifications / attestations of such access, managing changes / rogue access, and finally revoking when no longer appropriate or needed.
But, like most things in the security space, as we have matured with managing privileged accounts and access, the attacks have changed. As the profile has changed, and as we mature as an industry, vendors are moving to more appropriate techniques like Zero Standing Privilege (ZSP) and just-in-time (JIT) privileged access. This is greatly improving our risk profile when it comes to privileged access given there isn’t an account to attack, and is ephemeral for a specific tasks. This is GREAT!
Now, back to the original conversation I had with the colleague. If we have built controls and infrastructure around discovering, vaulting, rotating and attesting to an account and privilege, but that is no longer there, how do we PROVE we are doing this when it is no longer there? Moving to a ZSP / JIT, the next periodic attestation to privileged accounts is going to be empty since is nothing there to discover and attest to. And likewise, auditors are going to question this thinking 1) governance platform is broken or 2) you can’t see things in your environment which is going to cause audit findings.
So, how do we fix this shifting paradigm?
First and foremost, we need to update our policies and standards to redefine what privileged access and accounts mean. Rather than static concepts of privileged accounts / access, we need to shift focus to the privilege itself and how that is represented and granted in the environment. For example, rather than saying we manage privileged accounts withing the PAM program, we shift to saying we manage access to privileges via the Governance Process (workflows, reviews, etc.) and enforce usage of such privileges via the PAM program / platform. This gives you the capability to audit access to who CAN execute / access privileges, not the actual accounts that they are traditionally assigned.
Next, we need to train our auditors. Is very easy to document discovery of accounts and periodic reviews, who is in an administrators group, etc. But, as we shift to this ephemeral approach to accounts and access, we need to make sure we are appropriately training auditors to understand what we define as privileged (e.g. who has access to execute a task, who can request elevated privileges, etc.) and not so much who has an account.
Lastly, we need to update how we attest to the above. This is going to be a bit harder in the sense is going to require a different level of oversight. Yes, we still need the governance capability / review of who CAN assume a privilege, but we also need alerting and usage of such privileges. Gathering this type of data can provide reporting to auditors / compliance of 1) who used such privileges and 2) correlate this to who SHOULD and CAN assume the privileges to ensure this is only being used by who you assume to be able to.
As a side note, with this move to ZSP / JIT, I always recommend that people build alerts to users and owners when the above is used. If you know when you are doing something, and the alerting reminds you of such, is much easier to know when something is not supposed to be happening because is alerting you of such.
So, as you start moving to this new model for PAM / privileges in your environment, in summary, would:
- Update policies to documenting the new definition of PAM / privilege and standards for attesting to such.
- Train / review with your auditors to make sure will be accepted
- Attest to access to execute privileges and monitor / alert on usage of such privileges.
Using this approach, you’ll be able to leverage this improved security posture and ensure maintaining compliance with current accepted standards and definition of PAM in your environment.
