The holy grail for data collection from Windows systems is here. Today marks the beginnings of the capability to enable Azure Sentinel customers to manage and filter the amount of information through the types of Event IDs that are collected and sent to the Log Analytics workspace. This has been a big ask of Azure Sentinel customers. Having the ability to limit the amount of ingestion (hence, ingestion costs) based on filtering is a huge cost saver and it provides the ability for customers to add additional Event IDs important to them when the All Events, Common, and Minimal options aren’t enough.
I’ll be digging into this a bit more, hopefully, this week. But, the following should suffice to get you on your path to working to understanding how to create your own Data Collection Rules.
Today, in the Data Connectors blade in Azure Sentinel, you’ll find a new connector called Windows Security Events. This new connector is in preview.
Inside the new connector, select the Add data collection rule option to create your very first filtering rule.
Most of the wizard steps to create the Data Collection Rule are self-explanatory, except the Custom option in the Collect step. Data Collection Rules support XPath queries. An XPath query is a specific format command that tells the Windows agent which log file and the type of information to pull. You can see in my example above, I only want to collect only System events with Event ID = 4769 (Kerberos).
Learn more about XPath queries: Configure data collection for the Azure Monitor agent (preview) – Azure Monitor | Microsoft Docs
The Docs for the new Windows Security Events connector should be available soon. When available they’ll be located here: Connect Windows security event data to Azure Sentinel (tabbed version) | Microsoft Docs
BIG NOTE: This feature is still rolling out and limited in capability somewhat, but as noted this is the beginning of a much requested capability. Getting familiar with this feature – particularly how to work with XPath queries – is important.
This capability is based on the new Azure Monitor Agent (AMA) – which is also in preview. The AMA supports Azure VMs. To use the AMA with non-Azure VMs the system must have Azure Arc installed and enabled.
This includes:
- Windows servers installed on physical machines
- Windows servers installed on on-premises virtual machines
- Windows servers installed on virtual machines in non-Azure clouds
=========================
[Want to discuss this further? Hit me up on Twitter or LinkedIn]
[Subscribe to the RSS feed for this blog]
[Subscribe to the Weekly Azure Sentinel Newsletter]
