I’ve been employed as a security professional for over 20 years. I cannot possibly count the number of times I have uttered the words “least privilege”. It’s like a little mantra, sitting on the same bench as “defense in depth” and “insider threat”. 

But telling someone to enforce least privilege and walking out of the room is the equivalent to the doctor telling you to “eat healthier” while failing you on your insurance physical and walking out of the room before over-charging you.

Least privilege is real. It matters. Unlike changing passwords every 90 days, it can have a material impact on improving your security. 

Least privilege is also really hard. Especially at scale. And it doesn’t work for your most important users. 

Why? Because least privilege isn’t the least privileges you need at that moment, they are the least privileges you might ever need to do your job… ever. And when someone needs to do something out of scope from when those privileges were first mapped it kicks off a slow change process that has to cross different teams and managers.

Or sometimes you just have to talk Bob into giving you access. And Bob is kind of a defensive jerk since he doesn’t trust anyone and doesn’t want to be blamed when you screw up.

Even with least privilege, if an attacker gets those credentials (the primary source of cloud native breaches) they can still likely do mean things. Because although least privilege isn’t always too horrible to implement for the average user or employee, it’s really hard to enforce on developers and administrators who, by design, need more privileges.

Just as we have MFA for strong authentication, we need something for strong authorization.

This is where Just in Time (JIT) comes into play. Instead of trying to figure out all the privileges someone needs ahead of time, they can request time-limited permissions at any point in time. I now believe that JIT should be the standard for administrative and sensitive access. 

I recommend that least privilege is a great concept for general user access, but JIT is better for any level of admin/dev/sensitive access in cloud.

Just in Time

JIT is a flavor of PIM/PAM. Privileged Access Management and Privileged Identity Management are systems designed to escalate a user’s privileges. They operate with a lower level until they need to escalate and these systems use multiple techniques to provide expanded access, usually for a time-limited session. Today isn’t the day to get into the nuance, but the advantage is they allow for flexibility while still maintaining security. Someone must request additional privileges when they need them, so even if their credentials are compromised the attacker is still limited.

“JIT” (Just in Time) is one technique for PAM/PIM (or, really, any access). A user has base credentials that might not have access to anything at all, and then their privileges are escalated on request. We use JIT ourselves (and it’s available in Cloud Defense), and Netflix released an open source tool called ConsoleMe based on their internal tool. Azure has a built in (but for an additional fee) service called Entra ID Privileged Identity Management. (Entra ID is what we used to call Azure AD before someone decided it was a good idea to confuse millions of customers for branding purposes) There are more options, these are just examples.

To enhance security, JIT needs to use an out-of-band approval flow and provide time-limited access. Those are the basics. The request and approval should flow through a different path than the normal authentication, like a form of MFA. The difference is that MFA is an out of band factor for authentication (proving you are who you say you are) and JIT is a form of authorization (you request and receive permission to do something). 

Managing Friction

Both least privilege and JIT introduce friction. I mean, everything we do in security introduces some kind of friction, especially Bob. With least privilege the main friction is the overhead to define and deploy privileges, and what breaks when someone doesn’t have privileges they need. With JIT the friction is the process of submitting and receiving an approval.

Having used and researched both least privilege and JIT for a long time, I’ve learned techniques to reduce the friction. In some cases you end up with faster and better processes than how we’ve historically done things

• The request and approval flow needs to be real time. This means approvals via ChatOps, text messages, or the 5G chip implanted with your COVID vaccine.
• For lower-privileged access, like read access to some logs, you can and should support a self approval. How does this help? Because it still uses the out of band process and reduces the ability of an attacker to leverage lost/stolen/exposed credentials.
• You can also support auto-approvals where you don’t even need to click over to self approve. How does this help? You can auto-approve but also use your out of band channel to notify that privileges were escalated. You’ve probably seen this if you ever add a Netflix or Hulu device to your account. Awareness alone can be incredibly effective.
• If this is for developers, you need to support the command line and other tools they use. Go to them. Make it super-easy to use. If you force them to log into a security tool the project will fail.
• If approvers aren’t responsive, like instantly, you will fail. Don’t make Bob the only approver.

Bring the capability to your devs/admins in the tools they already use. Make it fast and frictionless. Ideally, make it easier and faster than opening up a password manager or clicking around an SSO portal stuffed with 374 cloud accounts to pick from. Buy Bob some cookies. Chocolate chip. (Oh wait, that’s me).

You can also use automation to reduce friction for least privilege access. The Duckbill Group implemented their own version of automated least privilege using different tech with the help of Chris Farris. Tools like AWS Access Advisor are there to help you monitor used permissions and scope them down. Automation is there to help you implement least privilege at scale, and can also be an adjunct to JIT.

When to use which

Least privilege isn’t a dead concept by any means. It’s still the gold standard for everyday users/employees that need a pretty consistent level of access. JIT is best for more-privileged access, especially to production environments, and especially in cloud where credential exposures are THE biggest source of breaches. Here’s where we use it ourselves:

• Developer read access to production.
• Developer change access to production (outside CI/CD). Far more restricted with more approvers required.
• Admin access to prod accounts.
• Incident response access.
• Some dev account access, since it can be faster than going back to the SSO portal, especially when working on the command line.

I no longer think least privilege alone is a valid concept for any significant level of privileged access in cloud (IaaS/PaaS), even when we use strong MFA. It’s too hard to properly scope permissions at scale, over time. JIT is a far better option in these use cases. Least privilege is still very viable when consistent permissions over time are needed, especially combined with good access logging and MFA. JIT is the companion to MFA. It’s the strong authorization to pair with your strong authentication. As we continue to move more critical operations into management planes that are exposed to the Internet, JIT is the way.

*** This is a Security Bloggers Network syndicated blog from FireMon.com authored by Rich Mogull. Read the original post at: https://www.firemon.com/on-least-privilege-jit-and-strong-authorization/