Un segnale, un proprietario

Nel portale unificato Microsoft Defender XDR tutto converge: incident correlati, evidence, advanced hunting. Proprio per questo l’esame ribalta la domanda: non “dove guardo”, ma “quale prodotto deve essere presente perché quel segnale esista”. Se il workload non è coperto, l’incident in Defender XDR non nasce affatto, e nessuna analytics rule di Microsoft Sentinel potrà recuperarlo. Ragiona sempre in due passi. Primo: dove vive l’entità osservata — un device, una mailbox, un account di Active Directory on-premises, un account cloud, un’app SaaS, una VM o un container. Secondo: quale prodotto raccoglie telemetria proprio da quel punto. La domanda “chi possiede il segnale” precede sempre la domanda “quale regola scrivo”.

Endpoint, mail e collaboration

Microsoft Defender for Endpoint possiede tutto ciò che accade sulla macchina: creazione di processi, connessioni di rete uscenti, scritture su disco, modifiche al registry, logon locali. È il prodotto delle tabelle DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents, ed è l’unico che offre response action sull’host: device isolation, live response, restrizione dell’esecuzione delle app. Anche le regole di attack surface reduction vivono qui.

Microsoft Defender for Office 365 possiede il messaggio e il contenuto condiviso: recapito, verdetto di filtraggio, allegati detonati con Safe Attachments, URL riscritti da Safe Links, oltre a Teams, SharePoint e OneDrive come vettori di file malevoli. Le tabelle sono EmailEvents, EmailAttachmentInfo, EmailUrlInfo e UrlClickEvents. Se lo scenario parla di phishing consegnato, di rimozione post-delivery o di un utente che ha cliccato un link, il proprietario è Defender for Office 365, non l’endpoint — anche se poi il payload esplode sul device e i due alert finiscono nello stesso incident.

Le due identità: on-premises e cloud

È qui che si concentra la confusione più costosa. Microsoft Defender for Identity monitora Active Directory on-premises tramite sensor installati sui domain controller (e sui server di ruolo AD FS / AD CS): ricognizione di utenti e gruppi, enumerazione SMB e LDAP, attacchi Kerberos (pass-the-hash, pass-the-ticket, golden ticket), DCSync, movimento laterale, percorsi di attacco verso account privilegiati. Le sue tabelle sono IdentityLogonEvents, IdentityDirectoryEvents, IdentityInfo.

Microsoft Entra ID Protection riguarda invece l’identità cloud: rilevamenti di rischio su sign-in e su utente, credenziali trapelate, indirizzi IP anonimi, viaggi atipici, sessioni sospette. Il suo output naturale non è un sensor su un server, ma un livello di rischio consumato da una Conditional Access policy risk-based (richiedi MFA, forza il password change, blocca). In Sentinel quei segnali arrivano soprattutto via SigninLogs e AuditLogs di Microsoft Entra ID. Regola mnemonica: sensor sul domain controller = Defender for Identity; risk level su un sign-in = Entra ID Protection.

SaaS e workload cloud

Microsoft Defender for Cloud Apps possiede le applicazioni SaaS: discovery dello shadow IT, session e access policy tramite Conditional Access App Control, app OAuth con permessi eccessivi, download massivi o condivisioni anomale in app di terze parti. La tabella di riferimento è CloudAppEvents.

Microsoft Defender for Cloud possiede i workload cloud e ibridi: VM, container e Kubernetes, database SQL e open source, storage account, App Service, key vault, oltre alla postura (CSPM, secure score, raccomandazioni). Nomi quasi identici, ambiti opposti: Cloud Apps è il SaaS che gli utenti usano, Defender for Cloud è l’infrastruttura che tu esponi. Nota che la protezione runtime dei server abilitata da Defender for Cloud si appoggia a Defender for Endpoint sulla macchina, mentre la raccolta di log verso Sentinel passa da Azure Monitor Agent con le data collection rule.

Trappole tipiche d’esame

  • Rilevare pass-the-ticket o DCSync su un domain controller → Defender for Identity: l’opzione “Entra ID Protection” è il distrattore classico; Entra ID Protection non vede il traffico Kerberos on-premises.
  • Bloccare un accesso da credenziali trapelate a un account cloud → Entra ID Protection + Conditional Access risk-based: installare un sensor non serve; l’azione vive nella policy, non su un server.
  • Utente che scarica in massa da un’app SaaS di terze parti → Defender for Cloud Apps: Defender for Cloud (nome simile) copre VM, container e database, non l’app SaaS.
  • Container Kubernetes con immagine vulnerabile o attività sospetta nel cluster → Microsoft Defender for Cloud: nessun prodotto “endpoint” copre il piano dei workload cloud e la postura.
  • Un utente ha cliccato un URL di phishing consegnato via mail → Defender for Office 365: UrlClickEvents e EmailUrlInfo sono suoi; DeviceNetworkEvents mostrerà semmai la connessione successiva, non il verdetto sul messaggio.
  • Voglio i security event dei domain controller in Microsoft Sentinel → Azure Monitor Agent con una data collection rule verso SecurityEvent: è ingestion SIEM, non sostituisce Defender for Identity né i suoi rilevamenti comportamentali.