Penny Wise and Password Foolish

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 access-related breach?

I think the majority of executives and security professionals would ante up a reasonably hefty sum to make this a reality. But let’s shift focus here and look at how we can assess how much damage a compromised privileged account could cost an organization from both a monetary perspective and a reputation perspective. Consider the recent breaches at Equifax, Yahoo, and Duke Energy. Each of these failures in security 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 not only has a monetary value on the Dark Web for a threat actor to purchase, but it also has a price that can be associated to an organization in terms of risk.

What is the value and risk should that password be breached and the contents it protects exposed to the wild? A database of personally identifiable information (PII) is quite valuable, and blueprints or trade secrets may have even a higher value if sold to the right buyer (or government). My point is simple: privileged accounts have a value, and the problem is not always securing them, but rather in identifying where they exist in the first place. Would you spend a penny, use a free tool, or existing product already in your organization to find them? Odds are you are already doing this, and you just need to know where to look to get this information. It would be foolish not to.

Don’t Overlook the Data You Already Have

So, how do you spend a penny or less to discover privileged accounts and rate their risk? Look no further than your existing operations and security teams.

Your existing teams probably have a vulnerability assessment solution 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 are 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.

Taking Privilege Risk Management to the Next Level

Now, I know some of my readers may be saying, so what? We already do this. That is great, but do you take this to the next level and actually assign a risk to the account? Do you quantify how often it is used, from what location(s) it is used, and how many people are using it (sharing accounts is a bad security practice, by the way)?

All privileged accounts are not equal. Some are worth a penny (figuratively) and others are worth considerably 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 foolish. 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 privileges you can get. Therefore, this could potentially allow a threat actor to maintain a persistent stealth presence until the organization identifies the breach.

So, what should you do to take credential, privileged access, and privileged account security to the next level:

• 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 existing tools, 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.
• Measure the risk of the asset. This can be done using basic critical/high/medium/low ratings, but should also consider the crown jewels present and any other risk vectors, such as 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.

Spending a penny to find them and map them is a much safer security mechanism than foolishly leaving them unattended. Thus, a penny wise to understand your privileged accounts versus a password foolish used in a breach. To learn more, schedule a strategy session with us today.