What is Zero Standing Privilege (ZSP)?

The idea of Zero Standing Privileges (ZSP) is a computer security concept where no standing or static access is provisioned to human users of a system. Sometimes it’s also referred to as “zero standing access”, and is usually associated with the idea of privileged access management (PAM).

Why ZSP is important

Standing access is the static access that trusted entities (both people and systems) have to your environment. This “always-on” access represents a large and tempting target to attackers, because not all credentials are created the same.

The Google Q3 2023 Threat Horizons Report identifies stolen credentials as the most popular initial attack vector. By implementing ZSP in your environment, you protect your customers, and ultimately your business from being exploited via stolen credentials. The act of requesting time-limited permissions gives an additional layer of security on top of the usual authentication mechanisms, like strong passwords and multi-factor authentication (MFA). LastPass and others stand as an example of what can happen when specific credentials are targeted, and compromised.

ZSP is a way to implement the concept of continuous verification. Just like Continuous Delivery and Continuous Integration (CI/CD), the repeated application of best practices results in higher quality systems that perform better during incidents. ZSP also provides an effective limitation to blast radius, which is the concept of the impact of the worst possible compromise in an environment.

ZSP in practice

At its simplest, ZSP introduces an additional layer of verification in to the access flow. This gives the access an additional layer of approval, and allows the access to be time-bound.

Here’s what ZSP looks like in a “happy path” scenario:

1. An engineer requires access to a system (such as a database) to perform a standard task as part of their daily work
2. The engineer submits a request for the specific access required
3. The request is approved by the right approver, as determined by the business requirements and risk
4. The engineer receives the specific level of access, for a set amount of time
5. All steps of the process and resulting access are logged
6. Access is removed when the engineer finishes the task, or when the access expires

Some of the key differences with a standard/static access model are:

• Access requested can easily be made specific to the task at hand, not just “administrator access,” even if engineer is eligible for the highest levels of access
• Approvals can be automated, for example on-call engineers might have automatic approval to access the systems they are responsible, which reduces friction for valid tasks
• The approval process can be monitored and measured, which gives additional visibility in to how the system is being used and performing

Where the difference becomes critical is if credentials are ever compromised. With standing access, the attacker with the compromised identity’s credentials can do anything that identity could do.

ZSP in the real world

Traditional systems assign role-based access, usually by team or title, which does not take in to account any context of their daily responsibilities. For example, just because an engineering manager is responsible for a particular system, doesn’t mean that they’re logging in and making changes on a daily basis. This example of standing access is a risk, but one that is widely accepted in many environments. While it makes business sense that a manager should have access to the system they own and are responsible for, having it available all the time is not required. Even though they might need access in certain break-glass scenarios, they likely don’t have a standing requirement for access day-to-day, which is the responsibility of the engineers on their team.

In a standing access environment, the manager’s credentials represent a tempting target for attackers, because the level of access is elevated. If anything, this pattern might let them hide the compromise for longer, because it can take longer to realize that infrequently used credentials are being misused.

With ZSP, even those that have a valid business reason for access to protected systems need to request access, with greatly reduces the risk resulting from credential compromise.

Related concepts

Sometimes ZSP is confused with the principle of least privilege (PoLP) access, as if the two were competing approaches. ZSP and PoLP are complementary to each other, but fundamentally different. PoLP limits the permission scope of authorization, ZSP limits the time scope of authorization.

Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) are also relevant, but different, concepts relating to privilege. RBAC is focused on matching the business or technical role to the level of permissions. ABAC is aimed at using attributes of the identity as context when making decisions, and while this might help implement ZSP, it is an additional and optional approach.

Requirements for ZSP

• Just-in-time (JIT) access is required. Without the ability to dynamically grant access based on requests, it just isn’t possible to withdraw standing access, without preventing engineers from doing their daily tasks.
• Automation is a key component of ZSP, since without it the overhead of managing requests and approvals becomes too much of a burden for teams to do for all their access requirements. This means there must be some up-front investment of engineering time and effort, to get the pay-off of enhanced security.
• An external identity provider (IdP) is required to maintain the concept of identity across all access requests. This source of truth for identity can focus on the authentication process (such as implementing MFA), without needing to be concerned with the authorization part of access management.

It’s worth noting that ZSP not just for special or elevated levels of access, but it’s a common starting point for organizations that are just getting started with ZSP, because it helps justify the additional effort. Ideally, all access should be managed from a zero starting point, which means that all access uses the same workflow for consistency and reliability, lifting the security posture for even unprivileged levels of access.

Integrations with messaging or chat tools (aka. ChatOps) integrates approvals with common communication patterns and workflows, reducing approval wait times and access friction, both of which contribute to the effectiveness and adherence of ZSP systems.

The future of ZSP

As companies, systems, and customers become increasingly connected, reducing the attack surface available to malicious actors (internal and external) becomes increasingly important and valuable. The up-front investment in reducing and removing standing is more than outweighed by the benefits, even if it only protects you from one incident.

As the industry evolves, ZSP will move from an aspirational nice-to-have to a hard requirement for any organization that claims to value security and the integrity of their systems, and ultimately their customers’ trust.

‍