Security Bytes: What is Least Privilege and why you should care about it - Lets fix this

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 about the many challenges of implementing Least Privilege. You may have been forgiven for thinking this is all just too hard to do right from day one, or to rectify from your current situation.

In this post, 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.

Where Do I Start?

Whether you’re starting out from scratch in a startup, or looking to undertake a program to improve your security posture and privileged access management (PAM), a lot of the basics and approach remain the same.

First Principles

As I mentioned in my last post, to know what your problems are and where to target your efforts to resolve them, you need to:

1. Acquire and review Secure Configuration Baselines for your platforms - on-premise and in the cloud.
2. Scan for compliance against those SCBs (using 3rd party tools - not all of them need to cost the earth).
3. Establish where you have exceptions to the SCB, raise with risk management to ensure these are on their radar, and the impact and likelihood of the risk materialising (this needs to be digestible by non technical staff/leadership)
4. Where the risk is deemed too great, target those for remediation first
5. Create exception configurations to allow selective exception (example, User Account Control in Windows should be enabled by default, but you may come across legacy applications written in such a way that UAC being enabled will break the application).
6. Track those exceptions and ensure that appropriate access control/governance and recertification/monitoring is in place to ensure that the exception doesn’t became the norm.
7. Map out your users, the roles they have, the applications they use, the access they have to them and from that extract out a set of common use cases that, by producing a design pattern for that use case, you would have an easily repeatable configuration/deployment, that by rolling it out you would improve security posture across all your applications e.g.
   • Logging : Provide a least-privilege way to access logs on a system (SUDO to limit access to commands to only certain directories or, better yet, use Access Control Lists (ACLs) [Linux], Event Log Readers group [Windows], NTFS Permissions [Windows] or Ingest logs to a centralised log aggregation solution that allows fine-grained access to/segregation of logs, provides alerting, reporting etc.
   • Access to application files : Move to using a source control management solution such as GitHub, Azure DevOps, GitLab etc
   • SQL database access : Use AD domain groups, do not directly provision domain users or SQL local users.
8. Implement the controls and design patterns so that all new users/applications/infrastructure use those best practices by default - STOP THE ROT
9. Review the applications that are non-compliant and work to bring them into compliance using the established secure design patterns identified above - never start here, if you decided to make this a numbers game e.g. remediating x% of accounts with overly permissive access, you will find that by the time you’ve finished, it’s already gotten worse again.
10. Monitor, Improve, Iterate - this is not a do it once and forget about it thing, security posture requires constant maintenance.
11. Automate. Seriously - the more you can automate, the better you will do this and keep doing it. A lot of people are afraid of automation, afraid they will automate themselves out of a job. The hard truth is that IT and therefore security, is an ever changing beast. Just to stand still, you need to keep learning and improving. So automation helps you do that and helps you avoid tedious, easily automated work.

You’ll notice that a lot of the above isn’t about technology. It’s about people and processes. Technology is easier than people and process. And also mapping out what you have - you can’t secure what you don’t know you have - but an attacker can absolutely exploit it.

Culture is also a big thing here - encouraging best practice is one thing, but if that best practice is not easy to adopt and sustain, you will meet resistance, and people will continue with how they’ve always done it - people do not like change.

OK, we’ve talked about people and process, what about technology?

There are many technologies available today to help you secure your business and adopt least principle as much as possible. These are not exclusively about enforcing least-privilege, but doing as many of these as possible will significantly improve your security posture and reduce your risk.

1. Use Multi-Factor Authentication (MFA) for every system that supports it. [Know that only authorised users access your systems]
2. Use Single Sign-On (SSO) every where that it is supported [Entering passwords repeatedly can lead to users more easily falling for phishing attacks]
3. Challenge vendor recommendations when installing applications [Does the application need administrative privileges to install/run/both? Try it! Sometimes Admin permissions are only needed to install the application]
4. Use delegated access everywhere you can: AD Delegation of Control Wizard, AD Delegation - PowerShell [ Vendor says an application needs Domain Admin? Most of the time it only needs delegated rights to manage specific attributes of specific objects - this can all be done with delegated rights unless the application is hardcoded to check “Am I a member of Domain Admins?”]
5. Consider use of Privileged Access Management tools ([Netwrix](https://www.netwrix.com/, Thycotic, Centrify, CyberArk) to:
   • allow management of privileged accounts
   • provided secure, audited privileged sessions
   • provide non-repudiation/auditing
   • provide separation of privileged access from primary user account used to login to desktops
   • provide granular privilege escalation
   • provide just-in-time privileged access
6. Use Just-In-Time or time–bound privileged access solutions (such as AWS Security Token Service (STS) or Azure AD Privileged Access Management or PIM) to allow users to elevate to a privileged role only for the time they are performing a task rather it being a standing privilege and reduce allowed usage windows to the minimum possible for that role. [If an account is compromised by an attacker, or a computer is compromised, limit what they can do with the compromised user/computer or previously authenticated session]
7. Consider use of Just Enough Administration (JEA) which allows delegated administration via Windows Powershell
8. Use Sudo on Linux if not using tools like Centrify which allow a similar capability but tied into Active Directory
9. Enable secure protocols by default (SSH, HTTPS)
10. Use secure encryption everywhere supported (TLS 1.3, short term TLS 1.2 - stop using older TLS/SSL versions)
11. Limit membership of Domain Admins and Enterprise Admins in AD to a very small subset of users - restrict, monitor and recertify membership of that group.
12. Limit membership of other Tier 0 (most highly privileged) roles (including Global Administrator, Privileged Role Administrator, Conditional Access Administrator in Azure AD). Again, monitor and recertify. Consider the use of Identity Governance and Entitlement Management features in Azure AD.
13. Use policies that take into account factors that affect the risk profile of the user or device that’s logging in, such as AWS IAM Policies or Azure AD Conditional Access - to ensure that only authorised users, from authorised devices and locations, can access your applications and to block access/enforce additional controls where there is increased risk.
14. Consider the use of a Cloud Application Security Broker (CASB) solution such as Microsoft Defender for Cloud Applications (MDCA, formerly MCAS). For AWS, there is not a native solution, but there are many solutions available in the AWS marketplace that you can integrate.
15. Have 1 or 2 breakglass accounts on your systems - enforce that they are only used in true breakglass scenarios - a breakglass account is no use to you if it’s locked or you no longer know the password. Breakglass accounts may not have MFA, all the more reason to protect and monitor usage. Consider splitting breakglass account passwords so no single person knows it, and store it securely. Shamir’s Secret Sharing is a common approach to this, and there are several implementations of it, from Hashicorp Vault to the Linux SSSS implementation. You can even play with it in your browser here - https://simon-frey.com/s4/ (don’t put anything sensitive in, I just use this to help bring the idea to life).

There are probably many more, and I know that I’m quite Azure focussed when it comes to cloud providers, so feel free to share tips related to AWS, GCP etc and I will add to this post.

What can vendors do better?

Application software providers

1. Avoid requirements for administrative privileges to install/use your software where it is not required - adopt secure development practices
2. Do not use default credentials, or if you do use a default user, force the setting of a secure password for it on install
3. Store credentials/sensitive information securely
4. Use secure communications protocols by default.
5. Your web application does not need to be in Internet Explorer trusted sites to function.
6. Your application does not need to run as the System Admin (SA) (in fact, it is recommended to disable the sa account created by default).
7. Use standard ports for standard protocols.

The last one is a little contentious - there are two schools of thought on this one. A common security tenet is that security through obscurity is not a valid control, though not everyone is in agreement with this.

Obfuscation does have it’s uses, for example:

• Using a non-standard port can be useful in some scenarios e.g. masking commonly exploited services from common network scans.
• Renaming builtin administrative accounts to a non-standard name can slow down attackers in some scenarios.

A counter to that though is that a skilled individual will still find vulnerable services through other methods, and may be able to enumerate privileged admin accounts in other ways (for example, by using the Security ID (SID) of the account in windows - default administrator always has the same SID).

In addition, application aware firewalls are not perfect - there may be cases where application traffic is not detected correctly when running over a non-standard port - in which case you are forced to then revert back to a more traditional rule that controls access by e.g. destination service port. This can be exploited to use commonly open ports to be allowed through the firewall, but using a protocol that was not intended to be allowed through.

So by all means use them as a means of slowing down or otherwise annoying an attacker, but don’t rely on them as your sole security control (see Defence In Depth).

Operating System Vendors

1. Review and expand BUILTIN groups in Windows to be more appropriate for common non-admin use cases [Microsoft]
2. Add more granular privileges and make them easier to manage/assign centrally (especially granular permissions over services) [Microsoft]
3. Retire support for legacy functionality where that backward compatibility requires compromise that weakens security posture - e.g. Windows Server has very good compatibility with very old applications, however that means that applications using insecure programming methods and APIs continue to run and can be exploited as attack vectors. It can also slow or stop the introduction of new features that would improve default security posture. [Microsoft]

Cloud Service Providers

1. Ensure your default deployment model for every service is secure - I’m calling out Microsoft here specifically: Azure Security Benchmarks are really useful, so why aren’t those the default settings?
2. Apply the same principles under the covers in your products that you preach in your security white papers and best practice documents - patching to ensure security fixes have been applied, protecting your secrets and not exposing them in the clear, using Web Application Firewalls (WAFs) to protect even internal services. Yes, that’s the same article and breach for all three points - they, in unison, allowed researchers to achieve cross-account container takeover (being able to access other Azure customer’s containers).

Summary

In this post I shared my opinions on the best approaches that organisations could take to improve their privileged access management position and security posture. I also shared my view on where software vendors could help their customers improve their security posture and reduce their risk exposure.

In my next post (possibly several posts), on the suggestion of a good friend and colleague of mine, I’ll do some worked examples of what I’ve talked about so far to show the journey you might take in getting to a position of least privilege in your applications and infrastructure.

While I did give Microsoft a hard time here based on the challenges I’ve seen using their products, they are by no means alone, other vendors have similar challenges.

To their credit, Microsoft are doing some really good things in promoting secure config, best practices, improved detection/response tooling etc. However if an organisation with the resources and funds that they have still struggles, that should reinforce why this matters and why putting in the time and effort to understand your environment and use cases will pay dividends. Also remember that even Microsoft may face some of the same challenges I talked about.

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