Auditing Administrator Access Rights

Identifying Administrative Privileges Across IT Resources

Accounts with administrative and elevated privileges are necessary for both business and IT functions, but also represent a significant risk to your organization. Privileged credentials in the hands of the wrong user or an attacker can lead to a variety of undesirable outcomes, including data breaches, infrastructure outages, and compliance failures. Although Privileged Access Management (PAM) is recognized by CISOs and security professionals as one of the most important areas of focus among their many initiatives, it’s still estimated that over half of all privileged accounts and entitlements remain unknown within most organizations¹. Scary stuff.

Privileged Account Management Goals

As with any project, it is wise to begin with the end in mind. When it comes to PAM, however, the goal shouldn’t be to just protect your privileged accounts. That’s obvious. The goal for any PAM program should be to reduce the number of privileged accounts that exist to the absolute minimum and protect those that remain from falling into the wrong hands.

Privileged accounts, in comparison with the “everyday” user accounts we all use for accessing our computers, checking our email, etc., are needed at specific times for specific purposes. However, these privileged accounts maintain persistent access to the systems, applications, directories, devices, and data repositories they were created for! THIS (ladies and gentlemen) is the problem that needs to be solved. This is what the attackers are actually counting on. Vaulting these accounts and frequently changing their passwords only does so much. An attacker doesn’t necessarily need the password to move laterally, escalate privileges, and compromise your entire domain and everything connected to it (which is everything). There are a number of ways they may be able to compromise that account – from stealing hashes to abusing privileges – and the fact its privileges exist at all times create the risk.

So now that we know we want to REMOVE privileged access (not just secure it), what’s the first step?

Step 1 – Audit Administrative Access Rights

The very first step on our journey to privileged account security bliss is to find out what you’re working with. When engaging in a privileged account discovery exercise, you’ll find some accounts will be easy to identify, yet some will be hidden so deep that without a comprehensive inspection, they might never be found. Either way, finding your privileged accounts is key. Once you know they exist, you can then begin the process of determining what to do with them.

Step 2 – Classify Privileged Accounts

To simplify things, consider creating a classification scheme. Don’t make it overly complicated either. You can probably break down all accounts into three (3) classes:

• Administrator/Root/Super User (i.e. “God-level”)
• Infrastructure/Application/Power User (i.e. some sub-set of “God-level”)
• Normal/Staff/Ordinary User (in the context of this blog, we don’t really care about these)

You can call these whatever you’d like, but the point is to delineate between different levels of privilege.

It’s also worth entertaining the delineation between different segments of your environment, such as Production, Development, and Test domains. Havoc can certainly be wreaked through the compromise or improper use of a privileged account in any of these environments, however, someone wiping out a test lab almost certainly will have a different level of impact than if the same happened in Production.

Step 3 – Identify Privileged Account Owners

Now that you know which accounts are privileged, what level of privilege they provide, and to what, the third step is to figure out who can help in the process of determining whether or not these accounts need to exist in perpetuity or even at all. Sometimes it can be quite difficult to identify an actual owner for every account, but here are some ways in which you can narrow down the candidates.

Identify Service Account and Privileged Account Owners

Based on the system you’ve identified the account on, consider the following:

• User Profile Last Modified Date – If a particular user’s profile was modified recently, it’s a good indicator that they’re an active user of the system and may be able to determine who the owner of the account is
• User Profile Size – If there are many users who leverage a system, but one user has a particularly large profile compared with the others, it could be an indicator that they are the true owner of the system and others just visit occasionally. As a result, that user may be able to identify who the account owner is.
• Currently Logged On User – In the absence of useful profile information, auditing who is currently accessing the system at least provides an active user in the organization to interview about who the account owner may be
• Last Logged On User – In the absence of useful profile information and an active user logged onto a system, identifying who has logged onto the system recently could help to identify who could identify the account owner
• Service Type – If the account is a service account, the service it’s running could very well lead to an application owner
• Authentication Source – The source of authentications to the privileged account could be a specific user’s workstation or maybe another server with a clear owner

Step 4 – Interview Privileged Account Owners

As mentioned previously, privileged accounts are used rather infrequently in comparison with every day user accounts. As a result, understanding usage frequency is an important data point to gather.

Here are some questions you might want to ask:

• What is the purpose of this account? (e.g. break-glass, system/app administration, service)
• What activities is it used to do?
• Are the privileges that it possesses necessary to achieve those activities?
• If it’s shared by multiple people, how is accountability to an individual/non-repudiation ensured?
• Is this a service account? What privileges does it actually need?
  • NOTE: Service accounts are often over-provisioned, so while you might not be able to eliminate it, you may be able to reduce the exposure its privileges pose

Step 5 – Retire and Remove No-Longer Needed Privileged Accounts

With signoff from account owners, begin removing privileged accounts that no longer need persistent access, starting with the most critical resources first. The criticality of a resource is, of course, subjective, but delineators such as the role the resource plays (e.g. Domain Controller vs Standard File and Print Server), the sensitivity of the data (e.g. Financial, ePHI, PII, IP) or applications (e.g. CRM, ERP, Trading, etc.) that reside on the system, or the segment of the environment the resource resides in (e.g. Production vs Dev, in the DMZ vs connected to the internet) are good things to think about.

Step 6 – Employ Just-in-Time (JiT) Access (At a Minimum)

Most PAM providers employ a Just-in-Time approach to privileged account access at this point, but that’s just the starting point. When you couple JiT access with Ephemeral (i.e. One-Time Use accounts created on the fly) or the temporary escalation of an existing account’s privileges, you can truly begin to align with a Zero Standing Privilege (ZSP) model. ZSP is critical because it is the most effective way to mitigate the opportunity for lateral movement. Think about it. If an account doesn’t exist, it can’t be compromised and thus cannot be used to move from one system to another.

Privileged Access Bliss

If it’s your responsibility to secure your organization’s privileged access rights, there’s no doubt you’ll sleep better at night having gone through the exercise of auditing administrative access rights. Start small! You can’t solve this problem in a day but chipping away at it over time will result in the reduction of risk for your organization at a monumental scale, as well as on a daily basis. And it all starts with auditing administrative access rights. Forrester famously stated that privileged accounts are involved in 80% of data breaches and as previously stated, over half of privileged identities remain unknown in most organizations. You can’t secure it (or remove it) if you don’t know it exists. For information on how Stealthbits can help, check out our innovative approach to Privileged Access Management.

https://www.stealthbits.com/privileged-access-management-solution

¹https://www.csoonline.com/article/3129474/pain-in-the-pam.html