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 organizations1. Scary stuff.
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?
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.
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:
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.
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.
Based on the system you’ve identified the account on, consider the following:
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:
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.
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.
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.
As General Manager, Adam is responsible for product lifecycle and market adoption from concept to implementation through to customer success. He is passionate about market strategies, and developing long-term path for success for our customers and partners.
Previously, Adam served as CMO and has held a variety of senior leadership positions at Stealthbits – now part of Netwrix including Sales, Marketing, Product Management, and Operational Management roles where his focus has consistently been setting product strategy, defining roadmap, driving strategic engagements and product evangelism.
Adam holds a Bachelor of Science degree in Business Administration from Susquehanna University, Selinsgrove, PA.
Proper data security begins with a strong foundation. Find out what you're standing on with a free deep-dive into the security of your Structured and Unstructured Data, Active Directory, and Windows infrastructure.Read more
Start a Free Stealthbits Trial!
No risk. No obligation.