How much money would you spend to secure your passwords from being stolen? If you actually could safeguard all your passwords, would you worry as much about a privileged breach as a vulnerability and exploit? I think the majority of executives and security professionals would ante up a reasonable sum to make this a reality, but protecting an asset is more than security patches and configuration. It is about the damage a compromised privileged account could cost an organization from a momentary perspective and a reputation perspective. If you need proof of this, consider the recent breaches at Equifax, Duke Energy (based on a third-party software vendor), and Yahoo. Each one of these affected the company’s stock, executive bonuses, acquisition terms, and even the ability to do basic business like accepting payments in due terms.

A compromised privileged password does have a monetary value on the dark web for a threat actor to purchase but also has a price that can be associated with an organization in terms of risk.

What is the value and risk if that password is exposed and the contents it protects exposed to the wild? It can influence a vulnerability score as well. A database of personally identifiable information (PII) is quite valuable, and blueprints or trade secrets have an even higher value if sold to the right buyer (or government). My point is simple: privileged accounts have a value (some a very high value), and the problem is not always securing them but rather identifying where they exist in the first place. So how do you discover privileged accounts and rate their risk? A vulnerability management solution is capable of doing this, and you just need to know where to look to get this information. It is a natural extension to any existing vulnerability management process if you are not already doing this.

A vulnerability assessment solution is capable of performing user enumeration for operating systems, applications, and databases. Within that data, the results should include accounts and their creation date, last login date, password age, and which groups they belong to—including administrators group or root. The results of these scans are generally ignored by vulnerability assessment teams but invaluable to security teams attempting to gauge the exposure of privileged accounts. If you can discover where privileged accounts exist, you can measure their risk and then monitor for their usage. Any inappropriate access can be highlighted using log management or a SIEM and properly escalated for investigation. This extends the processes and procedures we have been discussing and maximizes the usage of the data that is collected.

All privileged accounts are not equal. Some are worth very little and others a lot more based on risk. A domain administrator account is of higher value than a local administrator account with a unique password (although that may be good enough to leverage for future lateral movement). Treating every privileged account the same is not a good security practice for securing an asset. You could make the same argument for a database admin account versus a restricted account used with ODBC for database reporting. Both are privileged, but owning the database versus just extracting data is not the same. Yes, both could be a devastating attack vector responsible for a breach, but owning the database is the highest privilege you can get. Therefore, this could potentially allow a threat actor to maintain a persistent stealth presence (if cynical and crafty enough) until the organization identifies the breach.

So, we are now at academics. What should you do to take credentials and privileges to the next level as a part of your vulnerability management program:

• Identify crown jewels (sensitive data and systems) within the environment. This will help form the backbone for quantifying risk. If you do not have this currently mapped out, it is an exercise worth pursuing.

• Discover all of your privileged accounts using a vulnerability assessment solution, free solutions (there are plenty), or via a dedicated privileged solution.

• Map the discovered accounts to crown jewel assets. This can be done by hostname, subnets, AD queries, zones, or other logical groupings based on business functions. This could be assigned as Criticality in your vulnerability management solution.

• Measure the risk of the asset. This can be done using basic critical/high/medium/low, but it should also consider the crown jewels present and any other risk vectors like vulnerabilities. Each of these metrics will help weight the asset score. If you are looking for a standardized starting place, consider CVSS and Environmental metrics.

• Finally, overlay the discovered accounts. The risk of the asset will help determine how likely a privileged account can be compromised (via vulnerabilities) and help prioritize asset remediation outside of the account mapping.

In the real world, a database with sensitive information may have a few critical vulnerabilities from time to time, in between patch cycles, and be considered a critical risk when they are present regardless of the accounts identified. When patch remediation occurs, the asset may still be a high risk if privileged access is not managed and will drop in risk if privileges are session monitored and access controlled. Criticality can come from vulnerabilities or unrestricted, unmanaged, and undelegated access, in addition to attack vectors that have workable exploits. Therefore, privileged accounts, especially ones that are unprotected, have stale passwords, guessable passwords, or even default passwords represent another risk that must be mitigated for your assets.