This post is part of a series on Just-in-Time (JIT) Access.
Read: Part I | Part II | Part III
Welcome back to this blog series on Just-in-Time (JIT) access. In part 1, we discussed what Just-in-Time access is, and where it fits into PAM strategies. In this part, we’ll take a look at the different approaches to Just-in-Time access that vendors take.
The approaches that we’ll look at are:
- Privilege Elevation and Delegation Management (PEDM)
- JIT Provisioning
- Zero Standing Privileges (ZSP) Approach to Privilege Elevation
Before we look at Privilege Elevation, let’s remember two things from part 1, which are the elements of privilege that we should look to control:
- Scope – Just Enough Access
- What systems of applications can the user access?
- How much privilege does the user or application requirements in order to perform its function?
- Time – Just-in-Time
- When do they need the privilege?
- How long do they need it for?
Privilege Elevation
Privilege elevation, PEDM, least privilege, or whatever other name you may know it by, is really about allowing users to log on to systems using standard user accounts and elevating applications, tasks, or commands that the user runs so that they do not require administrative rights. Usually, these privilege elevation solutions can work with both Windows and Unix/Linux, and typically require some form of the client to be installed, which performs the elevation.
Now this sounds pretty ideal, right? We remove administrative rights from users, elevation applications, or commands that they run, which means we can control the scope of elevation and the time. So what’s the catch?
The problem here is that elevation tools rely on policies or rules. These must be created upfront, and although some of these PEDM solutions have learning modes and quick-start templates, this can be a time-consuming exercise. These policies are always applied to the user, so if the user’s workstation gets compromised then an external or internal threat actor has the same level of elevation.
It’s called “standing privileges,” and whilst it may not be as much privilege as if the user was in the local administrator group themselves, it’s still a privilege and therefore still a risk.
JIT Provisioning
A common approach emerging to combat standing privileges is Just-in-Time provisioning.
Just-in-Time provisioning can work in a number of ways, either provisioning of accounts, provisioning or group membership changes, or provisioning of ephemeral tokens. To keep things simple, we’ll focus on the provisioning of group membership changes, which is the most common approach.
What this typically entails is a user going to a web portal and requesting access to a machine, at which point they are added into an administrative group on that machine for a pre-defined period of time.
With this approach, you can certainly control the time element and, to a limited degree, you can control the scope. Why is this limited? Well, in Windows operating systems you’re fairly limited in terms of local groups. Generally, you’re either an administrator or user. When you drop a user into the administrator group, they’re an administrator regardless of whether you’re controlling how long they have this access for. It’s still a window of opportunity and a window of risk.
Deployment Options
There are also two deployment options:
- Vault-less & agent-less
- Agent-based
Vault-less and agent-less may sound great. Since you typically don’t need to worry about installing agents to do enforcement, you don’t need to worry about vaulting credentials. So how does it work?
The user logs in to a central management web interface and requests access to a machine. The software solution will reach out to that machine, run a remote command and then add the user to an administrative group and then remove after the request has been completed.
In order to do that, it must require a privileged account on that system in order to run the command. Whilst it seems like an attractive solution, what it is actually doing is making you create lots of unmanaged privileged accounts because the solution doesn’t contain vault or rotation capabilities.
If we turn our attention to the agent-based approach, we need to ask ourselves:
- How is the agent authenticating itself to our platform?
- What service account is the agent running as?
- Can the users interact with the agent to stop it?
- Is there kernel-level integration? If so, will I likely see conflicts with other endpoint protection software on my machine?
- Can I control the scope of privilege as well as time?
This post is part of a series on Just-in-Time (JIT) Access.
Read: Part I | Part II | Part III
