Welcome to the latest of my Security Bytes posts, where I dig into areas of interest in Infosec/CyberSec, and offer my opinion.
In my last post, I talked at a high level about the history of computers and privileged access.
In this post, I want to get into a term you may hear a lot of if you work in Information Security, CyberSecurity or any Technology Risk role - Least Privilege.
What is “Least Privilege?”
It is properly known as the Principle of Least Privilege and is defined by CISA as:
The Principle of Least Privilege states that a subject should be given only those privileges needed for it to complete its task.
If a subject does not need an access right, the subject should not have that right. Further, the function of the subject (as opposed to its identity) should control the assignment of rights. If a specific action requires that a subject’s access rights be augmented, those extra rights should be relinquished immediately upon completion of the action.
Why does this matter?
“…even ignoring any security concerns, protecting yourself from mistakes that have serious consequences is worthwhile reason in itself I would argue.”
Why should I want to adopt Least Privilege?
Having “standing privileges” e.g. permanently assigned/active/enabled privileges carries several risks, not least of which are:
- Increased impact of mistakes - if you make a mistake and you are not privileged, the scope and impact of the mistake are much less than if you had privileged access at the time.
- Increased impact of any account compromise - if someone is able to compromise your account by cracking, gaining access to or somehow forcing a change to your password, the higher the level of privilege that account has, the more damage an attacker can cause.
So, even ignoring any security concerns, protecting yourself from mistakes that have serious consequences is worthwhile reason in itself I would argue.
The other aspect of that definition is the time-based aspect - you should only hold an elevated or privileged access for the period that it is required.
Historically this would have meant that when for example you change role within an organisation, or move onto a different project - any access that pertained to your old role should be removed - access should be recertified on a regular basis and your organisation should also have robust Joiner/Mover/Leaver (JML) processes.
Does every organisation have this in place? Maybe in large enterprises, but I would suspect that as you move down to Small to Medium sized businesses, the likelihood of that decreases.
Even if it is in place, is it operating effectively? Again, I would expect that it may vary quite widely from one organisation to another.
Modern, cloud based applications offer the ability to be very granular in terms of the privileges granted, through both built-in RBAC roles and the ability to quickly and easily define custom RBAC roles.
They may even offer a far more JIT (Just-In-Time) approach to privileged access.
Microsoft Azure cloud offers Privileged Identity Management (PIM) - this allows you to define which roles are permanently assigned to a user, other roles which are eligible to be activated for a period of time (which you can set to a maximum time of your choosing), and require both additional approval at time of activation, and also enforcement of Multi Factor Authentication (MFA).
Although other cloud services most likely offer the same capabilities, I’m sticking with Microsoft Azure here because that’s the only cloud service I’ve used to date.
That’s great, but what about non-cloud (on-premise) applications/OSes?
Whilst these features are very welcome, they still leave you with a number of blindspots:
- Does your on-premise network infrastructure support JIT privileged access, granular and easily configured RBAC, MFA, time-bound access?
- What about on-premise storage infrastructure?
- Applications?
What about the elephant in the room, operating systems?
Indeed, operating systems, as mentioned in my last post, have varying degrees of capability around Least Privilege.
Linux/Unix based systems have SUDO and sudoers files, but:
- Do you have the appropriate skilled people to administer it?
- Do you have centralised control over the provisioning of access, with recertification?
- Do you have monitoring and auditing to ensure that all changes to access are able to be tracked and alerts are in place for unexpected/unapproved changes?
- It is still standing privilege - there is no MFA or JIT/time-bound access.
Windows systems have a bigger challenge, whilst sharing the challenges of skills, centralised control, monitoring, auditing and standing privilege:
- Built in groups (RBAC) are less granular.
- Configuring more granular privilege requires deeper OS knowledge and those privileges can be difficult to audit.
- By default, Windows Server licencing allows only 2x Administrators to login to a server - any other user requires additional CALs (licences) - so people may either end up being inadvertently non-compliant with Microsoft licencing, or providing overly-permissive access e.g. Administrators group access.
- Microsoft has made some attempts to improve this with the introduction of Just Enough Administration (JEA) which allows delegated administration via Windows Powershell - though this does require skills and effort to setup and maintain JEA roles.
- People are used to working in a point and click desktop GUI - they are used to logging into servers like they would their own PC (I’m not saying I agree with this - more on this in the next post in this series).
- Applications and software developers are used to developing and releasing applications written to require Administrative privileges - Microsoft themselves even do this in their own applications. How many times have you had an application state that it requires Local Administrator on the server, SystemAdmin (SA) on a SQL server, Domain Administrator in Active Directory etc? Security product vendors can be some of the worst offenders here…
Summary
I’ve covered (at still pretty high level) the basics of Least Privilege and some of the challenges.
I’m going to stop here - in my next post in this series, I’ll explore common approaches taken/tooling used to address some of the challenges mentioned, and some of the issues with those approaches/tooling. I’ll also explore how the interaction with budgets and project delivery can further exacerbate these issues.
When I wrap up the series, I’ll share my opinions on the best approaches that organisations could take to improve their privileged access management position and security posture. I’ll also share my view on where software vendors could help their customers improve their security posture and reduce their risk exposure.
As ever, thanks for reading and feel free to leave comments down below!
If you like what I do and appreciate the time and effort and expense that goes into my content you can always 