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.
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 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:
- To activate the SecurityEvent table on the Log Analytics workspace, you must enable the Security solution on the workspace. This can be done either by enabling Defender for Servers at the Log Analytics workspace level or by running the Azure PowerShell instructions below:
- Install-Module Az.MonitoringSolutions
- New-AzMonitorLogAnalyticsSolution -Type Security -ResourceGroupName <LA workspace RG> -Location <LA workspace region> -WorkspaceResourceId <LA workspace full ARM resource ID>
- 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
Microsoft
