The primary key performance indicator (KPI) of a system administrator is the ability to make things work — plain and simple. When people encounter problems related to system access rights, they almost always knock on the domain administrator’s door to seek escalated privileges. Adding a user to a highly privileged group usually solves this problem in the short term, but it’s certainly not the best practice.

By gaining inappropriate access to privileged accounts, application and service users are exposing vulnerabilities across the environment. Also, these access rights are easy for internal and external auditors to find.

While it’s the security operations center (SOC) team’s responsibility to defend their environment, the team is not always in a position to remediate these issues. Given these challenges, how can security decision-makers manage and mitigate risks associated with highly privileged accounts?

Try Modeling User Behavior

Application and service users are relatively static due to their nature. Let’s imagine that a privileged identity management solution user logs in to several systems, gains some administrative login privileges, modifies a user in that host and logs off.

In a security information and event management (SIEM) tool, it would look like this:

1. Success Audit: A user successfully logs into an account.
2. Success Audit: Successful login with administrative or special privileges.
3. Success Audit: An attempt was made to reset an account’s password.
4. Success Audit: A user account was changed.
5. Success Audit: A user logged out of the account.

Obviously, this would give the user of the privileged identity management solution the kind of privileges that malicious actors and penetration testers dream about.

Similarly, other application and service users leave a remarkably low variety of footprints compared to human managed users. In addition to the operating system level, these users’ behavior is also predictable in other environments, such as databases and network devices.

For SOC teams, it is easy to model and map the behaviors of service users. The event types, sources and destination IP addresses associated with these users does not change very often. In some cases, activity times are even predefined. As a result, a determined SOC analyst can see which files an application user accesses on known servers and at what time of day it typically runs batch jobs.

Keep Control of Privileged Accounts

Once the analysis of highly privileged users is complete, it’s time to develop rules and use cases to detect anomalies. Since almost everything about the user is known, it is easy to create a white list of event types, sources, destination addresses and activity time frames. Any activity that does not match the white list should raise an alert in the SIEM environment.

You might be raising your eyebrows and wondering, “Isn’t that the purpose of behavioral analytics tools?”

This is partially correct: Behavioral analytics tools and other machine learning techniques try to solve nondeterministic problems mainly based on anomaly detection — and they are perfect for monitoring users at a large scale. While modern algorithms provide an acceptable level of accuracy, they also generate many false positives and negatives. When it comes to monitoring privileged users, this problem is deterministic — we know exactly what we want to monitor.

In a mature SOC, rules and use cases are tailored to the specific environment. There is no one-size-fits-all solution in this area. That’s why we do not see these kinds of rules in SIEM content provided by third parties. With the capability to monitor and defend privileged accounts in this fashion, chief information security officers (CISOs) can rest a bit easier at night.

Discover, manage, protect and audit privileged account access with IBM Security Secret Server