I’ve been working on Zero Trust for a decade now. It’s getting complicated out there. But it’s working – network firewalls are out and SSO is in! The world is better. SSO is great. But I see the emergent outcome of this: Our threat models are colliding. Insider threats and outside attackers are starting to look the same.

Because SSO and MFA are so good, hackers are stealing identities or their logged in sessions, as we unfortunately saw in the CircleCi incident. Now an attacker needs persistence on a developer’s laptop, instead of guessing a 6 character dictionary password in an isolated system without MFA. Progress. BUT! This means that hackers are starting to “look” like insiders from a system defense point of view. Some of the tools for managing insider risk are now the means to mitigate risk from outside attackers as well.

The problem that persists at the intersection of insider threats and outside attackers is authorization. The access and permissions for an identity should be tied to the exact work an identity should be doing at that moment, and nothing more. This is often called least privilege. And guess what, least privilege shows up as a coveted principle or pillar of zero trust almost every time.

The challenge is finding pragmatic advice on implementing least privilege. And so, I present to you:

Paul’s Pragmatic Least Privilege Maturity Curve

Phase 1: Have Less Stuff

Does access to your company’s support portal spark joy in you? If not, you probably don’t need it. Besides encouraging your team to have a Marie Kondo mindset and culture for permissions, you can drive this through tools like access reviews. Self attestation, manager review, justifications – they can all drive a reduction in total privilege at a company. Additionally, it can make sense to take on engineering work to improve tools and systems – either eliminating unused features or functionality, or creating more fine-grained roles or groups. For example, you could add a “read-only” role to your internal support tool and restrict mutation operations to a smaller group.

The problem is, realistically, this mindset can only go so far, until you severely hamper the productivity of your entire team. You end up waiting on a ticket that’s been sitting for months, asking another person to do some simple button click inside an application – but you just don’t have permissions to press it.

The other problem is even with a minimalist culture and constant review, permissions have a tendency to accumulate. That is, the graph of permissions for an identity goes up and to the right, until that person is no longer at the company (when it should go to zero… right?).

The longer someone works at a company, the more access they accumulate. And another flaw, we are graphing this in YEARS. The accumulated risk is the area under the curve – permissions multiplied by time.

Phase 2: Dynamic Privilege

To make the most theoretically secure system, just give no one the permission to use it. But this would be a major damper on productivity, if no one could access a system! The reality is that many employees do need access to sensitive systems and data, but they often don’t need it every hour of every day, and that’s where a strategy of dynamic privilege can help reduce risk and inject reasonable processes for gaining privileges. In our previous graph example, we can reduce the area of the curve by introducing ephemeral and dynamic privilege–time-limited or expiring access. Your employees don’t need standing permissions to your AWS admin role. You can put that behind a time-limited access request and through automation, revoke the access after a day.

If you do this, your privilege graph has humps, like a camel. Your identities have their baseline permissions, e.g. corporate email, but a subset of permissions become dynamic. This is a good pattern for highly privileged roles or actions that aren’t needed every day.

Now our graph is looking nice! We can talk about the risk areas in terms of days of the week instead of years. The permissions of a user actually go down! This has neat properties, for example, a user who doesn’t need access often or needs it for a one off project truly just doesn’t have access.

Camel shaped graphs do have a prerequisite to be successful: automation and an excellent user experience. If your team dislikes using a dynamic privilege tool, they will inevitably subvert it or not use it when it’s introduced. If you’re only going to have authorization for a short period of time, the tool must be easy to use and not require manual work.

This method also can fail when a person’s job is inherently working in a privileged application. A senior employee in customer support or your database engineers – they live in risky environments every day and the tasks they might need to perform vary.

Phase 3: Multi-Person Authorization for Privileged Actions

The classic picture of this is of a nuclear missile command center, with two people needing to turn a key at the same time. So far our civilization has survived, so I guess it’s working. Multiple authorizers is a common concept in industries like financial technology or cryptocurrencies, but it has not yet been widely adopted in general SaaS applications.

This is true, except where natively supported by the SaaS. For example, almost every modern organization uses a tool like Github or Gitlab. These tools enforce a permission to merge a pull request – they generally require another developer to approve or in some cases a specific group of developers if you’re modifying specific files (“code owners”). This is a multi-party authorization for a privileged action!

Right now, this pattern is largely artisanal. This is a one-off, but multi-party authorization for a privileged action works well when the action is something that happens very often and the work is done in a team context where other team members can review and approve the action.

In pragmatic terms, you will likely need your security engineering team to build tools for this. But it can be useful for actions in your support dashboard or for tasks like deploying your software. These are actions done often, but with high risk, so the investment in automation and a good user experience is worth it.