Contactez-nous Suivez-nous sur Twitter En francais English Language

De la Théorie à la pratique

Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN



Morey J. Haber, BeyondTrust: A Penny Wise and a Password Foolish

January 2018 by Morey J. Haber, Vice President of Technology, BeyondTrust

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? I think the majority of executives and security professionals would ante up a reasonable sum to make this a reality but that’s not what this article is about.

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 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 to 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? A database of personally identifiable information (PII) is quite valuable and blueprints or trade secrets have even a 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. 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.

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 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.

Now I know some of my readers may be going – 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, where its used from, and how many people are using it (sharing accounts is a bad security practice – by the way)? This is where a penny becomes important verses being foolish. All privileged accounts are not equal. Some are worth a penny (figuratively) 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 foolish. You could make the same argument for a database admin account verses a restricted account used with Open Database Connectivity (ODBC) for database reporting. Both are privileged but owning the database verses 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 (if cynical and crafty enough) until the organization identifies the breach.

So, just what should you do to take credential and privileges 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, and low ranking but 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 Common Vulnerability Scoring System (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 high risk, if privileged access is not managed, and will drop in risk if privileges are session monitored and access controlled. Criticality can be 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 verses a password foolish used in a breach.

See previous articles


See next articles