Attempted Murder of a Sacred Security Cow

Questioning a basic tenet of Security

I’ve been thinking a lot about Identity lately. It’s part of the Zero Trust philosophy, it’s a fundamental element of security, and it was Identity Management Day on April 12. While noodling on the topic, my thoughts turned to the principle of Least Privilege (PoLP): what it is, how we manage it, why we use it.

The principle of least privilege is a best practice governance concept in which a user or a process is granted the exact and minimum privileges necessary to perform its function.

I remember being an identity administrator, and how difficult it was to make sure that this principle was enforced. I remembered how much time it took for managers, appdev teams, and the identity team, to manage Least Privilege through the access lifecycle (onboard, special projects, transfers, promotions, certification, offboard, re-onboard…). I was thinking about how we are all trying to make security less about user friction and unnecessary overhead and more about user enablement. And I was noodling on what would happen if we did NOT enforce Least Privilege. So, as I always do, I turned to social media for their thoughts:

The good news: I was correct — it is a VERY UNPOPULAR opinion.

The bad news: although some people were willing to try to see how I reached this conclusion, many dismissed it out of hand. I was surprised at how much attention and emotion this tweet generated. This is the most liked response:

I found the people who seriously engaged with the topic on Twitter and LinkedIn had interesting and informed reasons for their opinion. Here’s what I learned:

Those in Favor of Least Privilege

There were lots of them! Here was some of the thinking:

• Elevated access should be temporary, supported by an approved business case. Plus, it’s easier to know who should have access, than who shouldn’t. “‘Who need access’ can be enumerated. ‘Who doesn’t need/shouldn’t have access’ cannot.”
• A well designed architecture makes managing PoLP easier “A lot of it comes down to how good your defaults and the role definitions (membership, privileges) are to begin with. Done right, you’re managing most of things at most once across an organisational unit.” Also, just because it’s difficult to do doesn’t make it not worth doing
• Not doing PoLP is also hard “…seems ripe for mistakes and accidental disclosures. How do you prove access was indeed required vs. missing it?”
• PoLP is more scaleable than the alternative: “Having done IAM for a global bank, and supporting well over 100k users, I think it’d be a nightmare to figure out who shouldn’t access specific resources vs the few who need access to specific resources. I definitely wouldn’t want to do that for the thousands of resources.”
• As long as users act insecurely, we need PoLP. “Allow LP by default and I won’t even have to phish”
• Having PoLP limits the attack surface, by making it harder for attackers to get access to stuff after an account has been compromised. For incident response “whitelisting and RBAC is more effective than blacklisting”

Those who are open to Questioning the Value of Least Privilege

There was significantly less of them, and most weren’t 100% in favor of my suggestion, but were open to “it depends”:

• PoLP bumps into Least Resistance, usually by the business. This then puts burden on the IAM team to manage approved and unapproved exceptions, a cumbersome re-certification process, or failed audits. “Security Theater is just as much about the stories we tell ourselves.”
• If your risk assessment and controls support PoLP, or removal of it, why not? Best practice isn’t required. “… most organizations are leaning towards excessive permissions, even when there’s no clear business justification.”
• Some resources may not need PoLP (“internal resources, documents, diagrams”). Others may. Having a one size fits all may not be optimal
• Where access is one person, one host, PoLP makes less sense “Restrict Admin priv made sense in the mainframe, multiuser on 1 system days when hosing admin would affect hundreds of users. Not as important now.”
• Does size matter? “I feel like there’s a tipping point in terms of organizational size and number of accounts/endpoints/resources where default deny with manual intervention for exceptions becomes less overhead than default allow with exceptions.”

What surprised me most about the conversations that followed my post was not that people disagreed, but that people weren’t willing to even engage in thinking outside the box (to be fair, I didn’t post is as a hypothetical, and adding #FightMe didn’t set the right tone). I respect the people who said “help me understand” or “explain further”, and I appreciate the people who said “I disagree, and here is why”.

I also found it interesting how siloed much of the thinking is. People who say “PoLP design is hard but maintenance is easy” need to spend time with the IAM teams whose job it is to work through maintenance issues every day. People who think automation and AI will solve for this haven’t considered how few of our architectures are set up to allow for automation, and won’t for a long time. From where I sit, everything looks great! doesn’t mean that across the community everything is great.

Security is more an art than a science, and if we’re not willing to examine our preconceptions, I fear that we will miss important advances in our profession. We continue to struggle with the same issues, over decades. When this happens, as it is with PoLP, it would suggest that our bedrock principles need revisiting. Not because PoLP is not working at all (it is) but because it is not working as well as it should. We need voices in the community who continue to challenge the status quo, and find new ways of doing this important work, and we need people who are intellectually curious enough to go on that journey, too.

-April 2022