SOLVED

"Azure Monitor for VMs" causing huge data volumes in Sentinel

Brass Contributor

Hi!

We enabled Azure Monitor for VMs for our on premise servers a few weeks ago, and we are very happy with the service so far. The problem is that we have Azure Sentinel connected to our Log Analytics Workspace; and since Azure Monitor for VMs introduces a huge increase in the data ingested into Log Analytics out cost for Sentinel has increased a lot.

There does not seem to be a way to filter what data is being passed on from Log Analytics to Sentinel, so it seems that we are stuck with passing every CPU, Memory and Logical Disk data point into Sentinel, which isn't really very valuable for SIEM/SecOps. And at the current cost rate we won't be able to keep Sentinel Attached, which is a shame.

What are our options here? How can I use Azure Monitor for VMs in conjunction with Sentinel; and only have relevant security events passed to Sentinel?

As a workaround; is there any way to lower the send rate of performance metrics from the OMS Agent? An possibly completely filter out Logical Disk events which counts for 80% of the data and gives us the lease value? Or can we send data to two workspaces from one server?

3 Replies
best response confirmed by Magnus Tjerneld (Brass Contributor)
Solution

@Magnus Tjerneld 

 

There isn't currently a way of filtering out what should not be processed by Sentinel. For this reason, you should probably consider using different workspaces for Azure Monitor for VMs and Sentinel.

 

If you are collecting other data from your VMs besides Performance metrics that you consider useful for Sentinel (e.g., Azure Security Center Standard security events, other system events, custom logs, etc.), then you will need to implement multi-homing (i.e., the same Log Analytics agent sending different data with different purposes to different workspaces). This is however not supported yet for Linux machines. 

 

I recommend you to read this nice article about Sentinel/ASC workspace design, as it might give some more insights: https://techcommunity.microsoft.com/t5/azure-sentinel/best-practices-for-designing-an-azure-sentinel...

@hspintoMultihoming really seems to solve my problem!

I have environments with 50+ VMs, and since I no longer seems to be able to throttle the sampe interval of performance analytics after moving to Azure Monitor for VMs, they each generate ~100MB of perf data per day; so that's 150 gigs of data that I really don't want ingested into Sentinel at an additional $2.30/GB/month ($345).

Thank you very much for taking the time to reply. I've skimmed the article and will read it more carefully, it seems to cover a lot of the stuff I need.

My two insights:
- Log Analytics and Sentinel could really use some basic filtering options.
- Azure Monitor for VMs should have a way to lower the sample interval, like the "old" perfmon ingestion into Log Analytics does. I definitely do not need 1 min sample interval for all my VMs.

Have a great weekend!

1 best response

Accepted Solutions
best response confirmed by Magnus Tjerneld (Brass Contributor)
Solution

@Magnus Tjerneld 

 

There isn't currently a way of filtering out what should not be processed by Sentinel. For this reason, you should probably consider using different workspaces for Azure Monitor for VMs and Sentinel.

 

If you are collecting other data from your VMs besides Performance metrics that you consider useful for Sentinel (e.g., Azure Security Center Standard security events, other system events, custom logs, etc.), then you will need to implement multi-homing (i.e., the same Log Analytics agent sending different data with different purposes to different workspaces). This is however not supported yet for Linux machines. 

 

I recommend you to read this nice article about Sentinel/ASC workspace design, as it might give some more insights: https://techcommunity.microsoft.com/t5/azure-sentinel/best-practices-for-designing-an-azure-sentinel...

View solution in original post