Nello stesso obiettivo d’esame convivono due meccanismi che non condividono né portale né ruoli: le regole di automazione con i playbook, che reagiscono, e l’audit unificato di Microsoft Purview, che ricostruisce a posteriori.

Tre trigger, e il terzo è quasi un altro prodotto

Una regola di automazione parte su tre eventi: incidente creato, incidente aggiornato, alert creato. I primi due li userai quasi sempre: l’incidente è il contenitore modificabile che aggrega alert, entità, commenti e tag, mentre l’alert è una singola prova immutabile.

Il trigger sull’alert esiste per un caso preciso: le regole analitiche che NON creano incidenti — tipicamente in un workspace collegato al portale Defender, dove gli incidenti nascono lì e le regole di creazione incidenti di Sentinel vanno disattivate. Due limiti da ricordare a memoria: il trigger vale solo per alert generati da regole Scheduled e NRT di Sentinel — quelli di Defender XDR non lo attivano — e l’unica condizione configurabile è il nome della regola analitica, mentre l’unica azione disponibile è “Run playbook”. Niente cambio di stato, di severità, di owner, di tag: quelle azioni vivono solo sull’incidente.

Sul trigger di aggiornamento la grammatica delle condizioni si allarga: oltre a equals e contains compaiono gli operatori di transizione (changed, changed from, changed to, added) e la proprietà “Updated by”, che distingue se la modifica arriva da un utente, un’applicazione, un playbook o un’altra regola di automazione. È il modo standard per non farsi rincorrere dalle proprie regole.

Trappola sottile: il Tag è una collezione, e “Any individual tag” (vero se almeno un tag soddisfa la condizione) e “Collection of all tags” danno esiti opposti sullo stesso incidente quando la condizione è negativa.

L’ordine non è un dettaglio estetico

Le regole girano in sequenza, mai in parallelo, e ogni trigger ha la propria coda: quelle di creazione girano prima di quelle di aggiornamento. Le regole successive valutano l’incidente nello stato in cui l’hanno lasciato le precedenti: se la prima abbassa la severità a Low, una seconda filtrata su Medium o superiore non parte più.

Il campo Order si autopopola solo dal portale: via API lo assegni tu, e due regole con lo stesso numero girano in ordine casuale.

Il default che sorprende di più: la regola attende un playbook al massimo due minuti, poi passa all’azione successiva a prescindere dall’esito. Se l’azione seguente dipende dall’output della precedente, quel comportamento va progettato, non subito.

La scadenza sulla regola è il modo pulito per sopprimere il rumore di un penetration test senza ricordarsi di disattivarla. Per sapere a posteriori che cosa ha toccato l’automazione:

SecurityIncident
| where ModifiedBy contains "Automation"

Il permesso che esegue il playbook non è il tuo

Quando una regola esegue un playbook non usa la tua identità: usa un account di servizio dedicato di Sentinel. Quell’account deve avere il ruolo Microsoft Sentinel Automation Contributor sul resource group in cui vive il playbook, non sul singolo playbook: è la ragione per cui, nel menu a tendina della regola, alcuni playbook appaiono in grigio. Per concedere quel permesso ti servono Owner o User Access Administrator sul resource group; per eseguire i playbook ti serve inoltre Logic App Contributor.

I ruoli lato Sentinel sono separati: Microsoft Sentinel Responder apre l’incidente ma non lancia il playbook, Playbook Operator lo lancia a mano, Contributor lo aggancia a una regola. E i trigger devono combaciare: da una regola con trigger incidente sono selezionabili solo playbook con trigger incidente.

Interrogare Purview Audit dal portale Defender

L’audit non è un log di Sentinel: è il registro unificato di Microsoft Purview, e nel portale Defender lo raggiungi dalla pagina Audit.

https://security.microsoft.com/auditlogsearch

È la stessa ricerca del portale Purview, sullo stesso backend. Prerequisiti: il ruolo View-Only Audit Logs o Audit Logs in Exchange Online (per default nei gruppi Compliance Management e Organization Management) e l’audit acceso nel tenant. La verifica va fatta in Exchange Online PowerShell — in Security & Compliance PowerShell la stessa proprietà risponde sempre False anche ad audit attivo:

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

Qui l’audit copre Defender XDR e Defender for Endpoint: isolamento di un dispositivo, indicatori di compromissione, modifiche ai ruoli, regole di rilevamento personalizzate.

I numeri da sapere: la conservazione è 180 giorni con Audit (Standard) — erano 90 per i record generati prima del 17 ottobre 2023 — mentre Audit (Premium) porta a un anno per Entra ID, Exchange, SharePoint e OneDrive tramite una policy predefinita, e a dieci anni solo con l’add-on per utente. L’intervallo massimo di una singola ricerca è 180 giorni; ogni account ha dieci ricerche in parallelo, di cui una sola non filtrata; l’export arriva a 50.000 righe con Standard e a 1.000.000 con Premium.

Due avvertenze. I record non sono immediati: per i servizi principali la disponibilità tipica è 60-90 minuti dopo l’evento, senza garanzia. E “Keyword Search” cerca solo nello schema comune indicizzato, non nel contenuto AuditData: se la stringa vive solo nel payload, non la trovi. Per quello c’è Search-UnifiedAuditLog, il cmdlet Exchange Online che sta sotto la pagina di ricerca.

Infine, le unità amministrative di Purview restringono la ricerca: un amministratore ristretto vede solo i log degli utenti della propria unità, e alcune operazioni restano visibili al solo amministratore non ristretto.