Making Zero Standing Privileges a Reality
The most significant change in the lifespan of identity security thus far is zero standing privileges (ZSP). Considered to be the next evolution of just-in-time (JIT) access, although it may seem needlessly complex at first, once you wrap your head around the concept, it feels as natural as turning off lights when you leave a room.
But first, a bit about me and the journey to ZSP.
I’m lucky enough to have thus far had a diverse career in tech that’s had me in a series of roles, from being an engineer to working with advisory consultants. During my time building infrastructure at scale, there’s been a constant demand for concepts that address the risk posed by privileged access without impacting ops productivity. As it turns out, years later, as I led CyberArk’s Strategic Alliances Solutions Architecture practice, I saw this exact challenge from another viewpoint. People want to behave in a way that keeps their organizations safe, but they expect to remain productive – not blocked by intrusive controls.
The ZSP concept meets that need.
The Journey to Zero Standing Privileges
Least privilege (or the principle of least privilege (PoLP)) is always a no-brainer. If you don’t need access, you should not have access.
I ran a team of operations engineers many years ago supporting a large-scale Infrastructure-as-a-Service (IaaS) platform. In looking at what we could do to improve the security of our platform, least privilege made perfect sense to us – it felt like a boundary that defined if something was in scope for our team or not.
A glimpse, from the author’s perspective, of 400 servers – or about 2% of the platform managed by his team in 2013.
We ran with the principle of least privilege – piloting various implementations and methodologies. But ultimately, that least privilege journey fell flat. The team, comprised of what would now be called platform or site reliability engineers, had massive hesitance to give up the access rights they felt they might need during an incident. Any team dealing with a critical situation is very familiar with the idea that it’s hard to build a technical plan for ‘when it goes wrong.’ Things never break in the way you expect.
In looking for the next concept that might allow us to improve the security of our platform, just-in-time (JIT) access was an easy winner for us. The only thing holding us back was our collective ‘when it goes wrong mindset’ where, during a critical situation, we’d often want to troubleshoot at a large scale across the entire platform, potentially accessing hundreds of servers, routers and switches to identify the issue. This wasn’t an unreasonable concern, but one that could be exploited by any attacker present.
As it turns out, I left the organisation before anyone definitively figured out the correct solution. I considered it a real miss that I never actually determined the right way to improve the identity security of our platform.
The reality was that we needed something that combined these concepts with consideration for the operational impact. This is where the concept of ZSP becomes highly relevant.
What is Zero Standing Privileges?
In short, ZSP evolved from JIT access because it was a necessity. Simply turning on and off administrative access for a user didn’t offer enough risk reduction for many modern enterprises.
ZSP is the concept that an identity sits with no entitlements on the resource it will be used to access – until the identity is needed and entitlements are requested. When granted, those permissions are only the ones required. It’s giving access to the right people at the right time – no more and no less. This represents a massive attack surface reduction as the account itself is now useless – even if an attacker could log in, they can’t do anything because they have zero permissions!
As such, ZSP is an excellent concept, sitting at the intersection of JIT access and least privilege. It addresses those frustrating ‘what-ifs’ that held me back due to the requirement of rapid access grants.
The author attempts to bypass a cloud provider’s controls to demonstrate the power of ZSP.
Zero standing privileges add further protection to just-in-time as a concept. With JIT access, you’ll be unable to enable just the right number of privileges to that account. This is arguably the core requirement of ZSP.
Only allowing an account to have the privileges it needs by exception rather than standing entitlements and returning it to no privileges puts you in a situation where you can minimise that account’s exposure. Elevating access just-in-time does reduce the risk of credential theft. But, once access is provided, internal or external bad actors have more entitlements to exploit, enabling lateral movement and privilege escalation. A ZSP approach also reduces the volume of systems or services an attacker could compromise when they gain access. This is easily one of the most effective strategies for reducing risk.
How to Make ZSP a Reality
First, you’ll need to find a way to handle elevation, a mechanism to align a user to a group of permissions. For a realistic chance of adoption, elevation mechanisms must be integrated into service management or ChatOps to speed up the handling of approvals.
You’ll also need to move away from thinking in the binary ‘is this an admin or not’ mindset and consider how the user access level poses a risk and find tooling to manage that. The distinction between privileged and non-privileged access is nebulous in modern Infrastructure as a Service (IaaS) environments. Lastly, you’ll need to ensure that whatever permissions you grant get removed as soon as the session ends.
If you’re looking for a modern, dynamic way to secure access in your cloud platform (as I once was), check out the CyberArk executive POV, “Why Cloud Identity Security and Why It Seems So Hard.”
Josh Kirkwood is a senior product marketing manager at CyberArk.
