A whopping 81% of data breaches involve the misuse of credentials to access sensitive and valuable data. With stats like these, IT leaders have huge motivation to ensure those credentials (read: user accounts) only have the bare minimum permissions needed to do job-related tasks.

The principle of least privilege seeks to do just that. Properly applying least privilege is key to lowering security risk, as well as a cornerstone of zero trust architecture.

The principle of least privilege means limiting access rights to the minimum necessary. When applied to people, admins can use role-based access control (RBAC) to limit a user's privileges to only the data, applications, and systems they need to do their job. But least privilege also applies to services, applications, processes, devices such as IoT, and other computing processes.

Least privilege is easy to explain, but harder to implement. And organizations have been struggling to do just that for a long time. A flip through the internet archives turns up this gem from Microsoft in 1999:

“Most security-related training courses and documentation discuss the implementation of a principle of least privilege, yet organizations rarely follow it.

The principle is simple, and the impact of applying it correctly greatly increases your security and reduces your risk.

The principle states that all users should log on with a user account that has the absolute minimum permissions necessary to complete the current task and nothing more.

Doing so provides protection against malicious code, among other attacks. This principle applies to computers and the users of those computers.”

And that was written over 20 years ago! The threat of attack today — both by insiders and external attackers alike — is even greater.

The principle of least privilege is even more critical to a robust cybersecurity strategy today. And it's easy to see why. For example:

• External attacks leverage user accounts to gain control over endpoints, to move laterally within the network, and, ultimately, to acquire targeted access to valuable data.

• Insiders leverage their own granted access or other compromised accounts to leverage data and applications for malicious purposes.

If you think your organization doesn’t need least privilege, consider the following two industry statistics.

1. Nearly three-quarters of users are over-privileged, having access to information that has nothing to do with their job.

2. Half of users share their credentials.

Put those two concepts together and you quickly realize that without least privilege, you have more privilege in place than ever intended.

Before you implement least privilege, it's important to first look at the goals and benefits of least privilege. When properly applied, the principle of least privilege helps IT to:

• Reduce the attack surface: Given a majority users in your organization are likely already over-privileged, implementing least privilege is done to eliminate any unnecessary access.

• Reduce the potential for malware infection: To be installed, malware requires local admin rights. By limiting access to admin-level privileges on endpoints and servers, malware (such as ransomware or SQL injections) is less likely to have the ability to infect a given machine.

• Reduce attacker lateral movement: Threat actors aren’t satisfied accessing a single endpoint; they desire to more within the network, jumping from endpoint to endpoint, until they reach a system with valuable data. Privileged accounts are necessary to facilitate this access. By limiting users to as non-privileged a level of access as is possible, attackers have less ability to move within the network.

• Reduce the potential for insider threats: Insiders will use any access you’ve granted them to get to all data accessible for exfiltration, corruption, or destruction.

• Meet and prove compliance: Least privilege makes your environment less complex, which in turn makes it easier to audit. Many compliance regulations (such as PCI DSS, FISMA, SOX, and HIPAA) mandate least privilege access policies to demonstrate proper treatment of data and systems security.

These goals need to be looked at through the lens of what it takes (what privilege level) to keep your business operational.

So, what are some of the fundamental steps you should take?

Unfortunately, implementing least privilege isn’t as simple as just making everyone NOT an admin.

This applies to endpoint workstations, servers, applications, other critical resources. Default all users (even IT) to having a standard level of privilege. Consider two routes to providing privileged access when needed.

First, create separate accounts for users that require privileges: one to perform their non-admin job functions (web browsing, email, working in Office documents, etc.) and their administrative functions.

If the two-account system won’t work in your organizations, consider removing root and admin access to endpoints, working from the ground up to provide users access to manage those parts of the endpoint necessary. For example, need the ability to manage DHCP, make the user a member of the DHCP Admins group, and give them Log On Locally rights, but no more.

