How to Evolve the SOC with Azure Sentinel: Analytics Rules Part 1

Azure Sentinel 3 Minutes

I kicked off this SOC evolution with Azure Sentinel series a few days ago with How to Evolve the SOC with Azure Sentinel: Hunting Queries. I’m not sure yet how many posts will ultimately be in this series, but like I do with SOC efficiency, I’ll probably maintain this series going-forward to ensure we’re always capturing the latest and great information based on Azure Sentinel improvements.

This series is important. As I talked about in the earlier blog post, SOC evolution is critical. Without the intent and ability to evolve the SOC, security teams and team members lose out on valuable intelligence that can be an important factor between identifying a compromise quickly and having to report a mass breach to stockholders. But, also — don’t let the size of your organization fool you. You may think because you have a smaller environment, there’s nothing that a threat actor would want. If you have company data and end user information, you have something that someone wants. So, SOC evolution is just as important for everyone.

For this post’s topic, though, I want to focus on a single area in Azure Sentinel that allows security teams to easily and quickly modify Analytics Rules to aid in the evolution process.

What

Did you know you can quickly and easily modify an Analytics Rule as part of your investigations?

Why

Modifying Analytics Rules on-the-fly is an important part of evolving the SOC to ensure it’s always capable and the most intelligent it can be. Through the investigation process using an Azure Sentinel Incident, an analyst might find that the right Entities aren’t available for proper context. Or, they may find that the Entities list is not complete, i.e., the Incident contains hostname and IP address, but needs username and URL. Remember, the more and better Entities that are contained in the Incident, the more context you have for the investigation to ensure that the event storyline is understood and the Incident can be closed out quickly, efficiently, and correctly.

In future posts, I’ll walk through the specifics for each of the other reasons to modify Analytics Rules but for now, here’s a quick list with short descriptions of why :

  1. The Severity. You may have determined that the issue is not as critical as originally identified for your environment, or vice-versa.
  2. The MITRE tactic. Guidance around the IOC may have changed or been updated by your trusted source.
  3. The Entities. As noted previously, proper context, artifacts, clues, and facts aid in investigations. Without these things investigations are quickly shifted to “cold cases.”
  4. The schedule. There are times when you’ll want to adjust the schedule to be notified sooner – particularly for an active threat. Or, alternatively, you may still want to be notified, but (based on the severity change) not alerted as often.
  5. The noise level. There are many places in the Analytics Rule wizard to adjust noise level for events and Incidents. You can adjust the threshold, group events and alerts, and other things. Eliminating noise ensures that analysts are focusing on the most critical security aspects and keeps them from becoming desensitized to 1,000’s of a similar event record.
  6. Assign automation. Over time, you’ll find that you react the exact same way to certain events. As an analyst, you may have just closed out the 10th similar Incident for the week. Based on your adjusted knowledge of the situation, you can add an automated response that happens every time the Incident is generated.

How

We have recently made the effort of modifying associated Analytics Rules much easier by adding a direct link to the originating Analytics Rule in the Incident’s overview pane.

In the Incidents blade or in the details of the Incident itself, just click through to the Analytics Rule by clicking the link provided as shown in the next image.

Modifying Analytics Rules from an Incident

Clicking the link opens the associated Analytics Rule directly in edit mode (in the wizard).

Knowing that this option exists, and that it’s so easy to access, security teams should have no problem making the SOC more intelligent and adaptable to current threats and evolving IOCs.

As noted prior, I’ll spend some time in the near future to talk through those areas for specific evolution (severity, MITRE, schedule, noise level, and automation) of Analytics Rules. Stay tuned.

=========================

[Want to discuss this further? Hit me up on Twitter or LinkedIn]

Author

Published