A Client-based Approach for Least Privilege, Just-In-Time Access

In this blog, I want to talk about “Just-in-Time” access and how a client-based approach (versus client-less) to privileged access security is the gift that keeps on giving. Not only is it essential in driving down risk, operational overhead, and cost, but it also aligns with modern best practices such as Zero Trust. As such, it’s an essential element of your security strategy.

Just-in-Time Access for better risk mitigation

Just-in-Time (JIT) is a term you’ll hear from many Privileged Access Management (PAM) vendors used in the context of a best practice—the Principle of Least Privilege (PoLP). With a proper least privilege approach, your admins have zero administrative rights. Thus, they need some means of obtaining elevated rights only when the need arises. JIT access allows them to do this, facilitated by a self-service request/approval workflow.

So, what does JIT buy you? Simplistically, if you graph out risk over time for a typical administrator, you might see something like this.

Looking at the risk axis, which one would you prefer—the blue or the orange?

If you’re not subscribing to a least privilege access security model, your risk will be more like the blue (“No PoLP”) line. It makes sense, right? Superuser accounts available anytime for routine use by admins = standing privileges, more attack vectors, bigger attack surface, unfettered access = greater risk, except, perhaps, at lunchtime.

Contrast that with the red (“PoLP”) line. This is a much lower overall risk, more representative of a least privilege approach to security. Here, privileges are fluid and continuously low, only elevated when required and approved, and automatically choked back down to a least privilege state after use. Also, note each risk spike peaks much lower. With least privilege, you don’t hand over the proverbial keys to the kingdom. You constrain the rights to a subset necessary for the task, e.g., DB maintenance, web administration, or application installation, and thus, the risk is never constantly high.

This least privilege approach incorporating JIT access can be a powerful tool in your arsenal to help combat identity-based data breaches. I say “can be” because there’s a right way and a wrong way. Choosing the wrong path—while mitigating some risk—will still leave you overly exposed.

JIT Access the wrong way, without clients

Logged into a password vault, the user requests additional permissions to access server X and run privileged applications. After approval, the vault logs into system X with a vaulted local administrator account and provisions a brand-new temporary administrator account for the user on server X, just in time. The user can then log in with this new account, do her job, and log out. Sometime later, the vault logs back into System X with the local administrator account and removes the temporary administrator account.

Let’s dissect why this is not ideal.

1. The vault is not scoping privileges based on what the user needs to do on system X. The temporary admin account is unfettered, allowing the user to do whatever they like beyond what is reasonable for the task at hand.
2. Each new temporary account is a new attack vector, increasing your threat surface. They’re typically added to the local or domain Administrator group on Windows or wheel group on Linux. If compromised, they give a bad actor complete ownership of that system with the potential to move laterally to other systems in the network.
3. The vault and the target system have no managed association. I.e., there’s no trust relationship or mutual authentication enabling system X to verify that the vault is a legitimate, trusted actor. We wouldn’t fault intrusion software ringing alarm bells to warn of an external threat actor creating a command-and-control backdoor admin account. Is this friend or foe? Who created the account? How can we trust it?
4. This approach does not align with PoLP, Zero Trust, zero standing privileges, or other modern best practices founded on least privilege. With no explicit policy enforcement point on server X, there’s no way to constrain user permissions, scope elevated privileges on a per-command or per-application basis, or enforce MFA policies at login and privilege elevation.

PAM solutions that employ this method of JIT access—while highlighting “simplicity” and “agentless”—are far from ideal. 

JIT Access the right way, with clients

The right way begins with a solid PAM architecture. A hub and spoke model implementing a centralized Policy Definition Point (PDP) with distributed Policy Enforcement Points (PEP) on each endpoint is an ideal design to accommodate modern distributed IT infrastructures (see NIST SP 800-207 Zero Trust Architecture). This provides the endpoint PAM intelligence necessary to overcome the challenges outlined above and sets you up for incremental value beyond JIT access.

Implemented as a thin PAM client on each system, the PEP enrolls the system in the PDP, obtaining a unique “machine identity” and establishing a trust relationship with mutual authentication. With this foundation, benefits include:

1. No dependence on temporary local administrator accounts for privileged access, reducing your attack surface. Users request only the roles they need for the job at hand – just in time – with the PAM client strictly controlling and constraining local access and privilege. If a bad actor compromises the admins’ enterprise account, its implicit low privilege limits the blast radius and prevents lateral movement.
   
   Added value: By enforcing MFA at login and privilege elevation, the PEP client can validate that a legitimate human user is at the keyboard versus a bad actor or malware. Also, with a brokered identity capability, you can support login IDs from any source (e.g., Active Directory, LDAP, Okta, or Google Directory).
2. With the PAM platform as a root of trust, you can distinguish between friend and foe, eliminating false alarms. The PAM client validates policies are from a trusted PDP instead of a rogue system for login, privilege elevation, and MFA.
   
   Added value: When the system wants to consume vault services (e.g., a DevOps app checking out credentials or secrets), the vault can also trust the endpoint, enforce roles and policies, and scope access to specific vault APIs and vaulted items such as secrets and passwords. Also, per-application service accounts can be eliminated.
3. This approach aligns with Zero Trust and zero standing privileges best practices, enforcing a least privilege accesses security model that ultimately drives down risk and aids regulatory compliance.
   
   Added value: As more regulations and guidelines are aligning with these best practices, client-based JIT access and privilege can result in a more robust compliance posture.
   
   
4. With the PAM client as a trusted PEP on the host, you can leverage it for more advanced PAM capabilities, such as real-time password reconciliation, delegated machine credentials for DevOps, and brokered authentication.

In our latest Delinea Server Suite release, we add even more value, conquering a sizeable challenge plaguing anyone using Active Directory to store PAM policies. Because of inherent policy replication delays in Active Directory, it can take minutes or even hours before PAM policy updates reach each system/client, making “just in time” ineffective. Without any modification to Active Directory or its schema, Delinea PAM can now update both Active Directory and its PAM clients simultaneously, ensuring that requested permissions are available for administrators as soon as the request is granted.

I hope you see the value that a client-based approach to JIT privileged access security brings to the table. With the average total cost of a data breach being USD 3.86M, this combination is also a business imperative.

For more information on Delinea Server Suite, please see our datasheet.