Privileged user accounts, such as those used by administrators, application developers and even the security team themselves are prime targets for attackers. Typically, once an attacker has the credentials for a privileged account, they are free to move around the business as they please. For this reason, constructing a secure privileged account management capability is a critical building block in your enterprise security architecture.
This blog looks at some of the considerations for your business when developing a privileged account management capability.
Privileged Account Management: Locking Down Access
Interestingly, this is when many organisations jump to looking at vendor solutions to enhance their logging capability, without looking at the systems and applications they already have. A relatively new class of security technologies, known as User and Entity Behaviour Analytics (UEBA), has emerged over the past few years that claims to learn what normal user behaviour looks like within your organisation, then report on any unusual activity that could indicate an attack is underway.
Large floods of data from a single account, an administrator suddenly moving data from one server to another or connecting to multiple end user devices might be examples of behaviour that could indicate an account is being misused. There is little doubt, since this has been tested many times, that an investment in UEBA assists in profiling attacks that might otherwise have slipped under the radar.
The importance of Behaviour Analytics
Without behaviour analytics, organisations are largely blind to the most insidious of threats, the ones that have already got access to privileged accounts, either by being a malicious insider or though account compromise. For this reason, Huntsman Security have built a patented behavioural analysis capability into our SIEM product, called Behaviour Anomaly Detection (BAD), which includes the following benefits:
- Immediate visibility of anomalous situations within networks, operating systems and, uniquely, application layers;
- Correlation of known threat intelligence and assets with behavioural data;
- Autonomous BAD extends the detection of threats beyond the limits of pattern and signature-based security controls, to what you don’t or can’t know;
- Ease of operation, reduces operational risk to limit uncertainty and operator error; and
- Integration with rules-based security solutions complement the analysis and insight into known and unknown threats.
BAD starts developing a baseline profile of what normal looks like as soon as the SIEM starts ingesting information. Alongside Microsoft’s Active Directory, as well as any other LDAP or authentication sources within your business, BAD can outline to the security operations team exactly what is going on within the business and identify unusual activity that is indicative of an attack.
The power of SIEM
The SIEM then comes into its own, since it doesn’t care what information it ingests, rather it takes events from any data source and mines that data against predefined correlation rules and the baseline created by BAD. When something is discovered, it runs through an automated threat verification cycle first, determining if it can be confident of the detection being a real incident, and if not the investigation is passed to a SOC analyst for further investigation. The only real limitation of what the SIEM can do is the creativity and imagination of the SOC analysts driving it.
From a privileged account management perspective, if you want to record what your administrators are doing, start by using a model whereby each administrator has a personally attributed account; i.e. they don’t log in as Admin1 rather they log in as JohnSmith, so that activity associated with the JohnSmith account is easily attributed to that user (or someone who has hijacked that account).
If six administrators all log in using the shared Admin1 account, it’s much harder to pick out who did what activities on which systems and while BAD will pick these up, it’s harder to discern what’s normal when accounts are shared amongst people with different administration roles.
Never use default accounts
Furthermore, never use default accounts. When you install the Microsoft operating system, you end up with several domain and local administrator accounts, each of which has supreme privileges over your systems, yet you’ll find that most administrators don’t need all these rights. If the user JohnSmith works on the helpdesk and has the primary role of resetting user passwords, they don’t need rights in Active Directory and certainly shouldn’t be installing software on file servers. By limiting what privileged accounts can do, you can reduce the attack surface, while making the audit trail more specific and targeted to see exactly what’s going on.
Applications can also be tuned to provide specific information. If you run Oracle, for example, you’ll find that the super user account is often the one Oracle administrators use for even the simplest housekeeping activities. This is not good practice since a compromise of that user’s device can leave the entire corporate database vulnerable to super user attack. So, delegate administration rights down to lesser accounts and ensure they are task based, thus limiting the exposure should any of these accounts get compromised.
Privileged Account Management: Logging & Alerting
Now that you have built a hierarchy of privileged users and protected the most privileged accounts from exposure by removing them from normal use, it means you can introduce specific logging and alerting rules into their use.
Most modern systems and applications can be configured to log every single activity a user undertakes, which helps BAD identify what’s normal and identify unusual activity. Have your administrators ensure that all logging is switched on, then ensure that the logging can’t be switched off again by most daily-use privileged accounts. This stops hackers hijacking administrator accounts or malicious insiders who work as system administrators from covering their tracks.
Carefully go through the audit policy for every system and application and select which events are needed to understand what’s happening. Many systems by default produce a whole raft of security-irrelevant information, which is often also ingested by the SIEM. If you want to keep everything, that’s fine, but it still pays to know what the most useful events are, thus allowing the SOC team to build quality correlation rules that quickly identify issues and threats.
Privileged Account Management: Correlation Rules
To obtain the best view of exactly what your privileged users are up to, SOC analysts should start creating correlation rules based on attack scenarios. For example, if an administrator was to try and clear the audit log on a Windows server, even if this fails due to lack of privileges, you can alert the SOC to this activity and investigate why they did this.
The SOC can create correlation rules that show when privileged users are trying to access applications or data stores from multiple hosts at the same time. Or, for example, if one of your database administrators starts logging in at the weekend, this could be normal activity, but if it’s started happening and you also see a spike in traffic leaving the organisation when that administrator logs in, it could indicate the account being using to steal corporate data and exfiltrate it to an external destination.
Developing a hypothesis of what an attacker might do with a privileged account is a good way of determining what you need to look for. In the scenarios outlined above, there are multiple log sources throughout each successive stage of the attack, such as remote access servers, Active Directory, database accounting system, and file system access control lists. As each of these log sources produces an event, the likelihood of an attack becomes greater. At some point, the confidence level of it being an attack passes a threshold and the SOC team gets an alert, leading to an investigation.
Privileged Account Management: Where to from here?
Monitoring the privileged few is vital to your organisation’s security by:
- Locking down access;
- Creating logging & alerting rules, and;
- Developing correlation rules based on attack scenarios.
By following these key steps you will have a clear view of what you can do with the tools you already have at your disposal and you’ll also have a better understanding of the gaps.
Products
Solutions by Industry
Learning & Resources
About Huntsman
