Alert Fatigue And Automation Fatigue

  • SIEM

What is Alert Fatigue?

Alert fatigue is a well-known phenomenon with security products – the security team gets a lot of alerts (from the SIEM, for example), it tries to triage and act upon all of them, but at some point, they are so many and so few of them are actual threats, that the security team just ignores them. And that leads to both overworked security teams and an increased risk for missing an actual threat.

Why is that happening? It’s hard to tweak a system right, no matter how flexible it is. The digital world is so complex that no amount of predefined rules can replace human reasoning about it. Machine learning comes to help, but it’s a black box that too can generate noise, and this noise is even harder to explain than a rule-based alert.

But false positives are often a “feature” because true negatives are a disaster. Vendors will be blamed more if their product misses something, and not for generating more pointless work for analysts. If the security team can say “we weren’t alerted”, the vendor will take all the blame. If the security team missed the alert, because of alert fatigue, then “processes” and “resources” can be blamed, rather than the software. Security is not a “blame game”, but this angle exists in reality.

Alert fatigue and Automation: The Right Path to Efficiency

Then comes automation, as a way to cater to the analysts while still keeping a rate of false positives “just in case”. Automation includes automating evidence gathering, opening tickets and sending messages, executing automated response commands on endpoints. To put it bluntly, automation is “rules on steroids”. And it does save a lot of repetitive tasks for the security team by drawing nice process diagrams and attaching activities to them.

But automation can also be tedious. And a strive to automate everything leads to fatigue as well – to build, fix, document, and maintain the automation. Automations are pseudo-code (and sometimes actual code) and need to be managed appropriately. Sometimes they will be problematic – integrations with ticketing systems will break, credentials will expire, processes will change, network issues will block automated responses. Semi-automated triage will still lead to false positives. No automation is a breeze, and if it isn’t, it’s trivial and probably already automated.

Automation fatigue is not yet a commonly spelt phenomenon, but it is a thing. Automation has to be flexible in order to cover sufficient use cases (e.g. we support executing custom Python scripts in addition to SOAR integrations), but that may lead to more complexity.

The reality is – a security monitoring solution can’t fix vulnerable software and bad configuration. That’s why it always errs on the side of caution. A good SIEM not only shows you where threats are but also helps you fix them so that they no longer occur. That’s a major point of security monitoring – not just detecting threats, but preventing threats in the long run. Yes, threats become more diverse, but if used wisely, a SIEM should generate fewer alerts, in the long run, reducing alert fatigue and diminishing the need for heavy and complex automation. The heavy burden regarding security should be on software vendors, developers, and system and network administrators, rather than on security teams. That’s the sustainable model.

And SIEM is an important tool for that, giving a good overview of where the problems are. It takes extra effort to turn that insight into more secure systems, rather than more fatigue for the security team.

If you are looking to diminish the burden of your security team, LogSentinel Next Gen SIEM will not only alert you of potential threats but will furthermore help you fix them so that they no longer occur. Let us simplify security and compliance for you!


Like this article? Share it with your network!