Following our guide to Least Privilege and the Value of User Logon Management we're thinking about how organizations may see the point of least privilege as being different things.

We all know, at a minimum, the implementation of the principle includes setting up users with the least amount of privileges possible (after all, it is right there in the name!)

But, once you establish least privilege, then what?

The way you answer this question determines what least privilege is really all about within your organization. It reflects what’s important to you when establishing security around this principle, as well as the scope and duration the principle needs to be in effect.

Not sure what I mean?  Keep reading. There are a few ways to answer the question, "then what?"

So, you’ve established that everyone’s privileges are minimized down to the core necessity only to enable them to do their job. There is a logic that says there’s nothing more to do here.

If you subscribe to the thinking that once the permissions have been limited, you’re done, then for you, least privilege is definitely about the current state of privilege.

Those of you with this response are definitely more in the “maintaining a state of least privilege” mindset — which is good. Having periodic attestation around privileges required, permissions assignments, and group memberships is a solid way to ensure control over what would otherwise become a entropic mess of over-permissioning with no visibility into the privileges assigned.

For your organization, least privilege is about maintaining a continual state of least privilege.

If you're in this camp, you definitely have a more mature viewpoint on the implementation of least privilege. When you add monitoring to the mix, you acknowledge that least privilege isn’t really about the privilege; it’s about the use of privileges.

So, monitoring when and how privileged accounts are used — this can be as simple as monitoring all logons, leveraging a password vault where privileged accounts must be checked out, or can be as complex as monitoring user activity through session recording.

One of the challenges in this particular answer is you need to decide which user accounts are “privileged." Is it just accounts with admin rights in Active Directory? Those with administrative rights to enterprise applications? Those with admin rights to endpoints? Servers? More than that?

If you’ve drawn a line somewhere in the proverbial sand, delineating a particular level of privileges and above that should be monitored, least privilege is about validating the state of privilege is not misused.

Delineating the "privileged" from the "low" level user can be somewhat short-sighted. If you start with the data, applications and systems you deem critical (that is, you wouldn’t want them compromised, exfiltrated, etc.) and work back to your users, you quickly realize that even the low-level sales person who has access to at least a subset of your customer database is, by definition privileged. Certainly, nowhere near as privileged as the administrator account in AD, but, nonetheless, they do have privileged access that users outside of sales do not.

So, it should be evident that if you’re going to take the route of monitoring privileged accounts, you need some level of monitoring use for even the accounts that represent a lower risk to the organization (like the sales user). Higher-risk users may require user activity or session monitoring, but all users should have a base level of monitoring for use, such as logon monitoring, to look for leading indicators of compromise, such as inappropriate or irregular logon attempts by otherwise, normal users.