The Case for Zero Standing Privileges

The principle of least privilege is one of the best known laws of information security: and it’s often the most difficult to put into practice. The principle demands that a user should only be given access to the resources and permissions they require to complete their tasks, and no more.

When I speak with peer CISOs they routinely state that they don’t have much trouble applying this principle to regular users, but they are still challenged when privileged access comes under scrutiny. Privileged Access Management (PAM) provides the seatbelt that makes it safe to grant privileged roles. Specifically, PAM addresses the risk posed by adversary access to administrator credentials by vaulting the passwords used for access to privileged resources. 

PAM has come a long way: in a former life we actually stored passwords on pieces of paper inside a physical vault! Vaulting software and services allows us to gate access to the credentials used for privileged access, and to require controls like step-up authentication and/or dual authorization before an administrator can “check out” the password. PAM can and should also offer an ability to automatically rotate a password after use by a human administrator.

Today’s PAM solutions have served us well when it comes to securing access to privileged on-prem resources like databases and servers. However, they tend to fall short when a privileged resource, such as a non-federated, privileged account in a B2B SaaS app, is accessible via the public internet. The vaulting capability can ensure that only an authenticated and authorized user can check out the credential for that privileged account, but if that password is entered into a SaaS app via an interactive browser session, the PAM solution can do little to protect the password from being saved (inadvertently) in the user browser or intercepted by malware. 

Over the past 12 months, we have observed a number of attacks where the vaulting of a password wasn’t sufficient to prevent adversary access to administrative resources.

These risks arise because:

• We are dealing with an Infostealer epidemic: The sheer size of the “combo lists” of stolen credential pairs and session tokens distributed on the internet today is staggering.  Most of the enterprise credentials caught up in these dumps were extracted by the personally-owned devices or the devices of temporary contractors - devices that were not subject to endpoint protection controls. Any password submitted via the browser of a malware-compromised device is vulnerable to interception. (You could say that the security teams of today are paying the price for the surge in the use of personally-owned devices that arose during the pandemic).

• Attackers are targeting native/non-federated/local accounts: Attackers are wise to the challenge posed by user accounts protected by single sign-on (SSO) and multifactor authentication (MFA). We have observed an increase in the targeting of non-federated accounts that allow direct access to the SaaS application. Authentication policies for non-federated accounts are typically weaker than those federated with an SSO provider. Numerous high-profile attacks involve the same pattern over again: the password or long-lived session token for a privileged account is extracted from an unmanaged device using infostealer malware, and is often sold on or distributed to other attackers.

These risks can be mitigated if:

• Security teams have tools to discover unexpected local/non-federated paths of access into SaaS applications, and

• Security teams can protect credentials with a cloud-native PAM that can auto-rotate credentials for SaaS applications after they are accessed by a human user.

Okta has made it our mission to build the tools that mitigate these risks (see Okta Privileged Access and Identity Security Posture Management). But as with any adversarial contest, “the enemy gets a vote” too: we should not expect their capabilities to stand still. 

So every organization also needs to be thinking about how to reduce or limit the blast radius when attackers successfully take over a highly privileged account. 

Enter (near) zero standing privileges

Zero standing privileges takes the principle of least privileged access to the nth degree. As the words suggest, the idealized state is that a grand total of zero accounts have standing administrative permissions in applications. 

I say “idealized” state because most systems are designed to have at least one interactive account with a level of administrative privilege. Resiliency demands the use of a break glass account - a shared account that can be relied on if the accounts assigned to individual human administrators are inaccessible. So if we’re being pragmatic, our North Star should be to reduce standing privileges to “near zero”. The minimum goal should be to have fewer numbers of user and machine accounts with highly privileged roles.

You won’t need to look very hard to find opportunities to downscope access. Large-scale studies have demonstrated the extent of the problem of over-privileged access: almost every user and machine account in the cloud is granted permissions that lie unused [pdf]. Microsoft’s research shows that less than 10% of permissions granted to Azure apps are ever used.  

There is a role for everyone in the identity ecosystem to play in whittling those permissions down:

• Cloud service providers have a role to play in helping their most security-conscious customers pare back the privileges that come with standard/out-of-the-box roles. Okta has made progress on the number of granular permissions available to create custom admin roles, and more are on the way.

• Customers of these services need to use custom admin roles to reduce the number of user and machine accounts with excessive permissions. Customers should also consider the myriad open source tools available for identifying excessive permissions in cloud infrastructure and applications, if not licensed Cloud Infrastructure Entitlement Management (CIEM) solutions.

Supporting zero standing privileges in the workforce

As part of the Okta Secure Identity Commitment, Okta recently shipped Govern Okta Admin Roles, a license-free add-on for every Okta Workforce Identity Cloud customer. 

Govern Okta Admin Roles allows for the most privileged administrative roles and permissions in Okta to be granted on a just-in-time basis. It’s built using some of the same tools our customers use to govern roles in third party applications (Okta Identity Governance). 

Access to Okta administrative roles can be configured to require dual authorisation, trigger customizable workflows, and be scheduled to expire after a specified time interval. My team recently recorded a live demo of this capability for the Risky Business podcast if you'd like to learn more.

I suggest taking a three-step approach to embracing this new capability:

1. Study what features your most privileged administrators use frequently. You are more than likely to find that the majority of permissions assigned to any given role are excessive. Work collectively to map out what baseline permissions are required for the roles in your organization.

2. Substitute standard roles for Okta Custom Admin Roles that only include the permissions your administrators require most frequently.  

3. Configure access request and approval flows for the more privileged and less frequently used permissions, such that they are available on a JIT basis and protected by dual authorization. 

In Part II of this blog series, we’ll unpack which permissions in Okta best meet the criteria for JIT access.