Logging, monitoring, and alerting programs are some of the most critical elements of any security and compliance program, but traditional approaches for implementing and upgrading these capabilities are often noisy, expensive, and laborious.

Traditional Alerting Approaches are Failing

During program assessments, we find that a lot of clients are generating so many alerts that they simply do not have the staff to look into each of them. Usually, these situations are a result of the following approach, which I refer to as the ‘traditional’ approach:

1. Purchase a tool with the most security and compliance correlation capabilities
2. Connect it to all possible systems
3. Enable all of the alerts that apply to the environment
4. Get overwhelmed by the volume of alerts
5. Try to tune back the alerts over time, but never make real headway because so much time is spent responding to alerts

From Security Information and Event Management (SIEM) systems to intrusion detection to file integrity monitoring, many organizations are generating a lot of alerts that simply never get reviewed. While there is some value in enabling effective forensics after an issue has occurred, it often fails to live up to the initial value proposition of empowering teams to identify and disrupt active attacks.

The main challenge here is not the tools or the people, it’s the approach. Like learning to swim by diving into choppy deep-sea waters or learning to ride a horse by climbing onto a wild mustang, alerts based on complex correlations of multiple sources that are designed to identify highly technical environmental issues might not be the best place to start. We have all heard the saying the enemy of good is perfect. Attempting to develop a monitoring program that covers everything is challenging and often takes so long to establish that by the time it is in place, the environment has changed and the monitoring program no longer covers what it should.

An analogy we often use is a treadmill. You can go out and buy the best treadmill in the world, but it won't have any benefit to your health unless you use it—and use it as part of an overall program. Understanding your overall security program and how monitoring and alerting can fit into that is essential. Without a solid understanding of your risks, data, and processes, it is challenging to know what is most important to monitor.

Align With the Business (Processes)

The good news is that whether you are building out new alerting processes or looking to improve existing ones, you can build some very good and very simple alerts based on how your organization has implemented its business processes, and you don’t need to throw out everything you’ve already done.

For instance, pretend you have an environment with a few administrators, a few privileged service accounts, and a handful of helpdesk accounts. Now, also pretend that there is a rule/process/policy in place that suggests that only helpdesk team members should create new accounts – admins and service accounts generally never create accounts. In this scenario, it is probably extremely easy to set up an alert that triggers whenever a non-helpdesk account is used to create a new account. Since this should only happen on an exception basis, the alert is not very noisy. Also, in this case, we may want to send these alerts to the administrators as well as to a central security team. This helps the admins stay aware of exception-oriented activity in their systems and could even allow them to proactively ‘call off’ the security team if the account was a legitimate process exception that they had to perform.

Because adversaries are not necessarily experts on your internal business processes, these kinds of exception-based, business-process-oriented alerting mechanisms can be extremely effective in identifying abnormal activity without overwhelming response teams.

Additionally, because the managers responsible for specific individuals and/or processes are often uniquely suited to help identify indicators of compromise concerning their areas of responsibility, it can be a good idea to interview them to ensure that alerts related to their areas are effectively and comprehensively designed.

Furthermore, these managers are often highly interested in unexpected activity related to their areas. Because they are often aware of legitimate process exceptions, we have seen organizations have great success in utilizing business managers as the first tier of analysis for alerts related to their processes.

Slow and Steady Wins the Race

Lastly, these rules should be built out slowly over time as a part of a program that continuously improves, they should not be implemented all at once as a single project. This will allow the alerting teams and processes to grow naturally over time.

It is also important to continuously review the monitoring and alerting processes to ensure that the rules are still effective for addressing their intended risks, and to ensure that new technologies are added to your monitoring and alerting processes.

Whether it is related to how data is flowing, who is executing sensitive system actions, or detecting unusual behavior in communication platforms, implementing business process-oriented alerts can significantly improve the quality of your alerting program. Additionally, if you leverage internal business expertise and build out these alerts over time you can make these improvements without major outlays of time or money.