Due livelli di automazione, una sola catena di risposta

In Microsoft Sentinel l’automazione della risposta si legge su due piani distinti. Il primo è l’automation rule: logica di orchestrazione che vive dentro Sentinel, non richiede alcuna risorsa esterna e lavora sulle proprietà dell’incident. Il secondo è il playbook, che non è una funzione di Sentinel ma una Logic App vera e propria, con i suoi connector, la sua identità e il suo costo di esecuzione.

La domanda che l’esame ti fa risolvere è quasi sempre la stessa, travestita in scenari diversi: l’azione richiesta si esaurisce dentro Sentinel oppure deve toccare un sistema esterno? Se resta dentro — cambiare stato, severità, owner, tag, chiudere un incident — è automation rule. Se esce — aprire un ticket, scrivere su un canale, disabilitare un account, isolare un device — serve un playbook. Confondere i due piani è l’errore più penalizzato in questa area.

Automation rule: orchestrazione nativa dell’incident

Una automation rule si attiva su tre trigger: quando un incident viene creato, quando un incident viene aggiornato, quando un alert viene creato. Sul trigger si innestano condizioni valutate sulle proprietà dell’incident — titolo, severità, tactics, nome dell’analytics rule che l’ha generato, tag, owner, stato — e infine le azioni.

Le azioni native coprono il ciclo di vita dell’incident: assegnare un owner, cambiare severità, cambiare stato (compreso il passaggio a Closed con una classificazione come falso positivo), aggiungere tag, aggiungere task alla checklist di case management. Tutto questo avviene senza deployare nulla: non c’è una Logic App dietro, non c’è consumo a esecuzione, non ci sono connection da autorizzare.

Due dettagli che l’esame ama. Primo: le regole hanno un ordine di esecuzione, quindi una catena di regole si progetta pensando a chi tocca l’incident per primo. Secondo: una automation rule può avere una data di scadenza, il che la rende lo strumento corretto per sopprimere rumore temporaneo — una finestra di manutenzione, un pen test pianificato — senza disattivare l’analytics rule e senza perdere la telemetria sottostante.

Nota sul trigger alert created: un alert non ha stato, owner o severità modificabile come un incident, quindi in quel caso l’automazione serve essenzialmente a lanciare un playbook.

Playbook: quando l’azione esce da Sentinel

Il playbook entra in gioco quando la risposta richiede un sistema che Sentinel non governa. È una Logic App con un trigger specifico: incident trigger, alert trigger o entity trigger. La distinzione conta, perché determina come il playbook può essere invocato. Un playbook con incident trigger si attacca a una automation rule; uno con entity trigger si esegue manualmente dalla pagina di una entity durante l’indagine — tipicamente per arricchire un IP con threat intelligence esterna o interrogare un sistema terzo su un utente.

Perché Sentinel possa eseguire un playbook servono permessi espliciti sul resource group che ospita la Logic App (il ruolo dedicato Microsoft Sentinel Automation Contributor). È un requisito di autorizzazione, non di configurazione della regola: se manca, il playbook semplicemente non è selezionabile o non parte.

Come si combinano

Il pattern di produzione è ibrido: l’automation rule fa da orchestratore e il playbook da esecutore. La regola valuta le condizioni, applica le azioni native (tag, severità, owner) e, come ulteriore azione, invoca il playbook per la parte che esce da Sentinel. Non è un aut-aut: è una gerarchia. Il playbook non decide se agire, riceve un incident già filtrato e agisce.

Trappole tipiche d’esame

  • Chiudere automaticamente gli incident di una specifica analytics rule come falso positivo → automation rule: azione nativa sullo stato dell’incident, nessun playbook e nessuna Logic App. Se una risposta propone un playbook per chiudere un incident, è la scelta più costosa e non la richiesta.
  • Notificare un canale Teams, aprire un ticket o disabilitare un account → playbook invocato da una automation rule: l’azione tocca un sistema esterno, quindi serve un connector Logic App. L’automation rule da sola non ha azioni verso l’esterno.
  • Sopprimere il rumore di una detection durante una finestra pianificata → automation rule con expiration date: disattivare l’analytics rule o escludere la data source ferma anche l’ingestion e il rilevamento, e non è ciò che lo scenario chiede.
  • Il playbook non compare fra le azioni della automation rule → permessi o trigger sbagliato: manca il ruolo Microsoft Sentinel Automation Contributor sul resource group della Logic App, oppure il playbook usa alert/entity trigger dove serve un incident trigger.
  • Arricchire una singola entity durante l’indagine, on demand → playbook con entity trigger eseguito manualmente: le automation rule non si lanciano su una entity, agiscono su incident e alert.
  • Assegnare owner e severità a tutti gli incident di un certo tipo → automation rule, valutata sulle proprietà dell’incident: è triage, non risposta attiva; introdurre una Logic App qui aggiunge costo ed è la classica risposta “tecnicamente possibile ma sbagliata”.