AMA: Microsoft SIEM & XDR: unified security operations
At Microsoft Ignite we announced that we are bringing our Microsoft Sentinel and Microsoft Defender XDR products together to deliver an optimized and unified security operations experience. We are combining the full power of these products into a single portal enhanced with more comprehensive features, automation, guided experiences, and Microsoft Security Copilot. Bring your questions to this Ask Microsoft Anything (AMA) as members of our Microsoft Security engineering team bring clarity and insights about this new experience. This session is part of the Microsoft Security Tech Accelerator. RSVP for event reminders, add it to your calendar, and post your questions and comments below! This session will also be recorded and available on demand shortly after conclusion of the live event.
TLS for Sentinel Syslog CEF Data connector(Secure Transfer of logs to Sentinel Log analytics workspa
Sentinel Data connector Syslog CEF is a feature that allows you to collect data from various sources using the Common Event Format (CEF) or Syslog protocols and send it to Azure Sentinel, a cloud-native security information and event management (SIEM) solution. By using this connector, you can integrate your existing security tools and devices with Sentinel and gain more visibility and insights into your network and security events. Ingest syslog and CEF messages to Microsoft Sentinel - AMA | Microsoft Learn The connection using this method happens over TCP/UDP 514 which is in plain text. However, some sources may require a secure connection to transmit data using Syslog over TLS (Transport Layer Security). This ensures that the data is encrypted and authenticated between the sender and the receiver. In this article, we will show you how to configure TLS for Syslog on a Linux machine and connect it to Azure Sentinel using the Sentinel Data connector for CEF.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!
I don't understand the ability to connect Ueba to multiple data sources.
Hello, I have connected UEBA in my environment, but I don't understand what it offers to connect the log sources of Audit Logs, Azure Activity, Security Events and Login Logs. According to UEBA, it collects alert information from other connectors such as Microsoft Defender for Endpoint, bookmarks or activities to generate these user behaviour profiles, so I don't understand why connect the aforementioned data sources? That added value where can you see it? Regards.
KQL: setting query time leads to problem in watchlist column projecting
Hello to the community! I have stumbled upon a very strange issue when using watchlists. I have a watchlist with 2 columns (userPrincipalName,allowedActivity) that I am then using to whitelist activities. Watchlist is imported using: let WhitelistedUsers = _GetWatchlist("testQuery") | project userPrincipalName, allowedActivity; Then I wanted to set it to a specific time frame to test it on given data set: set query_now = datetime("1/14/2022, 1:45:46.556 PM"); Problem is that when setting my query for a specific time, I get the following error from the watchlist: 'project' operator: Failed to resolve scalar expression named 'userPrincipalName'. Commenting the set query_now solves the project problem (not my problem though). I tried to set the time before and after watchlist import but that does not solve the issue. I could not find any posts around the topic (quite a specific one), so anyone observed similar behaviors or has a possible explanation? I can probably work around the set query_now with other functions but I gotten used to it, and find this behavior extremely strange
How can I detect someone enabling Forensic Evidence Capturing?
Someone recently drew my attention to Microsoft Purview's Forensic Evidence Capturing feature under insider risk management-- powerful stuff! But also a feature I would only want to see turned on if duly authorized. How can I detect someone enabling this in Microsoft Sentinel? I tried enabling/disabling it but do not see any events referencing "forensic evidence" generated anywhere.
Manage Microsoft 365 Defender Alerts in Azure Sentinel
We're trying to find a way to manage the 'out of the box' alerts that come with Defender 365 about 95% of which are FP. Is there a way to build some sort of dashboard in Sentinel with alerts? I don't mean incidents, we aren't there yet, I just mean alerts? Preferably, with enough information about the alert that the analyst can make a quick decision and move on... Thanks!!
