Alert noise reduction

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:

• Triggered by the Alert name.
• Checks if the alert contains entities from a list for our use case.
• Checks if there is/was other similar cases in the previous days. (Using a modified version of the Siemplify action "Get Similar Cases")
• If the number of similar cases equals or is greater than our threshold, the alerts will automatically be closed.

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. ☺️

@Antoine4,

"This might surprise you but we are not currently grouping any alerts."

Can you tell us how you accomplish this?

@Antoine4, 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!