Ricostruire un attacco multi-stage e multi-domain

Gli incident più difficili da gestire non sono quelli con un alert grave, ma quelli con venti alert mediocri distribuiti su workload diversi. Uno scenario tipico da esame: una mail di phishing consegnata (segnale di Defender for Office 365), un click sull’URL, un processo sospetto sull’endpoint del destinatario (Defender for Endpoint), una raccolta di credenziali seguita da autenticazioni anomale verso il directory on-premises (Defender for Identity) e da un sign-in a rischio nel cloud (Entra ID Protection), infine una condivisione massiva di file da SaaS (Defender for Cloud Apps). Nessuno di questi segnali, preso da solo, giustifica una escalation. Insieme raccontano un kill chain con lateral movement.

Il valore di Microsoft Defender XDR è esattamente questo: la correlazione automatica raggruppa alert eterogenei in un unico incident quando condividono entità comuni (utente, device, file hash, indirizzo IP, mailbox). L’errore da evitare in un SOC — e nelle domande — è trattare gli alert come unità di lavoro indipendenti: si chiude l’alert dell’endpoint come “malware rimosso” senza accorgersi che l’account compromesso continua a muoversi. L’unità di lavoro è l’incident, e la prima azione dell’analista è leggere l’attack story e la lista delle entità coinvolte per capire il perimetro reale.

Quando l’attacco tocca anche fonti non-Microsoft (firewall, proxy, VPN, appliance di rete) entra in gioco Microsoft Sentinel: nel portale unificato gli incident Defender XDR e quelli Sentinel convivono, e i log raccolti via Azure Monitor Agent con le relative data collection rule — oppure via connettori come CommonSecurityLog e Syslog — permettono di estendere la timeline oltre l’ecosistema Microsoft. Per misurare la portata reale della compromissione, le capacità di hunting graph e blast radius aiutano a rispondere alla domanda “chi altro è raggiungibile da questa identità o da questo device”, cioè a stimare l’esposizione laterale invece del solo asset colpito.

Case management: governare il lavoro, non solo l’analisi

Un incident tecnicamente ben ricostruito può comunque fallire dal punto di vista operativo se nessuno sa chi ci sta lavorando, a che punto è, e cosa è già stato verificato. Il case management serve a questo: raccogliere in un unico caso uno o più incident correlati, assegnare un owner, gestire lo stato (nuovo, attivo, chiuso) e la classificazione di chiusura, registrare note e prove, tracciare il passaggio fra tier del SOC.

La distinzione da tenere a mente è netta: un incident è un oggetto di rilevamento, un caso è un oggetto di processo. Le domande d’esame lo sfruttano proponendo scenari in cui il requisito non è “trovare l’attaccante” ma “dimostrare la catena di custodia dell’indagine”, “far lavorare tier 1 e tier 2 sullo stesso evento senza sovrapposizioni”, “collegare tre incident che l’automazione ha creato separatamente ma che appartengono alla stessa campagna”. In tutti questi casi la risposta corretta ruota attorno al case management, non attorno a una nuova analytics rule.

Il case management non sostituisce l’automazione: le automation rule restano lo strumento per reagire in modo deterministico agli eventi di incident (assegnare owner, cambiare severità, chiudere falsi positivi noti, lanciare un playbook Logic Apps). Il caso è il contenitore umano sopra quell’automazione.

Indagine assistita da Security Copilot

Microsoft Security Copilot, integrato nell’esperienza di Defender XDR e Sentinel, affronta un problema molto concreto: il tempo che un analista spende a ricostruire il contesto. Su un incident con decine di alert produce un riepilogo in linguaggio naturale della catena d’attacco, evidenzia entità e comportamenti rilevanti e propone passi successivi di remediation o di ulteriore indagine. Aiuta anche chi non padroneggia KQL, traducendo una domanda in linguaggio naturale in una query di hunting.

Il criterio di scelta è: Copilot accelera triage, sintesi e handover fra turni, non decide al posto dell’analista. L’output va validato contro le evidenze (advanced hunting, tabelle come AlertEvidence, DeviceLogonEvents, IdentityLogonEvents, SigninLogs) prima di trasformarlo in azione di contenimento. La stessa logica vale per le capacità di AI agentica: riducono il lavoro ripetitivo, ma la responsabilità della classificazione e della chiusura resta del SOC.

Trappole tipiche d’esame

  • Alert multipli su workload diversi che sembrano incidenti distinti → un unico incident correlato: la risposta giusta è indagare l’incident aggregato in Defender XDR, non chiudere i singoli alert workload per workload; chiudere l’alert endpoint lascia viva l’identità compromessa.
  • Serve tracciare owner, stato e note dell’indagine su più incident della stessa campagna → case management: non è compito di una analytics rule né di un tag su un singolo incident; il caso è il contenitore di processo che sopravvive alla chiusura dei singoli incident.
  • “Assegna automaticamente l’incident al tier 2 quando la severità è High” → automation rule: l’assegnazione automatica è orchestrazione (trigger su incident creato/aggiornato), mentre il playbook è la Logic App che esegue eventuali azioni esterne; il case management è dove poi si vede e si gestisce quel lavoro.
  • “Riassumi rapidamente un incident con molti alert per l’handover di turno” → Security Copilot: la risposta non è scrivere una hunting query; e ricorda che una hunting query non genera alert, quindi non è mai la soluzione quando il requisito è notificare o creare un incident.
  • “Serve capire quali altri account e device sono esposti dall’identità compromessa” → hunting graph / blast radius: non basta la timeline del singolo device; l’obiettivo è il perimetro laterale, non l’artefatto iniziale.
  • Log di appliance di rete non-Microsoft necessari alla timeline → Microsoft Sentinel con AMA e data collection rule: Defender XDR da solo non copre quelle sorgenti, e il Log Analytics agent/MMA non è più un’opzione valida.