Like any (hopefully) good theory I keep evolving it over time as I work with more companies and talk to more people. I’ve been using it a ton over the past couple years in my speaking and training, especially as I’ve been pulled into more governance scenarios. Time and time again the major problems I run into aren’t so much technical, but organizational. Yes, there are many MANY technical complexities to cloud security, and they can and do result in breaches, but in my experience the governance issues far outweigh the technical ones. 

Good governance can’t patch a zero day, but bad governance means the attacker never needs one.

The core of the theory hasn’t really changed, I just keep working on better ways to explain it. I also decided to trim it down slightly. Here’s how I currently plop it onto my slides:

• Cloud decentralizes operations and infrastructure
• But cloud unifies all administrative interfaces
• And puts all admin portals and resources on the Internet, protected with a username and password

Going back to the previous version the changes are small but also big:

• Cloud has no chokepoints, and thus no gatekeepers.
• All administrative and management functions are unified into a single user interface that is on the Internet.
  • Protected with a username, password, and, maybe, MFA.
• Technology evolves faster than governance.

I still use the “no chokepoints and gatekeepers” in my talk track but I found that it’s a longer way of saying “decentralized”. The fundamental issue is the independent control of the full stack outside of centralized infrastructure. That a dev or app team can build and manage all of their own infrastructure in their own environment with just a credit card. Now there are still some dependencies and controls, especially in the data plane or when you need to tie back into networks, but that doesn’t change the primary point.

Trying to completely recentralize is rarely going to work.

Next, I didn’t really change the unification of administrative interfaces. To expand, we decentralized all the infrastructure and control at the deployment level, but everyone, in the world, uses the same web console and API endpoints. 

Attackers have one gateway to infinite targets.

Then I took the sub-bullet from version one and made it bullet 3. These admin portals are all on the Internet, and by default use little more than a username and a password. All resources are also one setting away from being on the Internet, just ask all those S3 buckets and ElasticSearch clusters.

It really is that simple. Teams manage their own stuff independently. They all, around the world, use the same web portals and API endpoints. And any idiot with the right credentials can poke and prod at the back end of your “datacenter”.

Now the crazy part; this was all laid out in 2011 in NIST 800-145, the 2 page NIST Definition of Cloud Computing. That defined the five essential characteristics of cloud computing as:

• On-demand Self Service
• Broad Network Access
• Resource Pooling
• Rapid Elasticity
• Measured Service

Take the first three points and we have:

• Teams manage their own stuff
• It’s all on the Internet
• And all based on collective resource pools

Alright, so what does this all mean what do we do?

Accept it.

That’s the first step. Understand the problem and use it as a lens to devise our solutions. As I wrote recently in my Strong Authorization post:

Because they aren’t used to everything (potentially) being on the Internet. The entire management plane is on the Internet, so if an attacker gets credentials, you can’t stop them with a firewall or by shutting down access to a server.

Start there. Accept the base reality. What can we do to reduce that risk? To reduce those attacks? I think the most impactful choice is to focus on IAM, and the intersection of governance and IAM. Who do you have manage permissions? Access? What security controls can prevent, detect, and correct IAM related attacks? What are your processes around IAM? Do your incident responders know the deep ins and outs of the IAM for your given cloud provider(s)? Do you use JIT/Strong Authorization? How do you manage IAM for contractors and external services?  

Start with your IAM governance and processes. Then choose and use technologies to support them. This is the single most impactful way to improve your cloud security. I really hope I’m not the first person to tell you that.

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.