There’s an old Polish proverb that says: “A noisy cow gives little milk.” This saying is aptly applied to Intrusion Detection Systems (IDS) in the realm of cybersecurity.

Everybody has IDSs, as they should, but they have become a major pain point for security teams. As Field CTO, I’m out there every day visiting and talking to CISOs and the issue of noisy IDS’s never fails to come up.

What role do IDSs play in your security network, and why are they so noisy?

The role of IDSs is to monitor a network or system for malicious activity or policy violations. The reason IDSs are so noisy is because they are everywhere. As they are Internet facing, it basically means they are open to the world. They monitor traffic from both east/west and north/south coverage, from department to department, from users to services and vice versa.

But more than any other security tool, IDSs are trigger happy. For IDSs, a single indication can lead them to determine an anomaly, even without relevant context, leading to mountains of false positives. Many signature-based IDSs are old or not well defined and are not effectively maintained – hence even more false alerts.

For example, when we do an internal vulnerability assessment test in our network, the IDS picks it up (it’s really good at it). The vulnerability scanning tool will try all the methods available to figure out the next stage of the vulnerability, whether it is successful or not, and will show all the lines of the interrogation. The IDS will pick up all these activities -very thorough, but VERY noisy.

The result of all this is hundreds of thousands, even millions of alerts every day to the security team. I hear this from all sorts of organizations, from small colleges with a few thousand hosts, to huge telcos with over one hundred thousand hosts. Even the large SOC teams with dozens of analysts at some of the biggest companies can’t deal with the daily barrage of alerts from their IDS.

What can be done to better manage noisy IDSs? 

So how do SOC teams try to deal with their noisy IDS tools? One way is to set them so that a certain percentage of the alerts are automatically discarded. But this is risky, as we can’t be confident that the type of alerts we “drop” don’t hold valuable information on real potential threats.

There are a number of steps security professionals can take to improve the performance of their IDS tools, and lower the noise:

1. Classify the triggered attack signature into MITRE ATT&CK^TM representations. MITRE is a common language used by SOC analysts which allows the teams to accelerate investigation and response.
2. Prioritize the defined MITRE ATT&CK^TM techniques and tactics in your organization: What type of technique is more important? What type is less? Who is the attack targeting (ie. Focusing on the entities in the organization)? Then define your dashboards accordingly.
3. Eliminate noise: correlate triggered attack signatures (classified into these prioritized MITRE ATT&CK^TM behaviors) with other third-party data sources to triage and validate each alert, including an integration with vulnerability assessment tools.

At the end of the day, IDSs are really only doing what they are supposed to do – alert. But to get the “milk” from this noisy cow, it must be paired up with tools that can take the mass of alerts and use automation to sift through them, floating up to the SOC teams a much smaller group of truly high-risk alerts.

I was working with a billion-dollar manufacturing company whose Suricata IDS alerted about a malicious internal host. The alert could easily have gotten lost in the mountain of over a hundred thousand alerts it brought in that day, and shut the factory down, causing grave damage to the business. With the combination of automation technology that we brought to the table, and the Suricata’s alert, we were able to weed out this truly high-risk alert from the haystack and stop the attack in its tracks.

I began with a Polish proverb, and so I’ll end with another proverb, this time an African one: Noise and hunting don’t go together. This is as true in the wild desert of security networks as it is in the African savannah.