It’s funny, the first question out of my mouth when a customer asks for help tuning the noise for Azure Sentinel is: “Is your noisiest connection MCAS, by any chance?”
95% of the responses are a resounding: “Yes”
Most customers think that it’s Azure Sentinel’s problem, but it’s not. It’s actually a tuning issue for the originating service.
One of the noisiest services can be Microsoft Cloud App Security (MCAS) – if not <ahem> tuned correctly. Seeing the value of a service like MCAS, a lot of times organizations will turn on everything sometimes just to see the system work. And, in doing so, doesn’t do it against best practices and doesn’t go back later to adjust and tune the system. And, then, because of this Azure Sentinel becomes MCAS’s noisebox.
MCAS does an amazing job. It’s almost too good.
Here’s a great example.
The MCAS policy called “Administrative activity from a non-corporate IP address” can get noisy. By default, though, the policy is configured to generate an alert for EVERY SINGLE TIME the system identifies the policy criteria. And, because we have the Azure Sentinel Data Connector for MCAS enabled, every single alert shows up in the Azure Sentinel console. EVERY SINGLE ALERT.
Do yourself a favor. For MCAS policies like this, modify the filter so that repeated activities are lumped together into single alerts. You’re still capturing everything, its just that now all of those alerts are grouped together into single Incidents in the Azure Sentinel console.
The example above will lump together every 5 alerts over 30 minutes. Test in your own environment to find the right combination that’s less noisy without compromising how often you want to be alerted. For me…I’m probably going to change that filter setting to 20 over 1 hour.
Now, this is just one example. There are many MCAS policies that can be adjusted for noise. If you start to see a number of duplicate MCAS-generated Incidents in Azure Sentinel, you can search the Incident title against the MCAS policy title and make the adjustments in the MCAS portal.
If you need help tuning MCAS, feel free to reach out to your Microsoft rep. We have some great MCAS experts who would be happy to help.
UPDATE: Next in this series: Tuning the MCAS Analytics Rule for Azure Sentinel: System Alerts and Feature Deprecation
Want a quick view into exactly how many alerts are being generated by MCAS? Run the following KQL query in Azure Sentinel.
//Show how many alerts have been generated by a specific service. Example here is MCAS. Change Product to the service you want info on. SecurityIncident | extend Product = todynamic((parse_json(tostring(AdditionalData.alertProductNames)))) | where Product has "Microsoft Cloud App Security" | summarize count() by tostring(AlertIds) | summarize sum(count_)
[Want to discuss this further? Hit me up on Twitter or LinkedIn]
2 thoughts on “Tuning the Noise Out of MCAS for Azure Sentinel”
You must log in to post a comment.