Least Privilege and the Value of Managing All User Logons

The risk associated with any kind of data breach today is so significant (with regard to the legal, financial, and reputational repercussions), that organizations like yours take the threat of breach very seriously. With 81% of data breaches involving the misuse of credentials to access sensitive and valuable data¹, ensuring those credentials (read: user accounts) only have the bare bones permissions needed to accomplish job-related tasks just makes sense.

This is what the principle of least privilege is all about – the practice of limiting users (along with services, applications, and other computing processes) to only those sets of data, applications, and systems absolutely required to complete legitimate work activities.

The principle has been around for many years. Microsoft wrote the following back 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 because the threat of attack today – both by insiders and external attackers alike – is even greater, the principle is even more pertinent to an organization’s security strategy:

• 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.

So, how should you implement Least Privilege to reduce breaches and insider threats?

Putting Least Privilege in Place

Implementing least privilege isn’t as simple as just making everyone NOT an admin. While that’s a piece of the puzzle, you need to first consider the overarching goals of least privilege:

• 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 is less likely to have an 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 and all access you’ve granted them to get to all data accessible for exfiltration, corruption, or destruction.

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

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

Step 1: Separate Privileged & Non-Privileged Accounts

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 privilege 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.

Step 2: Limit Privileges

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.

Step 3: Limit Access to Administrator

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.

The use of Privileged Account Management (PAM) solutions can provide secure access to administrator and other privileged accounts via a policy-protected vault.

Step 4: Monitor Use of (Not Just) Privileged Accounts

Each of the previous 3 steps revolve around proactively creating an environment where users are only granted (and can exercise) the needed permissions. These steps will certainly curtail the majority of over-permissioning 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 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.

But what should you consider a ‘privileged’ account? 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, what’s needed is to have a way to monitor the use of every account to ensure the underlying goals of least privilege are met.

The previously mentioned use of a PAM solution is viable for a subset of truly privileged accounts (like Administrator within AD), but is not a good fit for monitoring the use of every user 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: the logon.

Leveraging Logon Monitoring

The logon is a required step, regardless of the method of access or level of privilege, in order 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.

Leveraging Logon Management as a Key Part of Least Privilege

The principle of least privilege is intended to create an environment that, while providing elevated access, still limits risk. The act of isolating privileges based on need and providing users only the access they require is a key first step. But once the accounts are created and the privileges established, a gap exists. Even with limited privileges, passwords can still be shared, and accounts can be compromised with malware. Given, the more restrictive least privilege environment cannot police itself to detect inappropriate use, so the need for some level of monitoring and enforcement is required.

By including Logon Management as part of your Least Privilege strategy, your environment remains in a constant state of enforcement and scrutiny to preserve the goal of increasing security and reducing risk.

¹ Verizon, Data Breach Investigations Report (2017)
² Microsoft, The Administrator Accounts Security Planning Guide (1999)
³ Ponemon, Corporate Data: A Protected Asset or a Ticking Time Bomb? (2014)
⁴ IS Decisions, Insider Threat Persona Study (2017)