What are Zero Standing Privileges (ZSP)?

What are Zero Standing Privileges (ZSP)?

The problem Privileged Access Management (PAM) solutions seek to solve can be simply formulated: How do I appropriately provide and protect privileged access to my information technology assets? Traditional PAM solutions have focused on deploying controls on top of an enterprise’s existing identity practices, whether that’s providing password and session management for shared built-in administrator accounts or a password-of-the-day for personal privileged accounts.

These approaches all rely on the same thing – protecting identities that permanently possess privileges on systems, databases, applications, etc. However, these “always-on” privileges can be stolen and misused and they remain a prized tool for attackers; their very existence creates a risk to an organization that should be mitigated. Why should we accept that risk or focus on mitigations? Enter a better way with Zero Standing Privileges.

The concept of Zero Standing Privileges has the objective to eliminate these “always-on” privileges.

Why Zero Standing Privileges (ZSP)?

Simply put: administrative privilege provides the means attackers need to complete their mission, whether that involves data exfiltration, data destruction, or other objectives. When an organization has identities with “always-on” privileges they must spend money and effort to control access to them, monitor their use, protect them from misuse. But for much of each day, these highly privileged identities lie fallow, unused but still posing risk. Many traditional PAM projects struggle because of the sheer volume of standing privileges and prior efforts to implement least-privilege models, while noble, have only exacerbated the sprawl.

Traditional PAM approaches have focused on managing and controlling access to privileged account passwords or temporarily elevating privileges to control when users can act with administrative privileges. For example, Jill, a server administrator, may check out a password-of-the-day for her personal privileged account “admin-Jill” each morning. Or, she may use a solution like sudo to have her privileges elevated on demand.

The focus of each of these approaches, however, is on ensuring that Jill uses her privileges in an authorized manner – but, Jill is a good employee and not an attacker seeking every avenue to compromise the organization. In both of these approaches, the privileges granted to her personal privilege account or in sudo configuration are persistent and are at risk to be abused by a motivated attacker.

Just Enough Privilege (JEP), Just in Time (JIT)

What if we can eliminate these standing privileges and replace them with a policy-driven process for obtaining privileged access only when it’s needed and scoped only to the job at hand? The answer is Just-in-Time privileged access and Just Enough Privilege grants.

In a JIT workflow, there are no standing privileges for Jill — there’s no sudo configuration to maintain, no personal privileged account to monitor. Instead, Jill’s potential privileges are detailed in a centralized policy. When Jill’s job duties require her to obtain privileged access, she initiates an activity which describes what she wants to do, and on what resources she needs to do it.

Behind the scenes, an activity identity is created or activated and just enough privileges granted to perform only the desired task. The activity is then performed interactively by Jill (e.g. remote desktop protocol (RDP) to a server) or by the system on her behalf (e.g. reboot a server). Upon completion of the activity, the privileges are revoked from the activity identity and it is destroyed or disabled.

By adopting this workflow, the privilege attack surface is reduced to the window during which Jill is actively using privilege; no passwords or artifacts remain for an attacker to steal. Unlike traditional PAM where the focus is on protecting the means (e.g. privileged accounts or configuration) that confer privilege, the focus of the Just in Time workflow is on the user. All Jill needs to know is that she needs to reboot a specific server, and the system will take care of providing, securing, and destroying that privilege when she’s done.

The zero standing privileges objective can be realized through just in time privilege access, improving operational sustainability for your privilege access program and drastically reducing the privilege attack surface. We’d love to hear your thoughts and questions on zero standing privileges and just in time privilege access below.

To learn more about our Zero Standing Privileges (ZSP) solution, visit our Stealthbits Privileged Activity Manager webpage.

2 thoughts on “What are Zero Standing Privileges (ZSP)?

  1. I struggle with this.
    The problem I have revolves around the use of service accounts or non-person accounts. Example: I need to keep a running inventory on every server we have so we have one account that is admin on all servers so it can run WMI queries, inventory software, etc. Server admins use an automated process to deploy patches, etc. which uses this same account or maybe our monitoring solution requires admin to run scripts every 15 minutes or whatever. In short, we have service accounts that are not domain/enterprise admins but they do have admin on every server in the company just the same. No user uses them so there are no workflows to be called.

    My Red Team loves these accounts because it gives them lateral movement any time they want it. Just Enough Admin will help, it can mitigate the problem to some extent but there will still be that account or accounts that simply cannot be mitigated.

    How does one mitigate that? We already monitor these accounts, hide these accounts from general queries, etc but we still struggle with keeping unknown threat actors (mostly our own red team) from pulling them from memory on running systems.

    I’ll keep digging, I also really appreciate the information from your blog postings. If you have any thoughts on my dilemma, I’d love to hear them.

    Thanks,

    Ron

    1. Hi Ron,

      Thanks for your comment; glad you’re enjoying the posts.

      Service accounts pose some additional challenges, but eliminating standing privilege for non-humans is just as important as for humans. Just in time workflows can be called via API, allowing applications to also obtain just in time privileges. That’s a bit more of a strategic direction, as it’s going to take some technology development but more importantly it’s going to take acceptance from software vendors that standing privilege is not a valid security pattern. We’re happy to continue to lead the battle on this!

      A few thoughts on things you can do today:

      1. Require explicit documentation for service account privileges from vendors and developers; anyone who just says “make it an administrator” is being lazy unless they can justify that in technical detail. Remove as much administrator access as you can, which is going to greatly reduce the attack surface.

      2. Prevent service (and other privileged) accounts from authenticating across security boundaries. As you point out, it’s still difficult to entirely prevent lateral movement. But one of the main risks from lateral movement we’re concerned about is privilege escalation – whether that means domain admins or access to sensitive data – and ensuring that your service accounts only have privileges within a single security boundary greatly reduces their value.

      3. Use Group Managed Service Accounts (gMSA) wherever possible. You’ll likely need to push vendors to support their use, but they can reduce your lateral movement risk.

      4. Consider prioritizing technologies that rely on pulling information, rather than pushing it. For example, I’d prefer a task running on each server to install patches rather than a central authority pushing them down. This pattern can eliminate the need for that service account with broad administrative privileges.

      I hope this is helpful; I’m always happy to discuss more. I hope you have a great new year’s celebration.

      Regards,
      Gerrit

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free Stealthbits Trial!

No risk. No obligation.

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other