Co-author - Ashwin Patil
Security teams today face an overwhelming challenge: every data point is now a potential security signal and SOCs are drowning in complex logs, trying to find the needle in...
I have a question regarding these news. https://learn.microsoft.com/en-us/azure/sentinel/whats-new#new-data-sources-for-enhanced-user-and-entity-behavior-analytics-ueba-preview It also includes "DeviceLogonEvents" alongside Okta and other cloud. As for Okta etc its understandable that the connector needs to be connected first. But for the "DeviceLogonEvent" it do exist in XDR already, but not in Sentinel in Azure. In Azure the "DeviceLogonEvent" is part of the Defender for XDR connector. So..... Do we now need to enable the "DeviceLogonEvent" table in the 'Defender for XDR' connector in Sentinel (Azure) for UEBA to work? (more ingestion cost and double storage). Or can we simply just enable it in the XDR portal under Sentinel and UEBA ? (free storage in XDR as its included in Defender for Endpoint).
TL;DR do we need to enable DeviceLogonEvent in the Defender for XDR connector in Sentinel (in azure) to ship the DeviceLogonEvent data to be ingested by Microsoft - or will this new (see screenshoots) UEBA setting in XDR portal automatically understand that the data lives in XDR and correlate the UEBA alerts between both datasources (UEBA settings in xdr+azure)
edit: DeviceLogonEvent is an empty table in Azure -> Sentinel -> tables and has no data until you activate it in Defender for XDR connector. My understanding previously was that "Ueba" lived on top of Sentinel resource and log analytic workspace (which are all in Azure). We kinda need to know if additional datashipping from XDR to Sentinel in Azure is needed so we dont have a blindspot , beliving UEBA is on for the DeviceLogonEvent table but it contains no data in Azure -> Sentinel -> Tables.