How to Create an xPath Filter for a Data Collection Rule
In the world of data collection, efficiency is key. Just as my miniature schnauzer buddy, Raven, has a knack for sniffing out the most interesting scents while ignoring the mundane, an xPath filter can be used to streamline data collection by focusing only on the most relevant information. This document will guide you through the process of writing an xPath filter for a data collection rule, ensuring that your data ingress is as efficient and effective as Raven’s nose. Imagine Raven on a walk, surrounded by countless scents. If she were to investigate every single one, she’d waste a lot of time and energy. Instead, she selectively sniffs out the most intriguing smells, saving her effort for what truly matters. Similarly, an xPath filter helps you avoid the unnecessary data, allowing you to zero in on the specific pieces of information you need. By the end of this guide, you’ll be able to create xPath filters that reduce data ingress and improve the overall efficiency of your data collection processes. Windows Event Log capture is a cornerstone of effective security monitoring. It provides a detailed record of events across a multitude of logs, including but not limited to system, application, security, and Application and Service event logs. By capturing these logs, organizations can monitor for suspicious activities, detect potential security breaches, and ensure compliance with regulatory requirements. The detailed information contained in these logs helps security teams identify patterns and anomalies that may indicate malicious behavior, enabling a proactive approach to threat detection and response. One of the primary benefits of Windows Event Log capture is its ability to provide real-time visibility into the activities occurring within an IT environment. This visibility is crucial for identifying and responding to security incidents promptly. For instance, logs can reveal unauthorized access attempts, changes to critical system files, or unusual network traffic patterns. By analyzing these logs, security teams can quickly pinpoint the source of an issue and take appropriate action to mitigate the risk. However, the sheer volume of data generated by Windows Event Logs can be overwhelming. This is where xPath filters come into play. xPath, or XML Path Language, is a powerful tool for querying and filtering XML data. When applied to Windows Event Logs, xPath filters can help security teams focus on the most relevant events, reducing the noise and making it easier to identify significant security incidents. By using xPath filters, organizations can create customized queries that extract specific information from the logs, such as failed login attempts, changes to user privileges, specific error codes, or even events related to specific applications like Microsoft Exchange or SQL Server. The use of xPath filters not only enhances the efficiency of log analysis but also improves the accuracy of threat detection. By narrowing down the data to only the most pertinent events, security teams can reduce false positives and concentrate their efforts on genuine threats. This targeted approach ensures that critical security incidents are not overlooked amidst a sea of irrelevant data. Additionally, xPath filters can be tailored to meet the unique needs of an organization, allowing for a highly customized and effective log monitoring solution. In essence, Windows Event Log capture is an invaluable tool for maintaining the security and integrity of an IT environment. By leveraging xPath filters, organizations can optimize their log analysis processes, ensuring that they can quickly and accurately identify and respond to security threats. Just as Raven, my miniature schnauzer, efficiently sniffs out the most interesting scents, xPath filters help security teams focus on the most critical events, enhancing their ability to protect their systems and data. This document provides guidance on creating an xPath filter for a Data Collection Rule (DCR) for the Azure Monitoring Agent (AMA). A DCR is used to create a filter for user-defined Event IDs from Windows event logs. The xPath filter, which is created by the user, can be applied to both Windows – Azure, Hybrid and Azure Arc devices. The collected events are then sent to an Azure Monitor, Log Analytics Workspace table named "EVENT". To get started the user will need to define a list of Windows Event Logs to capture and the Event IDs within those log(s). There is the option to collect all of the Event IDs but that is not recommended unless specifically needed. All data collected and stored consume storage space which cost money for data ingressed and stored. For the examples within this document, I will collect the following Event IDs from the Event Logs: Security 1102, 4624 System 111, 113, 117 PowerShell Root PowerShell 400 Operational PowerShell 4103, 4104 To review where these are located within the Event logs, there are screen grabs to help find them. Start up the Windows Event Viewer Drill in the Event Viewer to find each Event Log To create an xPath filter, you can have the Event Log Viewer assist in the build. Right click on an Event Log log and select “Filter Current Log” This will bring up the following Window (There are two tabs available): On the “Filter” tab, enter the Event IDs, separating each with a comma. Select the “XML” tab To convert the Event Log Filter into an xPath form for the DCR, the following steps should be performed. Looking at the first screen capture above (Encased in red): <Query Id=”0” Path=”Security”> Copy the name within the quotes Security Append “!” on to the previous results Security! Looking at the second screen capture above (Encased in red): <Select Path=”Security”>*[System[(EventID=1102 or EventID=4624)]]</Select> Copy everything between the two greater than and less than symbols > < on to the previous results Security!*[System[(EventID=1102 or EventID=4624)]] The result is now an xPath filter that can be used with your DCR (To be created later). Note 1: Additional EventIDs can be added to the filter by simply inserting “ or EventID=9999” before the close parenthesis “)”within the xPath filter. Note 2: If all you would like to capture ALL events from a log then only the first 2 bullets above would need to be completed and then a “*” would need to be appended to include all events. Security!* Repeat the process above for each Event Log you would like to capture/filter. From the examples to be used the complete list of xPath filters can be found below. Save the xPath definitions in a text file that will be used in the DCR creation process, coming up next. Security!*[System[(EventID=1102 or EventID=4624)]] System!*[System[(EventID=111 or EventID=113 or EventID=117)]] Windows PowerShell!*[System[(EventID=400)]] Microsoft-Windows-PowerShell/Operational!*[System[(EventID=4103 or EventID=4104)]] Creating a new DCR to capture the data Browse to https://portal.azure.com > “Monitor” Settings > Data Collection Rules Create a Data Collection Rule Select “+ Create” On the “Basic” tab, enter “Rule Name”, “Subscription”, “Resource Group”, “Region” and Windows Using a “Data Collection Endpoint” is optional for this demo On the “Resources” tab, select “Add resources” Browse to the resources to apply this DCR against On the “Collect and deliver” tab Select “+ Add data source” On the sub-tab “Data source”, one by one, copy and paste each xPath filter. Hit “Add” after each paste. After all the xPath’ s have been added they should now be displayed below the entry line as you can see in the example below. On the sub-tab “Destination”, enter “Destination Type”, “Subscription”, and “Destination Details”. The “Destinations Details”, Log Analytics Workspace, is where the Event ID details will be sent within Azure. Enter any Tags required Review the “Review and create”, if all ok, select “Create” The Data Collection Rules blade should now reflect the new rule. When using a “Custom” xPath filter, the “Basic” tab reflects like nothing has been defined. Ensure you review the “Custom” / “Data source” tab to see the filters. After you have created this DCR (xPath filter) the devices that will have this defined against will soon start to send their EventID activities to the “Event” table within the Log Analytics Workspace. To ensure that a device has had the DCR applied against it, the following PowerShell commands can be done to review the definition on the device. From a PowerShell command prompt run the below: Note: The xml output will be stored at c:\temp. Ensure that path exists before running the script below. Connect-AzAccount $subscriptionId = "-------------------------------------" Set-AzContext -SubscriptionId $subscriptionId $resourceGroupName = "RG-Security" $dcrName = "CustomerSpecificRuleSet" # Get the Data Collection Rule and output to a file Get-AzDataCollectionRule -ResourceGroupName $resourceGroupName -Name $dcrName -SubscriptionId $subscriptionId | ConvertTo-Xml -As String -Depth 3 | Out-File -FilePath "C:\temp\dcr.xml" Write-Host "Data Collection Rule details have been written to C:\temp\dcr.xml" Looking in the dcr.xml finds the following: Once the DCR has been applied and events start to be pushed you can now find the events in the “Event” table. Query the Event Table In Azure Monitor > Logs the data can now be queried. A simple query: Event | project TimeGenerated, Source, EventLog, EventID If you notice the event log name and any EventIDs associated are populated within the query. The example only outputs 4 columns, but this was done to provide for display simplicity. Review the schema for a complete set of columns available. In conclusion, just as Raven efficiently sniffs out the most interesting scents on her walks, an xPath filter can help you streamline your data collection by focusing on the most relevant information. By applying the techniques outlined in this document, you can reduce data ingress and ensure that your data collection processes are both efficient and effective. Remember, the key to a successful xPath filter is precision and selectivity, much like Raven’s keen sense of smell. With these skills, you’ll be able to navigate through vast amounts of data and extract only what is necessary, saving time and resources. Happy filtering!
