Just-in-Time PAM and the False Sense of Least Privilege
by Mahesh Babu, on Sep 09, 2020
Just-in-time administration (JIT) is a now prevalent capability in PAM solutions. Once an emerging, niche feature set, this has now propelled into a table-stakes capability for PAM vendors offered as a bolt-on with their Enterprise Vault and PEDM offerings promising to (1) reduce the surface of unnecessary persistent access given to administrators and (2) reduce administrator friction by allowing the use of their own accounts and not have to check in / check out secondary or shared accounts.
Therefore, the analyst community has framed JIT as a low friction way to enforce the Principle of Least Privilege. While conceptually true, the implementations of JIT in the market do not address these requirements at all. The some that do, don’t actually reduce the risk. None of the approaches can certainly claim to enforce the Least Privilege or Zero Standing Privilege.
The definition of JIT itself can be misleading. For example, let’s take a look at how Gartner defines JIT in their 2020 Critical Capabilities report:
"This capability provides on-demand privileged access without the requirement of shared accounts carrying standing privileges. Typically, this involves non-privileged accounts being granted appropriate privileges on a time-bound basis. This capability is focused on compliance with the principle of least privilege and subsequently achieving zero-standing privileges for PAM access."
Gartner then goes on to define the key capabilities or “use cases” that constitute JIT:
- The ability to dynamically add and remove users from AD groups.
- Dynamically provide time-limited access to privileged accounts.
- PEDM functionality through on-demand privilege elevation.
- On-demand creation and deletion of privileged accounts.
- The ability to create and use ephemeral tokens.
- On-demand access to SaaS control panels like AWS
Here are the limitations with the way Gartner frames JIT:
| Use Case | Positive | Negative | Enforces PLP or ZSP? |
| The ability to dynamically add and remove users from AD groups. | Limits group access to a time-based membership. | For the time window approved, users have access to everything provisioned to the AD group. Unless AD groups are very targeted (access to a single computer) they are not “least privilege” AD groups tend to be left in place AD group nesting leads to unintended, hidden privileged access provisioned to users |
No |
| Dynamically provide time-limited access to privileged accounts. | Time limiting ensures privileges are elevated for an approved, specified amount of time thereby reducing "in-session" time | Only the authentication is time limited, not the access. In most cases, access is 24x7. These permissions can be weaponized by attackers to infect a machine with malware, move laterally from machine to machine and spread ransomware. Sessions to be easily extended (giving admins 9-5 access) or circumvented (by using elevated privileges to create multiple accounts) |
No |
| PEDM functionality through on-demand privilege elevation. | Can effectively blacklist / whitelist applications and processes Can effectively elevate permissions of the device owner and manage membership to the device's local admin group |
Bypasses >90% of the privileged users with access to a machine: PEDM tools can elevate privileges for those users directly listed on the machine (e.g., the device owner, local administrator), but not those who have hidden, effective access gained through AD group nesting. |
No |
| On-demand creation and deletion of privileged accounts. | Minimizes the need to have complex, agent based AD bridging solutions to provision corporate, directory managed identities to specific machines. This is especially beneficial for non-Windows machines that natively do not support Active Directory | Without robust SIEM-PAM integrations and logging, incident response teams will lose user attribution and the ability to trace user activity | No |
| The ability to create and use ephemeral tokens. | Compensating control for applications with poor secrets management best practices such as hardcoded passwords or cryptographic keys | Dependent on a well managed PKI infrastructure - shifts the risk to the key management solution | No |
| On-demand access to SaaS control panels like AWS | Limits access to AWS IAM roles / Azure AD groups and other equivalent resources | Dependent on how groups / roles are structured and nested. For the time window approved, users have access to everything provisioned to the role or group. Unless roles or groups are very targeted (access to a single computer) they are not “least privilege” | No |
Ultimately this means that with JIT in place, while administrators may be:
(+) authenticated on a time limited basis,
(--) their standing permissions are not removed and can be weaponized during an attack and
(--) during a JIT session, they are over-provisioned and have access to more than the resource they need to work on (“just-in-time access to everything”)
(--) the majority of users with admin access to a machine are hidden to PAM solutions
Hopefully this post pushes the thinking on JIT, dispels the myth that JIT equals PLP and clarifies that PLP is not achieved until standing privileges are removed.
To learn more about the risk of this hidden administrator access that resides on corporate endpoints, please visit this primer on the topic titled Standing Privilege - the unfair attacker advantage.
To learn more about how Remediant delivers JIT while removing standing privileges, please visit Remediant’s product page
Source:
2020 Gartner Critical Capabilities Report on Privileged Access Management: https://www.gartner.com/doc/3988410