Il portale Microsoft Defender XDR (security.microsoft.com) è il punto unico da cui un amministratore Microsoft 365 governa il ciclo di vita di un incidente: dalla correlazione automatica degli alert fino alle azioni di contenimento su dispositivi, identità e caselle di posta. Sapere quale strumento usare per quale requisito è esattamente ciò che l’esame MS-102 verifica.

Il ciclo di risposta all’incidente

Un incident è un contenitore che raggruppa alert correlati provenienti da più workload — Microsoft Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps ed Microsoft Entra ID Protection — insieme a tutte le entità coinvolte (dispositivi, utenti, mailbox, file, URL).

Il flusso operativo standard:

  1. Triage nella incident queue — filtra per severità, stato, assegnatario, tag e servizio di origine. La colonna Impacted assets dice subito quanto è esteso il raggio.
  2. Assegnazione — imposta Assign to me o a un collega e porta lo stato da Active a In progress.
  3. Investigazione — esamina le schede Alerts, Devices, Users, Mailboxes, Evidence and Response e l’Attack story (grafo dell’attacco).
  4. Contenimento — azioni sulle entità (vedi sotto).
  5. Chiusura — porta lo stato a Resolved e compila Classification (True positive / Informational, expected activity / False positive) e Determination (Malware, Phishing, Multistage attack, Security testing, Line-of-business application…). Questi campi alimentano il tuning del modello.

Azioni di contenimento

Requisito Azione Dove
Bloccare un endpoint compromesso mantenendo la connessione a Defender Isolate device (Full o Selective) Device page / incident
Fermare un account usato dall’attaccante Suspend user / Disable user in Microsoft Entra ID, Require sign-in o reset password User page, Entra ID
Rimuovere una mail malevola recapitata Soft delete (Move to Deleted Items / Recoverable Items) Threat Explorer → Take action
Bloccare un file su tutti i device Stop and quarantine file, indicatore su hash Action center / Indicators
Raccogliere forensics Collect investigation package, Run antivirus scan, Initiate Live Response Device page

L’isolamento selettivo lascia attive Outlook, Teams e Skype for Business; quello full taglia tutto tranne il canale verso il servizio Defender. La soft delete da Threat Explorer sposta i messaggi nella cartella Recoverable Items: l’utente può ancora recuperarli, quindi non è una rimozione definitiva.

Advanced hunting: tabelle e KQL

L’advanced hunting interroga in Kusto Query Language uno schema condiviso fra i workload:

  • Device: DeviceEvents, DeviceProcessEvents, DeviceNetworkEvents, DeviceLogonEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceInfo
  • Email: EmailEvents, EmailAttachmentInfo, EmailUrlInfo, EmailPostDeliveryEvents, UrlClickEvents
  • Identità: IdentityLogonEvents, IdentityDirectoryEvents, IdentityQueryEvents, IdentityInfo
  • Cloud app: CloudAppEvents (include l’audit di Exchange Online, SharePoint, Teams)
  • Alert: AlertInfo, AlertEvidence

Operatori essenziali:

EmailEvents
| where Timestamp > ago(7d) and DeliveryAction == "Delivered"
| where ThreatTypes has "Phish"
| join kind=inner EmailUrlInfo on NetworkMessageId
| summarize Conteggio = count() by RecipientEmailAddress, UrlDomain
| project RecipientEmailAddress, UrlDomain, Conteggio
| order by Conteggio desc

where filtra, project seleziona/rinomina colonne, summarize aggrega con count()/dcount()/make_set() e clausola by, join correla tabelle (chiave tipica NetworkMessageId per l’email, DeviceId/AccountObjectId altrove), extend crea colonne calcolate, take/limit campiona.

Regole di detection personalizzate

Da una query si può creare una custom detection rule: frequenza Near real-time (NRT), 1, 3, 12 o 24 ore. Requisiti tassativi: la query deve restituire Timestamp, ReportId e almeno una colonna entità (DeviceId, DeviceName, AccountObjectId, AccountSid, RecipientEmailAddress, SHA1…), altrimenti il salvataggio fallisce. La regola può generare un alert e innescare azioni automatiche (isolate, run AV scan, block file).

Trappole tipiche d’esame

  • Scenario: ti chiedono di indagare un evento avvenuto 60 giorni fa in advanced hunting → Risposta giusta: non è possibile, i dati di advanced hunting hanno 30 giorni di retention. Per periodi superiori usa il Unified Audit Log in Microsoft Purview o l’esportazione verso Microsoft Sentinel.
  • Scenario: hai chiuso manualmente tutti gli alert ma l’incidente risulta ancora Active → Risposta giusta: chiudere gli alert non chiude l’incidente; devi impostare lo stato dell’incidente su Resolved (risolvere l’incidente, invece, chiude gli alert correlati).
  • Scenario: l’AIR ha identificato la remediation ma il device non è stato pulito → Risposta giusta: il gruppo di dispositivi è in automazione semi-automatica; l’azione è nel tab Pending dell’Action center e richiede approvazione. Solo Full — remediate threats automatically agisce senza intervento.
  • Scenario: devi rimuovere una mail di phishing già consegnata a 500 utenti → Risposta giusta: Threat Explorer → Take action → Soft delete (o hard delete), non una regola di trasporto: quest’ultima agisce solo sui messaggi futuri.
  • Scenario: la custom detection rule non si salva → Risposta giusta: mancano Timestamp, ReportId o la colonna entità nella project finale.