Automate your SOC – Noise is the enemy of speed

As you can imagine, Microsoft has a massive security footprint. We’ve published previously that we get more than 20 billion cybersecurity events per day. That is an incredible number and you can imagine how difficult it must be to sort through all that data to find real threats. You may not have that many events, but I bet you struggle with the same issue – sorting through the noise. 

According to David Monahan – research director for Security and Risk Management at EMA, 88 percent of organizations receive up to 500 alerts per day that are classified as “severe” or “critical”. And 67 percent of organizations were only able to investigate 10 or fewer of those severe events per day.

That leads us into the care and feeding of your SIEM or what we like to call “SIEM optimization”. It would be great if all we had to do was ingest logs into a SIEM, turn on some analytic rules and wait for alerts to pop up. But there is no “set it and forget it” when it comes to security. It’s an ongoing process. We need to eliminate false positives, reduce the noise, and make adjustments so we can actually respond to the most important events.

Let’s divide optimization into three parts. (I know there are semantic differences between the word “alert” and the word “incident” when it comes to cybersecurity but for the purposes of this article, I’m going to use the word alert to mean things you have to respond to.)

  1. Too many alerts
  2. Quieting the noise
  3. Responding to the most important alerts

Today, let’s talk about what we should do when we have too many alerts. The first question we need to ask ourselves is “do I really need this alert”. A lot of people think “I want every possible alert that I can possibly get just to be safe” but what really happens when you do that is that you get overwhelmed and end up not responding to much of anything.

Most SIEMs categorize alerts with severity levels like informational, low, medium and high. Or they might use terms like critical or Severity 1, 2 and 3. Regardless of what the label is, our philosophy is that your eyeballs don’t need to see “informational” alerts and maybe not even “low”.

The only alerts you need to see are the ones you’re going to take action on. This could mean that you don’t send the alerts to the SIEM at all (I’ll show you an example of how to do this in Microsoft Sentinel) or that you use automation to close them.

You might ask “why would I want to auto close alerts?”. The answer would be that all telemetry is good. We love telemetry data which feeds the machine learning algorithms that most SIEMs have. Those informational and low alerts can help the machine learning identify patterns and correlate low-fidelity alerts and events across multiple products into high-fidelity and actionable incidents.

So how can you keep from getting alerts in Sentinel? There are two ways.

Stop alerts coming in from other data sources:

In Sentinel, there are analytic rules with the type “Microsoft Security”. These rules automatically create Azure Sentinel incidents from the alerts generated in other Microsoft security solutions like Azure Defender. These rules can be changed to only send alerts of the severity level you desire. To do this, simply open the analytic rule and select the drop-down box under “Severity”. Then simply uncheck the box of the type you no longer want to receive and next your way to the end and save.

Stop alerts from being generated in Sentinel itself:

Select the analytic rule that you no longer want to create alerts on the Incidents page. Select the “Incident settings” tab and select “Disabled” under “Create incident from alerts triggered by this analytics rule”. The rule will continue to collect information for later analysis, it just won’t clog up your Incidents page.

Automatically close an alert:

To auto close an alert, navigate to Automation. Select Create –> Automation rule. Give the rule a name. I’m calling mine “Autoclose NewUser Agent” because I want to automatically close the alert “New UserAgent observed in last 24 hours”.

Under “Conditions”, select the name of the rule or rules you want to automatically close. Under “Actions”, select “Change status ” and pick “Closed”. Then select the reason you want logged. I selected “Undetermined” but pick whichever one you think works best. Then click “Apply” and there you go.

You can also be more specific about which alerts you want closed. For example, only auto close the NewUser agent alerts if the Account Name contains Bob and the IP address is 10.10.10.2.

Hope that was helpful.

See you next time. Mike will be showing you how to run your first STAT playbook.

Check out previous posts:

Let’s automate your SOC – Azure Cloud & AI Domain Blog

Automate your SOC – Let’s talk about STAT, baby – Azure Cloud & AI Domain Blog

Author

2 thoughts on “Automate your SOC – Noise is the enemy of speed