Cyber security monitoring is a daunting task. One area that often gets prioritized to monitor is access control, most likely because the logs are available and it’s one of the highest risk vectors that will cause impact to your organization. The hard part is ensuring that you are monitoring for the use cases that may cause the highest impact and not just the logins and logoffs of all your employees

How can you do this without driving your security operations staff who must respond to alerts crazy? The key is identifying these key use cases,which can be a challenge, but there are a couple of approaches to consider.

1) Trending- are you watching for unusual spikes in access control activity?

2) Risky behaviors-multiple unusual events that happen within a specified time period by one account

3) Access to specific assets (e.g., your crown jewels)

4) Unusual actions by privileged users

First, let’s take a step back and define access control. Access control is not a single concept, but a combination of authentication and authorization. One key mistake many organizations make is not watching for a combination of the two, but rather a single dimension. This particular single event warrants manual investigation into authentication logs that do not provide the entire context of an event.

Now let’s define what a use case is. The use case ends can be defined in many ways, but in the context of this article, it means what we care to monitor. The use case is specific in language, has a reasonable way to monitor (e.g. existing log files that can be leveraged in a monitoring tool) and it has a method of response that can contain and/or remediate the event. Often, Security Operations is called upon to monitor for abnormal access control behavior but may run into problems with either not having context into the full event or may not be able to remediate it. These are in fact bad use cases. If you have to rely on another team to remediate the issue, then it may take too long to fully resolve an issue, then you extend the window of risk. Instead, perhaps examining the full actions of a user versus just one incident may be a better use of resources.

"The business needs to decide what level of risk to accept, with the guidance of Security to help determine how best to monitor for that risk"

We cannot have this discussion without mentioning tooling. If you don’t have the luxury of a user behavior tool, you have to get creative on what you do have available. If you have a SIEM or other log consolidation tool, then leveraging any type of correlation searches or features will help find riskier actions that will warrant your incident responders valuable time.

Once you start doing more risk-based monitoring, whatever tool you use, tuning is important. Monitoring rules need to offer assurance that they have low false positive rates and truly identify the behavior you believe you think you are monitoring for.

Last, but certainly not least, we need to discuss accountability! This gets pushed off onto the Security Operations Center, when the accountability needs to belong many times to the business. The business needs to decide what level of risk to accept, with the guidance of Security to help determine how best to monitor for that risk.

By considering many of the concepts outlined in this article, you will not only reduce risk, but you will also be creating much more interesting work for your Security Operations team to investigate.