This step involves quite a large amount of work. To get this right, user profiles need to be identified (e.g., Salesperson, Payroll User, Payroll Admin, etc.) along with a definition of what permissions are necessary for each. Then an audit must be performed to bring every user account into a state of least privilege.

This applies to access to data, printers, applications, systems, and the local endpoint. Should a user genuinely require admin rights to perform specific tasks, look for ways to provide application-specific elevation of rights, rather than a blanket fix of just making them an admin. Third-party solutions exist to facilitate this.

Whether we’re talking about the local admin account on a workstation, or the administrator account in Active Directory — and everything in between — minimize the number of users that have access to these types of accounts.

Privileged account management (PAM) solutions also can provide secure access to administrators and other privileged accounts via a policy-protected vault.

Each of the previous 3 steps revolves around proactively creating an environment where admins only grant users the necessary permissions. These steps curtail the majority of over-permissions going on in organizations today.

But even with all this in place, the organization runs the risk that account misuse (even accounts restricted down to the bare work essential privileges) will provide enough access for a threat action to take place.

For example, if you were to run through the exercise of limiting user accounts and determine that the Director of Accounts Payable needs full access to the AP system, the potential still exists that the account can be compromised and fraudulent payments can be made to steal the organization’s money.

Here’s the key issue: Least privilege isn’t actually about privilege.

In reality, least privilege is really about the compromised use (whether by an insider or external threat actor) of a privileged account. So, one of the key aspects of a least privilege strategy must be to monitor the use of privileged accounts.

Given the rampant practice of misusing credentials as part of both external and insider attacks, your organization cannot afford to simply focus on accounts that are admin level. The previous example of the AP Director is one where the user certainly isn’t considered an admin of anything; just a user with more access to a given system than others in the organization.

So, the goal is to have a way to monitor the use of every account to ensure you're meeting the underlying goals of least privilege.

As we mention above, using a PAM solution is viable for a subset of truly privileged accounts (like Administrator within AD). But, it's not a good fit for monitoring the use of every user account in the organization.

There is one pivotal point of access that provides organizations with leading indicators that an account is either being properly used or has been compromised, and that is the logon.

The logon is a required step, regardless of the method of access or level of privilege, for an account to gain access to resources. And it’s this mandatory step that can provide you with visibility into the use of privilege — no matter the level. Both insider and external threat activity include telltale signs of misuse right at the logon:

• After-hours use: Users tend to logon using a similar days/time pattern. Abnormal usage of an account outside of business hours can indicate potential misuse.

• User/endpoint mismatch: Logons from unusual locations or endpoints should be a source of concern.

• Multiple failed logon attempts: External attackers attempt to leverage credentials on as many systems as possible to increase their ability to move laterally. This kind of activity is a clear indication of potential misuse.

• Multiple concurrent logons: Continuing the last scenario, an external attacker may successfully leverage an account and gain entry to multiple systems simultaneously — an abnormal occurrence for any account.

The challenge in monitoring account use via logons is that, despite their clear value in highlighting inappropriate activity, Microsoft environments have no native means by which to centralize all logon activity — let alone provide analytics around unusual logon behavior.

You can get part of the way there with Event Subscriptions (a capability with Event Logs where certain logs can be forwarded to a central Windows machine), but it’s a solution that is designed for a very small number of systems. Third-party logon management solutions exist to provide comprehensive logon monitoring across all endpoints, analyzing logon activity, and providing notifications of any abnormalities.

Logon monitoring is the first step in helping to limit the risk associated with any kind of privileged access — the very intent of a least privilege initiative. Monitoring logons elevates IT visibility into account use, before threat actions can be implemented.

Logon management solutions also provide policy-based enforcement around logons. This further ensures privileged accounts cannot be misused by restricting logons by machine, time, and concurrency, as well as forcing logoffs after approved hours.

The combination of the two functionalities helps to keep the least privilege controls in place, further securing the environment from credential misuse.