Getting started with Zero Standing Privilege: A Field Guide


Over the last few weeks I’ve had a bunch of conversations about zero standing privilege (ZSP). From my blog exchange with Andi Hindle, to the Identerati Office Hours with Mike and Vlad, to a great chat with Simon and Atul, ZSP has been the topic du jour. And throughout those conversations one question consistently came up: how does one get started with ZSP?

Conduct a census

ZSP, just like automated user provisioning, is not something that you need to apply for 100% of your apps, services, users, and use cases. As you start off, you’ll want to take a far more targeted approach. I’d recommend itemizing the systems/apps/services that, if something were to go wrong, have the greatest blast radius. Talk to your service reliability peers, talk to your friends in finance, talk to your customer support teams. From them you’ll get a list of things that could cause significant outages or damage to the company… like core DNS, network infrastructure, general ledger, your services in the public cloud, etc. 

Why gather this list? Well, user accounts in the systems on that list represent, at least in theory, extremely privileged accounts; the standing privileges in those accounts represent significant risk of abuse and misuse. It’s those user accounts where you’d likely ought to begin.

BTW, it’s worth pointing out that ZSP is not solely about mitigating the risk of an external adversary abusing standing privilege… sometimes the calls come from within the house. Long ago, I was a sales engineer for Oracle. One of my clients suffered a major outage because the database administrator thought they were connected to a development instance and truncated a table. This meant that all the rows in the table were deleted in their entirety… no chance to undo. And it turns out that the DBA wasn’t attached to the development instance but, in fact, the production one – a simple mistake to make… with a massive blast radius.

Find low hanging fruit

While you are working on building that list of high blast radius systems, I’d recommend identifying easy-to-implement ZSP systems. What you are looking for are systems where there is native support for either ephemeral users or user accounts with no (or very low) mandatory standing user privilege. Find systems that easily support just in time (JIT) access changes at at least session creation time. 

Why these systems? These systems give you a headstart in terms of implementing ZSP… because they already support it. And that means you stand a greater chance, with the technology you already have at your disposal, of being able to implement ZSP.

A side note about JIT and ZSP. You can think of JIT as a means of achieving ZSP. JIT is great at granting access, but it, in and of itself, often lacks a way to remove that granted access. But, and this is the key point, you must check to see what happens with a JIT’ed user account after the session is over… if it retains the access granted then you must find a way to remove that access. Leaving aside how access is removed, tools that facilitate JIT do not always have great capabilities to make a priori decisions about what access to grant… and that can lead to custom code either in the SSO or the service provider too.

Taking an example from my recent past, Salesforce allows privileges to be granted explicitly for a specific session. Known as session-based permission sets and permission set groups, Salesforce has a native mechanism of granting elevated privileges that are scoped to a session; once the session is over, the access goes away. This stands in stark contrast to regular permission sets and permission set groups, which also can be granted via JIT but whose associated privileges are retained after the session ends.

Head to the intersection

With a list of critical systems in scope for ZSP’ification and the list of easily ZSP’ed systems, hopefully you got lucky and there is intersection between the two. Such an intersection would be systems that are high blast radius AND natively support ZSP. The next step would be to explore what means you have today with your existing identity capabilities to JIT access to the user accounts (and ensure it is removed) as well as reducing rights granted via birthright policies.

This likely means that you are going to need to make changes to both your user provisioning and SSO systems. Do so cautiously with a mindset of creating a repeatable process. Ideally, you’ll repeat these steps again for the other critical systems to which you want to apply ZSP. That repeatable pattern also needs to include how you document those changes as well as how you work with your auditors to demonstrate the effects of those changes. You will be changing the means by which a person gets elevated privileges and thus you’ll need to demonstrate both how you manage the policies for that as well as how the auditor can validate those policies.

I think there is a lot of affinity between planning for ZSP and planning for automated user provisioning. Identifying what you want to protect and your ability to manage/change user privileges are mandatory common steps – what differs is the way in which you affect those changes. The point being that the ZSP journey ought to be a reasonably familiar one; it’s a path you have walked before!

See you in person?

I’ve been having a blast thinking about ZSP. Every conversation I have about it helps solidify it in my mind which in turn points to more questions to answer. I’ll be at Identiverse and then the European Identity and Cloud Conference… love to hear what you think about ZSP there!

And if you are attending Identiverse there’s some of ZSP-related content you might want to check out!