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:
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:
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.
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.
There are also two deployment options:
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:
This post is part of a series on Just-in-Time (JIT) Access.
Read: Part I | Part II | Part III