How to configure Security Events collection with Azure Monitor Agent
Published Mar 17 2023 04:59 AM 14.9K Views
Microsoft

Although Microsoft Defender for Servers (part of the Microsoft Defender for Cloud suite) does not rely on security events collection to provide its protection capabilities, customers may want to collect this valuable data to bring additional context to their server security investigations or alerts. For this reason, Defender for Servers Plan 2 users benefit from a 500-MB free data ingestion allowance (per day, per server) into Log Analytics, as long as the Defender for Servers Plan 2 is also enabled on the machines scope where security events are collecte....

 

Security events collection (for Windows systems only) is done with the help of a guest agent. This has been possible so far with the legacy Log Analytics agent and the Defender for Servers auto-provisioning experience, and is also possible for Microsoft Sentinel users, via the Log Analytics and Azure Monitor Agent (AMA) data connectors. However, if you are not a Sentinel user yet and you are using Defender for Servers with the new AMA experience, it is still possible to collect security events, as you will learn next.

 

A sample of security events collected by the Azure Monitor AgentA sample of security events collected by the Azure Monitor Agent

  

 

Azure Monitor Agent Security Events Data Collection Rule

 

Everything collected by the AMA is configured by means of a Data Collection Rule (DCR). This is also true for Windows security events and, one of the great advantages of AMA, you can filter data collection to only the event IDs that matter to you. If life was simple, you could just configure a Windows Event Log DCR for that. However, your data would be ingested into the Log Analytics Event table, which is not included in the data types covered by the free 500-MB Defender for Servers allowance and does not integrate very well with the investigation experience Azure security analysts prefer.

 

To achieve the optimal (security- and cost-wise) experience, you need your data to be ingested into the SecurityEvent table. This is done by crafting a DCR that uses the Microsoft-SecurityEvent AMA stream and can be done in several ways. Let’s look at two of them in the following sections.

 

Important: you must specify an event filter according to the options described here. For custom event filters, see how to define XPath queries.

 

Azure PowerShell

 

The first option is to use the Add-AMASecurityEventDCR.ps1 PowerShell script that allows you to create a Data Collection Rule for Security Events collection by Azure Monitor Agents running in your Windows servers. After downloading and unblocking the script, you can run it using the syntax below:

 

 

 

 

 

 

./Add-AMASecurityEventDCR.ps1 -DcrName "<DCR name>" -ResourceGroup "<DCR resource group>" -SubscriptionId "<DCR subscription>" -Region "<DCR region>" -LogAnalyticsWorkspaceARMId "<Log Analytics Workspace ARM resource ID>" -EventFilter AllEvents|Common|Minimal|Custom [-CustomEventFilter "<XPath query 1>","<XPath query 2>","<XPath query N>"]

 

 

 

 

 

 

This script only creates the Data Collection Rule. Don't forget to create the Data Collection Rule Associations for each of the Virtual Machines you want to collect Security Events from.

 

The script usage syntax and some examples are available in its GitHub repository.

 

Custom Azure Policy initiative

 

You can also use a more scalable and complete solution, based on the deployment of a Policy Initiative ARM template that not only creates the AMA Security Events DCR but will also create a DCR association with each Windows Virtual Machine in the same region.

Once deployed, you can assign the Configure Data Collection Rule for Security Events collection Policy initiative at the desired scope, by filling in the required and optional parameters:

 

  • Effect - DeployIfNotExists or Disabled.
  • Workspace Resource Id - Log Analytics Workspace where to send the Security Events to (must have Defender for Servers Plan 2 enabled).
  • DCR Region - the Azure region where you want the Data Collection Rule to be deployed.
  • DCR Resource Group - the (new or existing) Resource Group name where you want the Data Collection Rule to be deployed.
  • Security Events Filter - either AllEvents, Common, Minimal or Custom.
  • Custom xPath Queries - only required if you specify Custom as the filter.
  • Additional Virtual Machine Images - only required if you have Windows VMs that are not based on Azure Marketplace images.

 

The Policy initiative parameters and deployment steps are available in its GitHub repository.

 

Conclusion

 

Security events are records of activities or changes in your environment that can indicate potential threats or vulnerabilities. You can use security events to analyze alerts in Microsoft Defender for Servers Plan 2. This article described how to collect security events with the new Azure Monitor Agent (AMA), for customers who are not using Microsoft Sentinel.

 

One of the main advantages of using AMA is the complete control over the granularity of security events you collect as well as the potentially multiple Log Analytics workspace destinations. You can optimize the data you collect by focusing on the most relevant Event IDs, according to your security policies.

 

For more details and examples on how to investigate alerts, see how to manage security alerts in Microsoft Defender for Cloud.

 

Acknowledgements

 

Special thanks to the reviewers of this article:

 

Gopal Shankar, Senior PM Manager

Tom Janetscheck, Senior PM

2 Comments
Co-Authors
Version history
Last update:
‎Apr 24 2024 09:53 AM
Updated by: