Opinions expressed are solely my own and do not express the views or opinions of my employer
The principle of least privilege is one of the most fundamental and important concepts in security. It’s seen at times as the holy grail — everyone wants it but sadly it is beyond reach of mere mortals and even the most mature security programs due to the effort and complexity involved; end users usually hate it because undoubtably they will no longer be able to access certain non-essential apps, tools, resources and networks, while most auditors would view it as absolutely essential to the success of an organization with limited understanding of how hard it is achieve within a complex organization.
The benefits of implementing least privilege are readily apparent to all security practitioners from minimising attack surface (and particularly the insider threat surface), reducing impact regulatory compliance (more on this later), better stability, limiting damage that can result from accident, error or compromised credentials.
So what is the Principle of Least Privilege?
The first mention of the ‘Principle of Least Privilege’ supposedly occurred in a paper by J.H. Saltzer and M.D. Schroeder in 1975. I wasn’t born yet, but sources indicate it was originally intended as a design principle and is now used broadly across a variety of security scenarios, most commonly identity and access management and information classification (i.e. a need to know).
Least Privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. ~ SALTZER, J.H. and SCHROEDER, M.D. ‘The Protection of information in computer systems in computer systems’, Proceeding of IEEE, vol. 63, no.9
Forgotten principle? You must be joking — Everyone knows it
You’re right — despite being over 40 years old, this definition is probably as easily recognisable to security practitioners today as it was when first written.
Unfortunately, in my opinion, the definition that is most commonly remembered by CISO’s and auditors, usually ignores the concept of time that was introduced into other subsequent variations of the principle. I personally like the variation presented by Gary McGraw and John Viega that includes the concept of limiting the amount of time that the privilege is available.
The principle of least privilege states that only the minimum access necessary to perform an operation should be granted, and that access should be granted only for the minimum amount of time necessary. IBM developerWorks, ‘Software Security Principles: Part 3’ (October 2000) URL: http://www-106.ibm.com/developerworks/security/library/spriv.html?dwzone=security
It’s this concept of time and the principle of limiting access to only when it’s required that is most frequently forgotten.
Determining Least Privilege is really hard
In principle (pun intended), the idea of determining the least privilege for every digital identity (machine and human) is pretty easy to understand and sounds pretty simple to implement, just make sure you only give privileges to those who need it to perform their job — right?
Unfortunately determining what privileges are needed is one of the most difficult tasks in security, let alone doing that at scale across an organization with years of privilege creep. Let’s explore this in more depth for a minute — how do you know when an identity needs the privileges to perform a certain job ?
- Is it because they tell you they need it? Most definitely not — for obvious reasons.
- Is it when someone is approved to have it? Does it matter who approved and what if that approval was 2 years ago or only to perform one task — unfortunately as we’ve seen from the story of the The Hungry Caterpillar, privileges accumulate and change over time without the proper management and needs change over time too.
- What about if they have never used it or only used it once? Is it still needed?
- What about if they need it once a year or only in an emergency?
- What if another seperate identity performed the job instead?
Like I said, it’s actually really hard to figure out a definitive measure of least privilege, particularly when you consider time in the equation.
Treating least privilege as a process
So instead of trying to find a definitive measure of least privilege, I urge you to consider implementing least privilege as a process — where additional privileges necessary to perform an operation on a specific resource are granted on request, and the privileges are granted only for the minimum amount of time necessary for the specific resource before being revoked. This should sound familiar when you consider the forgotten principle of limiting least privilege to only when required.
This dynamic approach will by necessity require steps to:
- Monitor what privileges are actually used or attempted to be used and what resources they are used on, by comparing logs and identity activity to privileges and figure out what privileges are actually used every day.
- Remove any inactive identities or remove any associated privileges from those identities that have not been utilised for an extended period of time.
- Identify privileges that are only needed for short periods at a time, and implement workflow and automation to provision expiring privileges for only the period required.
- Remove identified unused privileges from all other identities that have not been utilised for an extended period of time.
- Implement on-demand or just-in-time processes to rapidly (and potentially self-service) elevate privileges on specific resources where required to reduce impact of restricted privileges.
- Investigate any abnormal activities by identities, and particularly unusual usage or attempted usage of privileges and where possible — auto remediate.
Ideally through the ongoing changes envisaged by these processes, you will continually reduce permanent privileges assigned to both human and machine identities over time.
Regardless of whether you adopt a more dynamic approach to implementing least privilege as a process, hopefully this post has at least convinced you to revisit the principle of least privilege and think about how you’ve interpreted it and whether you have some potentially over-privileged identities as a result.
Check in again soon for more blog posts focused on privilege management — particularly in the cloud.