Due automatismi che agiscono in momenti diversi

Microsoft Defender XDR contiene due meccanismi automatici che gli analisti confondono di continuo, perché entrambi “fanno qualcosa da soli” su un incident. La differenza sta nel momento e nell’obiettivo.

L’automated investigation and response (AIR) entra in gioco dopo che un alert è stato generato: apre un’indagine automatica, esamina gli artefatti coinvolti e ne bonifica quelli giudicati malevoli. È un motore di remediation, e lavora prevalentemente sul perimetro del device.

L’automatic attack disruption agisce invece durante l’attacco: quando la correlazione cross-signal di Defender XDR raggiunge una confidenza molto alta su un pattern noto (ransomware human-operated, business email compromise, adversary-in-the-middle), il servizio contiene subito l’asset, senza aspettare l’analista e senza alcuna logica da configurare. Non bonifica: spezza la kill chain per guadagnare tempo.

AIR: bonifica l’artefatto sul device

AIR parte da un alert e ricostruisce cosa quell’alert ha toccato: file, processi in esecuzione, servizi, scheduled task, chiavi di registro usate per la persistenza, driver. Ogni entità riceve un verdetto (malevola, sospetta, nessuna minaccia trovata) e, per le entità malevole, AIR propone o esegue l’azione di remediation corrispondente — quarantena del file, terminazione del processo, rimozione della persistenza.

La variabile decisiva è il livello di automazione configurato sul device group, non un’impostazione globale del tenant. Con il livello full le azioni vengono eseguite automaticamente; con i livelli semi restano in attesa nell’Action center, dove un analista con i permessi adeguati le approva o le rifiuta; con no automated response AIR indaga ma non rimedia nulla. È il tipico dettaglio che l’esame usa: se lo scenario dice che i device di un reparto sensibile non devono subire azioni automatiche, la risposta è spostarli in un device group con un livello di automazione più basso, non disattivare la funzionalità per tutti.

Esiste un AIR anche in Defender for Office 365, orientato a email e mailbox: lì l’indagine correla messaggi, cluster di email e click, ma le azioni di remediation sulla posta restano soggette ad approvazione dall’Action center. Ricordare la separazione dei workload evita di attribuire a Defender for Endpoint la bonifica di una campagna di phishing.

Attack disruption: contenere mentre l’attacco è in corso

L’attack disruption non nasce da un singolo alert ma dalla correlazione di segnali provenienti da più workload — endpoint, identità, email, SaaS. Quando il livello di confidenza è sufficiente, il servizio esegue azioni di contenimento come contain device (isolare l’endpoint dal traffico laterale) o disable user / contain user (bloccare l’account compromesso e impedirne l’uso dai device onboarded). L’incident viene marcato con un tag dedicato, e le azioni compaiono nell’Action center, dove sono reversibili una volta completata la bonifica.

Due implicazioni pratiche. Primo: le azioni sull’identità presuppongono che il workload corrispondente sia realmente distribuito — Microsoft Entra ID Protection per le identità cloud, Defender for Identity per Active Directory on-premises, con i suoi prerequisiti di configurazione. Secondo: non si “scrive” un attack disruption. Ciò che si governa sono le esclusioni dalle automated response actions, per proteggere account di servizio critici, e la revisione a posteriori delle azioni intraprese.

Quando serve invece una logica personalizzata — aprire un ticket, notificare un canale, chiedere un’approvazione formale, arricchire con threat intelligence — l’ambito non è più Defender XDR ma Microsoft Sentinel: automation rule per orchestrare l’incident e playbook (Logic Apps) per eseguire le azioni.

Trappole tipiche d’esame

  • Il malware va rimosso dal device senza intervento umano → automation level del device group su full: AIR indaga comunque, ma rimedia automaticamente solo se il device group lo consente; un playbook di Sentinel non sostituisce questa impostazione.
  • Un account compromesso sta muovendosi lateralmente adesso → attack disruption: una custom detection rule genera un alert, non contiene nulla; l’attack disruption disabilita o contiene l’identità in tempo reale.
  • Gli account di servizio non devono mai essere disabilitati automaticamente → exclusion list delle automated response actions: non si disattiva l’intera attack disruption per il tenant.
  • Serve un’approvazione formale prima di ogni azione → livelli semi + Action center: le azioni pendenti si approvano lì, con il ruolo appropriato; non esiste un “approva” dentro il singolo alert.
  • Occorre notificare il service desk e aprire un ticket → automation rule + playbook in Sentinel: AIR e attack disruption non integrano sistemi esterni.
  • Il device contenuto è stato bonificato e va rimesso in rete → undo dell’azione dall’Action center: il contenimento è reversibile e tracciato, non richiede di ri-onboardare il device.