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 what Least Privilege actually is.
In this post, 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.
So how do I implement Least Privilege?"
How indeed! Well first of all you would be well served by adopting a baseline security policy - often referred to as a Secure Configuration Baseline (SCB)
Secure Configuration Baseline (SCB)
Secure Configuration Baseline- A fully documented set of agreed security configurations to enable the secure by default deployment of particular infrastructure components, operating system, middleware component or application.
It’s pretty much a first principle - what does good look like?
Now you may be wondering what an SCB has got to do with Least Privilege - and for me it’s clear, part of what an SCB entails is to configure an application/operating system/platform securely.
Does any of the following sound secure to you?
- Application requires users to login to the server desktop rather than using a User Interface (UI) to access the application remotely from a client machine.
- Application must run with administrative privileges at all times for all tasks
- Application requires Domain Admin privileges (at all, but especially at runtime, for all tasks)
Those are just a few examples, there are a myriad other examples of what bad looks like, but the point here is to focus on configuration based on agreed best practice for what good looks like.
There’s several sources you can use for this, some common ones are:
- NIST (National Institute of Standards and Technology) in the United States maintains a [National Checklist Program Repository]https://ncp.nist.gov/repository) - this details SCBs, Security Technical Implementation Guides (STIGs) etc
- NISTs Cyber Security Resource Centre (CSRC) also maintains a Security Content Automation Protocol (SCAP) which “is a method for using specific standards to enable automated vulnerability management, measurement, and policy compliance evaluation of systems deployed in an organization”
- Center for Internet Security (CIS) also maintains a number of Security Benchmarks
There are many others out there but what they all provide is a detailed configuration for a number of operating systems, applications etc that provide a secure by default position e.g. a picture of what good looks like.
That doesn’t mean of course that just following these is enough to ensure that your systems are secure and that you cannot be breached. But it does give you a good foundation on which to build.
Reporting
I know, that sounds boring, but you need to be able to know what systems you have and that they are compliant. You also need to know when a system is or moves out of compliance with your security policies.
Again there are several Vulnerability Assessment products in the market that would be able to help you do this, including:
- Qualys
- Tenable
- A full list of products in this space is available from Gartner
- As a smaller organisation with a restricted budget, you may also be able to leverage OS and platform features to aid you in this monitoring/reporting.
Use Cases - Know your users and applications
Now you know what good looks like, you may have, for example, a group policy that only allows members of the Administrators group on windows servers to be able to login to a server.
On the face of it, this sounds like all you would want right? Why would your users, developers, application support staff etc need to login to servers directly, they just use applications right? Only system administrators (sysadmins) would need to login to a server… Park that thought for now, I’ll come back to that shortly.
So what do I mean by use cases then?
- What is the role being performed? (developer, user, application administrator, database administrator etc)
- What systems need to be accessed to perform that role? (database server, application server, network router etc)
- Where do those systems need to be accessed from? (corporate desktop in a corporate network, corporate laptop from a public network etc)
- What is the minimum amount of access required to perform the role? (standard user, user access administrator, system administrator etc)
- How long is the access required for? (During a project, when in this job role, when deploying an application etc)
That should build up a profile of sorts of the types of users you have, and what activities they need to perform, how to perform them and the tools and access required to do so.
Roles and Responsibilities
It’s also important to know who should perform the roles mentioned. That sounds like an obvious requirement, but it is often overlooked, with several people/teams having the same access to the same systems.
For one thing, you should only give access to responsible, knowledgeable people - you’re not going to give the office junior the administrator password to your most critical system!
This leads into something known as Segregation of Duties (SoD):
Separation of duties (SoD; also known as Segregation of Duties) is the concept of having more than one person required to complete a task. It is an administrative control used by organisations to prevent fraud, sabotage, theft, misuse of information, and other security compromises.
There’s a few reasons why that matters:
- Reducing errors - if more than one person is required to be able to complete an action then that allows for others to review their work for errors before moving to the next stage of the process
- Reducing the risk of fraud - for example if you consider a cheque processing system, no one person should be able to request a cheque be issued, authorise the printing of the cheque, issuing the cheque etc. They should also not be able to issue a cheque to themselves.
A common methodology for this is to produce a RACI Matrix:
R = Responsible Those who do the work to complete the task.
A = Accountable The one ultimately answerable for the correct and thorough completion of the deliverable or task. In other words, an accountable must sign off (approve) work that responsible provides.
C = Consulted Those whose opinions are sought, typically subject-matter experts; and with whom there is two-way communication.
I = Informed Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication.
So once you have all the information above, you just then need to map out those roles, assign the roles and the access only to those who need them, remove when no longer needed and you’re golden, what’s so difficult?
Challenges
There are a plethora of issues that can arise, that make Least Privilege less than trivial to implement and maintain.
I’m going to break them down by their core categories below.
Skills / Knowledge
Resourcing
DO YOU HAVE ENOUGH SKILLED PEOPLE IN THE RIGHT ROLES??
I’ll say that again - DO YOU HAVE ENOUGH SKILLED PEOPLE IN THE RIGHT ROLES??
If you have more work to be done than you have people to do it, they will be under pressure, stressed and will either not do their best work (make mistakes, compromise on quality) or they will be pressured to make poor choices to meet a desired delivery cadence.
Technical
In any organisation, you are only as good as the people that you have working for you. So if your staff don’t know enough about a system to secure it adequately, you may well end up with either an insecure configuration to begin with, or it may deviate from that over time.
Business Processes
Similarly, if your business users don’t know enough about the processes they follow/systems they use and why they do what they do then this can introduce a number of risks, probably the most serious of which are following processes without understanding why they are being performed, for what outcome, and how those could be amended to improve efficiency (e.g. through increasing automation).
Culture
A culture can make or break a company, and can be a huge differentiator in the security posture of the company. For example, do your staff seek to start with the least privilege required to perform a task, or jump straight to “I need Admin rights”? Do they store secrets/passwords securely? Do they actively look to give up access they no longer need, or hoard them?
Budgetary Constraints/Deadlines
Most organisations will have budgetary factors to consider in all aspects of their operations:
- IT Infrastructure/Software Budget
- Security Infrastructure/Software Budget
- Staff/Resourcing Budget
- Project Delivery Budget
They will also have deadlines to meet that may include:
- Financial (delivering a product within budget)
- Marketing (getting a product to market in an agreed time to capitalise on an opportunity to gain commercial advantage)
- Regulatory (implementing regulatory controls within a timescale set by a regulator)
Vendor/Technology Capability
Does the vendor have a secure-by-design mindset? Do they deliver products which default to requiring administrative privileges for most actions? Do they provide RBAC/granular privilege features/frameworks that are easy to integrate and adopt quickly/easily?
Technical Debt
Are you a startup, able to design everything from scratch? Are you an established business with infrastructure and applications that may stretch back decades? How quickly can you effect change that affects large parts of your organisations’ infrastructure?
Perfect Storm
Whilst the above is a very small list of factors to consider, hopefully you can see how this can quickly get to a position where despite least privilege making perfect sense, it is seldom implemented as widely, and consistently as it should be.
If you don’t have the resources, the knowledge, the budget or the time to do it right, will you?
What do you think would win in your organisation? A security control or a project deliverable?
That’s not to say that your security professionals should allow any old thing - or block every less than perfectly secure application/configuration/product.
There is always a balance to be struck, in accordance with your Risk Management team.
However, as it stands, most organisations struggle to do this right consistently, ending up with overly privileged users that have standing privileges (e.g. they are permanently active on the user account). Those users frequently also have poor privileged access hygiene - exercising poor judgement and poor practices when operating in those highly privileged roles.
By that I mean things like, but not limited to:
- using privileged access where not required
- leaving privileged sessions logged in when no longer in use
- improperly handling/storing secrets (passwords, keys, certificates)
Summary
That was, again, a fairly whistle-stop tour of how you might implement least privilege and also why it often doesn’t happen.
I’m going to stop here - in my next post in this 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 