Alert noise reduction

Security teams are no strangers to the overload of alerts. Be it via new SIEM rules, a preponderance of detection products added or actual threats, alerts are firing all the time.
Excessive alerts are one of the biggest challenges facing the SOC, so we'd like to devote this thread to peers offering each other actionable guidance and tips that have worked to help you:
--Weed out false positives
--Discover high-priority threats
--Glean useful insights
Consider including the tech that you've tried or worked for you. For example, did you use grouping and automation to reduce the noise and pinpoint the alerts that require attention?
Feel free to be as general or technical as you'd like!
Comments
Hi,
Noise reduction was always a key challenge when designing a new SOC solution. Even from the days when I was on the “detection side” of the solutions map, I remember how noises and false alarms oftenly took the focus away from new detection capabilities that had been added. It becomes vital with Siemplify, as we promise to reduce analysis efforts. New capability
automation, in the shape of policy managers or playbooks, usually gets the highest focus for alerts noise reduction. But when it comes to the soc analyst - grouping similar alerts (by device, threat, etc) really moved the efficiency needle. Whenever the analyst marks an alert as a real incident, we should help them to immediately reach other similar alerts - and raise the urgency. We start out by grouping tens of alerts into 1 case, but with our deep analytics and BI...grouping is about to become more powerful than ever...
Looking forward to getting your feedback as well as ideas for how we can accelerate our grouping capabilities
Hello everyone,
I think noise reduction is a challenge for every SOC and everyone has their way of dealing with it.
There are a few things we are doing to reduce this noise and to provide better insights to the Analysts. This might surprise you but we are not currently grouping any alerts.
For analysts to quickly select the most important cases, we are using a playbook that will provide General Insights about the content of an alert.
For example: If an alert comes up with a threat indicator KNOWN_MALWARE and the policy was not applied or this entity was not blacklisted yet, it will change the stage to Initial Investigation, change the priority of the case and add a general insight warning the Analyst about the threat.
We are using a wide set of indicators to better sort our cases also by adding tags, automatic comments etc.
About the noise reduction, what we are currently focusing on the false-positives which have been most of the alerts in our environments.
We use a playbook that will trigger and do as follow:
Most of our playbooks to close false-positives contains this block, its goal to tell us if the alert is a false-positive or not:
You can see that we select multiple entities by separating them with semicolons.
We have our threshold for the number of similar cases we need to consider this as a repetitive alert (in this case, the threshold is very low because we want all alerts to be tagged as false-positive)
The "days back" does not matter in this use case but can be useful some times.
The custom action "Get Similar Cases From Selection" will return this after execution:
After this block runs, if the output is equals to "matched", our playbook will peacefully close our alert.
This is one of our ways for alert noise reduction. ☺️
@Antoine,
"This might surprise you but we are not currently grouping any alerts."
Can you tell us how you accomplish this?
@Antoine, you mentioned that your team is using a modified version of "Get Similar Cases". Can you share more information on how your team modified this action? I'm looking at ways to modify the same action to get more specific/applicable results. Thanks!