Automatizzare la risposta alle minacce in Microsoft Sentinel con regole di automazione

• Si applica a:

  Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

Questo articolo illustra le regole di automazione di Microsoft Sentinel e come usarle per implementare le operazioni soAR (Security Orchestration, Automation and Response), aumentando l'efficacia del SOC e risparmiando tempo e risorse.

Importante

Microsoft Sentinel è disponibile come parte della piattaforma unificata per le operazioni di sicurezza nel portale di Microsoft Defender. Microsoft Sentinel nel portale di Defender è ora supportato per l'uso in produzione. Per altre informazioni, vedere Microsoft Sentinel nel portale di Microsoft Defender.

Che cosa sono le regole di automazione?

Le regole di automazione sono un modo per gestire centralmente l'automazione in Microsoft Sentinel, consentendo di definire e coordinare un piccolo set di regole che possono essere applicate in diversi scenari.

Le regole di automazione si applicano alle categorie di casi d'uso seguenti:

• Eseguire attività di automazione di base per la gestione degli eventi imprevisti senza usare playbook. Ad esempio:

  • Aggiungere attività sugli eventi imprevisti da seguire per gli analisti.
  • Elimina gli incidenti rumorosi.
  • Valutare i nuovi eventi imprevisti modificandone lo stato da Nuovo a Attivo e assegnando un proprietario.
  • Contrassegnare gli eventi imprevisti per classificarli.
  • Inoltrare un evento imprevisto assegnando un nuovo proprietario.
  • Chiudere gli eventi imprevisti risolti, specificando un motivo e aggiungendo commenti.

• Automatizzare le risposte per più regole di analisi contemporaneamente.

• Controllare l'ordine delle azioni eseguite.

• Esaminare il contenuto di un evento imprevisto (avvisi, entità e altre proprietà) e intraprendere altre azioni chiamando un playbook.

• Le regole di automazione possono anche essere il meccanismo con cui si esegue un playbook in risposta a un avvisonon associato a un evento imprevisto.

In breve, le regole di automazione semplificano l'uso dell'automazione in Microsoft Sentinel, consentendo di semplificare flussi di lavoro complessi per i processi di orchestrazione delle risposte alle minacce.

Componenti

Le regole di automazione sono costituite da diversi componenti:

• Trigger che definiscono il tipo di evento imprevisto che causerà l'esecuzione della regola, soggetto a...
• Condizioni che determineranno le circostanze esatte in cui la regola verrà eseguita ed eseguita...
• Azioni per modificare l'evento imprevisto in qualche modo o chiamare un playbook.

Trigger

Le regole di automazione vengono attivate quando viene creato o aggiornato un evento imprevisto o quando viene creato un avviso. Tenere presente che gli eventi imprevisti includono avvisi e che sia gli avvisi che gli eventi imprevisti possono essere creati dalle regole di analisi, di cui esistono diversi tipi, come illustrato in Rilevare le minacce con regole di analisi predefinite in Microsoft Sentinel.

La tabella seguente illustra i diversi scenari possibili che causeranno l'esecuzione di una regola di automazione.

Tipo di trigger	Eventi che causano l'esecuzione della regola
Quando viene creato un evento imprevisto	Piattaforma unificata per le operazioni di sicurezza in Microsoft Defender: Viene creato un nuovo evento imprevisto nel portale di Microsoft Defender. Microsoft Sentinel non è stato eseguito l'onboarding nella piattaforma unificata: Un nuovo evento imprevisto viene creato da una regola di analisi. Un evento imprevisto viene inserito da Microsoft Defender XDR. Viene creato manualmente un nuovo evento imprevisto.
Quando l'evento imprevisto viene aggiornato	Lo stato di un evento imprevisto viene modificato (chiuso/riaperto/triage). Il proprietario di un evento imprevisto viene assegnato o modificato. La gravità di un evento imprevisto viene generata o ridotta. Gli avvisi vengono aggiunti a un evento imprevisto. Commenti, tag o tattiche vengono aggiunti a un evento imprevisto.
Quando viene creato un avviso	Un avviso viene creato da una regola di analisi di Microsoft Sentinel pianificata o NRT .

Automazione basata su eventi imprevisti o basata su avvisi?

Ora che l'automazione degli eventi imprevisti e l'automazione degli avvisi vengono gestite centralmente dalle regole di automazione e dai playbook, come scegliere quando usare quale?

Per la maggior parte dei casi d'uso, l'automazione attivata dagli eventi imprevisti è l'approccio preferibile. In Microsoft Sentinel, un evento imprevisto è un "file di casi", un'aggregazione di tutte le prove pertinenti per un'indagine specifica. Si tratta di un contenitore per avvisi, entità, commenti, collaborazione e altri artefatti. A differenza degli avvisi che sono singoli elementi di prova, gli eventi imprevisti sono modificabili, hanno lo stato più aggiornato e possono essere arricchiti con commenti, tag e segnalibri. L'evento imprevisto consente di tenere traccia della storia di attacco che continua a evolversi con l'aggiunta di nuovi avvisi.

Per questi motivi, è più opportuno creare l'automazione per gli eventi imprevisti. Il modo più appropriato per creare playbook è quindi basarli sul trigger dell'evento imprevisto di Microsoft Sentinel in App per la logica di Azure.

Il motivo principale per usare l'automazione attivata dagli avvisi è rispondere agli avvisi generati dalle regole di analisi che non creano eventi imprevisti, ovvero quando la creazione degli eventi imprevisti è stata disabilitata nella scheda Impostazioni evento imprevisto della procedura guidata per le regole di analisi.

Questo motivo è particolarmente rilevante quando l'area di lavoro di Microsoft Sentinel viene onboardata nella piattaforma unificata per le operazioni di sicurezza, poiché tutte le operazioni di creazione degli eventi imprevisti si verificano in Microsoft Defender XDR e pertanto le regole di creazione degli eventi imprevisti in Microsoft Sentinel devono essere disabilitate.

Anche senza l'onboarding nel portale unificato, è comunque possibile decidere di usare l'automazione attivata dagli avvisi se si vuole usare un'altra logica esterna per determinare se e come vengono creati eventi imprevisti dagli avvisi, nonché se e come vengono raggruppati gli avvisi in eventi imprevisti. Ad esempio:

• Un playbook può essere attivato da un avviso che non ha un evento imprevisto associato, arricchire l'avviso con informazioni provenienti da altre origini e in base a una logica esterna decidere se creare un evento imprevisto o meno.

• Un playbook può essere attivato da un avviso e, invece di creare un evento imprevisto, cercare un evento imprevisto esistente appropriato a cui aggiungere l'avviso. Altre informazioni sull'espansione degli eventi imprevisti.

• Un playbook può essere attivato da un avviso e avvisa il personale SOC dell'avviso, in modo che il team possa decidere se creare o meno un evento imprevisto.

• Un playbook può essere attivato da un avviso e inviare l'avviso a un sistema di ticket esterno per la creazione e la gestione degli eventi imprevisti, creando un nuovo ticket per ogni avviso.

Nota

• L'automazione attivata dagli avvisi è disponibile solo per gli avvisi creati da regole pianificate, NRT e analisi della sicurezza Microsoft.

• L'automazione attivata dagli avvisi per gli avvisi creati da Microsoft Defender XDR non è disponibile nella piattaforma unificata per le operazioni di sicurezza. Per altre informazioni, vedere Automazione con la piattaforma unificata per le operazioni di sicurezza.

Condizioni

È possibile definire set complessi di condizioni per la governance quando devono essere eseguite le azioni (vedere di seguito). Queste condizioni includono l'evento che attiva la regola (evento imprevisto creato o aggiornato o creato un avviso), gli stati o i valori delle proprietà e delle proprietà dell'entità dell'evento imprevisto (solo per il trigger degli eventi imprevisti) e anche la regola o le regole di analisi che hanno generato l'evento imprevisto o l'avviso.

Quando viene attivata una regola di automazione, controlla l'evento imprevisto di attivazione o l'avviso in base alle condizioni definite nella regola. Per gli eventi imprevisti, le condizioni basate su proprietà vengono valutate in base allo stato corrente della proprietà nel momento in cui si verifica la valutazione o in base alle modifiche apportate allo stato della proprietà (vedere di seguito per informazioni dettagliate). Poiché un singolo evento di creazione o aggiornamento di un evento imprevisto può attivare diverse regole di automazione, l'ordine in cui vengono eseguite (vedere di seguito) fa la differenza nel determinare il risultato della valutazione delle condizioni. Le azioni definite nella regola verranno eseguite solo se tutte le condizioni sono soddisfatte.

Trigger di creazione di eventi imprevisti

Per le regole definite usando il trigger Quando viene creato un evento imprevisto, è possibile definire condizioni che controllano lo stato corrente dei valori di un determinato elenco di proprietà degli eventi imprevisti, usando uno o più degli operatori seguenti:

• è uguale o non è uguale al valore definito nella condizione.
• contiene o non contiene il valore definito nella condizione.
• inizia con o non inizia con il valore definito nella condizione.
• termina con o non termina con il valore definito nella condizione.

Ad esempio, se definisci il nome della regola analitica come Contains == Attacco di forza bruta contro un PC cloud, una regola analitica con l'attacco di forza bruta contro portale di Azure non soddisfa la condizione. Tuttavia, se si definisce il nome della regola analitica come Non contiene == Credenziali utente, l'attacco di forza bruta contro un PC cloud e la forza bruta contro le regole di analisi portale di Azure soddisfano la condizione.

Nota

Lo stato corrente in questo contesto si riferisce al momento in cui viene valutata la condizione, ovvero quando viene eseguita la regola di automazione. Se vengono definite più regole di automazione per l'esecuzione in risposta alla creazione di questo evento imprevisto, le modifiche apportate all'evento imprevisto da una regola di automazione eseguita in precedenza vengono considerate lo stato corrente per le regole di esecuzione successiva.

Trigger di aggiornamento degli eventi imprevisti

Le condizioni valutate nelle regole definite usando il trigger Quando un evento imprevisto viene aggiornato includono tutte quelle elencate per il trigger di creazione dell'evento imprevisto. Ma il trigger di aggiornamento include più proprietà che possono essere valutate.

Una di queste proprietà è Aggiornata da. Questa proprietà consente di tenere traccia del tipo di origine che ha apportato la modifica nell'evento imprevisto. È possibile creare una condizione che valuta se l'evento imprevisto è stato aggiornato da uno dei valori seguenti, a seconda che l'area di lavoro sia stata onboarding nella piattaforma unificata per le operazioni di sicurezza:

Aree di lavoro di cui è stato eseguito l'onboarding

• Un'applicazione, incluse le applicazioni nei portali di Azure e Defender.
• Un utente, incluse le modifiche apportate dagli utenti nei portali di Azure e Defender.
• AIR, per gli aggiornamenti da indagini e risposte automatizzate in Microsoft Defender per Office 365
• Raggruppamento di avvisi (che ha aggiunto avvisi all'evento imprevisto), inclusi i raggruppamenti di avvisi eseguiti sia dalle regole di analisi che dalla logica di correlazione predefinita di Microsoft Defender XDR
• Un playbook
• Una regola di automazione
• Altro, se nessuno dei valori precedenti si applica

Aree di lavoro non caricate

• Un'applicazione
• Un utente di Microsoft Sentinel
• Raggruppamento di avvisi eseguito dalle regole di analisi (che hanno aggiunto avvisi all'evento imprevisto).
• Un playbook
• Una regola di automazione
• Microsoft Defender XDR

Usando questa condizione, ad esempio, è possibile indicare a questa regola di automazione di eseguire qualsiasi modifica apportata a un evento imprevisto, tranne se è stata apportata da un'altra regola di automazione.

Più a questo punto, il trigger di aggiornamento usa anche altri operatori che controllano le modifiche dello stato nei valori delle proprietà degli eventi imprevisti e il relativo stato corrente. Una condizione di modifica dello stato verrebbe soddisfatta se:

Il valore di una proprietà dell'evento imprevisto è stato

• modificato (indipendentemente dal valore effettivo prima o dopo).
• modificato dal valore definito nella condizione.
• è stato modificato nel valore definito nella condizione.
• aggiunto a (questo vale per le proprietà con un elenco di valori).

Proprietà tag : singola e raccolta

La proprietà evento imprevisto Tag è una raccolta di singoli elementi. A un singolo evento imprevisto possono essere applicati più tag. È possibile definire condizioni che controllano singolarmente ogni tag nella raccolta e le condizioni che controllano la raccolta di tag come unità.

• Tutti i singoli operatori di tag controllano la condizione rispetto a ogni tag nella raccolta. La valutazione è vera quando almeno un tag soddisfa la condizione.
• Raccolta di tutti gli operatori di tag controlla la condizione rispetto alla raccolta di tag come singola unità. La valutazione è true solo se la raccolta nel suo complesso soddisfa la condizione.

Questa distinzione è importante quando la condizione è negativa (non contiene) e alcuni tag nella raccolta soddisfano la condizione e altri no.

Di seguito viene illustrato un esempio in cui si trova la condizione, Tag non contiene "2024" e sono presenti due eventi imprevisti, ognuno con due tag:

\Incidenti ▶ Condizione ^ \	Evento imprevisto 1 Tag 1: 2024 Tag 2: 2023	Evento imprevisto 2 Tag 1: 2023 Tag 2: 2022
Qualsiasi singolo tag non contiene "2024"	TRUE	TRUE
Raccolta di tutti i tag non contiene "2024"	FALSE	TRUE

In questo esempio, in Evento imprevisto 1:

• Se la condizione controlla ogni tag singolarmente, poiché esiste almeno un tag che soddisfa la condizione (che non contiene "2024"), la condizione complessiva è true.
• Se la condizione controlla tutti i tag nell'evento imprevisto come singola unità, poiché esiste almeno un tag che non soddisfa la condizione (checontiene "2024"), la condizione complessiva è false.

Nell'evento imprevisto 2 il risultato sarà lo stesso, indipendentemente dal tipo di condizione definito.

Trigger di creazione avvisi

Attualmente l'unica condizione che può essere configurata per il trigger di creazione dell'avviso è il set di regole di analisi per cui verrà eseguita la regola di automazione.

Azioni

Le azioni possono essere definite per l'esecuzione quando vengono soddisfatte le condizioni (vedere sopra). È possibile definire molte azioni in una regola e scegliere l'ordine in cui verranno eseguite (vedere di seguito). È possibile definire le azioni seguenti usando le regole di automazione, senza la necessità di funzionalità avanzate di un playbook:

• Aggiunta di un'attività a un evento imprevisto: è possibile creare un elenco di controllo delle attività che gli analisti seguiranno in tutti i processi di valutazione, indagine e correzione dell'evento imprevisto, per assicurarsi che non vengano persi passaggi critici.

• Modifica dello stato di un evento imprevisto, mantenendo aggiornato il flusso di lavoro.

  • Quando si passa a "chiuso", specificando il motivo di chiusura e aggiungendo un commento. In questo modo è possibile tenere traccia delle prestazioni e dell'efficacia e ottimizzare per ridurre i falsi positivi.

• Modifica della gravità di un evento imprevisto: è possibile rivalutare e modificare la priorità in base alla presenza, all'assenza, ai valori o agli attributi delle entità coinvolte nell'evento imprevisto.

• Assegnazione di un evento imprevisto a un proprietario: consente di indirizzare i tipi di eventi imprevisti al personale più adatto per gestirli o al personale più disponibile.

• Aggiunta di un tag a un evento imprevisto: questo è utile per classificare gli eventi imprevisti in base ai soggetti, agli utenti malintenzionati o a qualsiasi altro denominatore comune.

È anche possibile definire un'azione per eseguire un playbook, per eseguire azioni di risposta più complesse, incluse quelle che coinvolgono sistemi esterni. I playbook disponibili per essere usati in una regola di automazione dipendono dal trigger in cui si basano i playbook e la regola di automazione: solo i playbook di attivazione degli eventi imprevisti possono essere eseguiti da regole di automazione dei trigger di eventi imprevisti e possono essere eseguiti solo dai playbook di attivazione degli avvisi dalle regole di automazione dei trigger di avviso. È possibile definire più azioni che chiamano playbook o combinazioni di playbook e altre azioni. Le azioni verranno eseguite nell'ordine in cui sono elencate nella regola.

I playbook che usano una delle versioni di App per la logica di Azure (Standard o Consumo) saranno disponibili per l'esecuzione da regole di automazione.

Expiration date

È possibile definire una data di scadenza in una regola di automazione. La regola verrà disabilitata dopo tale data. Ciò è utile per la gestione, ovvero la chiusura, di eventi imprevisti "fastidiosi" causati da attività pianificate e limitate nel tempo, come ad esempio i test di penetrazione.

Ordinamento

È possibile definire l'ordine in cui verranno eseguite le regole di automazione. Le regole di automazione successive valuteranno le condizioni dell'evento imprevisto in base al relativo stato dopo l'esecuzione delle regole di automazione precedenti.

Ad esempio, se "Prima regola di automazione" ha modificato la gravità di un evento imprevisto da media a bassa e "Seconda regola di automazione" è stata definita per l'esecuzione solo sugli eventi imprevisti con gravità media o superiore, la Seconda regola non verrà eseguita su questo evento imprevisto.

L'ordine delle regole di automazione che aggiungono attività impreviste determina l'ordine in cui le attività verranno visualizzate in un determinato evento imprevisto.

Le regole basate sul trigger di aggiornamento hanno una coda di ordini separata. Se tali regole vengono attivate per l'esecuzione in un evento imprevisto appena creato (da una modifica apportata da un'altra regola di automazione), verranno eseguite solo dopo l'esecuzione di tutte le regole applicabili in base al trigger di creazione.

Note sull'ordine di esecuzione e sulla priorità

• L'impostazione del numero di ordine nelle regole di automazione determina l'ordine di esecuzione.
• Ogni tipo di trigger mantiene la propria coda.
• Per le regole create nella portale di Azure, il campo dell'ordine verrà popolato automaticamente con il numero che segue il numero più alto usato dalle regole esistenti dello stesso tipo di trigger.
• Tuttavia, per le regole create in altri modi (riga di comando, API e così via), il numero di ordine deve essere assegnato manualmente.
• Non esiste alcun meccanismo di convalida che impedisce a più regole di avere lo stesso numero di ordine, anche all'interno dello stesso tipo di trigger.
• È possibile consentire a due o più regole dello stesso tipo di trigger di avere lo stesso numero di ordine, se non si è interessati all'ordine in cui vengono eseguite.
• Per le regole dello stesso tipo di trigger con lo stesso numero di ordine, il motore di esecuzione seleziona in modo casuale quali regole verranno eseguite in quale ordine.
• Per le regole di tipi di trigger di eventi imprevisti diversi, tutte le regole applicabili con il tipo di trigger di creazione dell'evento imprevisto verranno eseguite per prime (in base ai relativi numeri di ordine) e solo le regole con il tipo di trigger di aggiornamento dell'evento imprevisto (in base ai relativi numeri di ordine).
• Le regole vengono sempre eseguite in sequenza, mai in parallelo.

Nota

Dopo l'onboarding nella piattaforma unificata per le operazioni di sicurezza, se vengono apportate più modifiche allo stesso evento imprevisto in un periodo da cinque a dieci minuti, viene inviato un singolo aggiornamento a Microsoft Sentinel, con solo la modifica più recente.

Casi d'uso e scenari comuni

Attività degli eventi imprevisti

Le regole di automazione consentono di standardizzare e formalizzare i passaggi necessari per la valutazione, l'analisi e la correzione degli eventi imprevisti, creando attività che possono essere applicate a un singolo evento imprevisto, a gruppi di eventi imprevisti o a tutti gli eventi imprevisti, in base alle condizioni impostate nella regola di automazione e alla logica di rilevamento delle minacce nelle regole di analisi sottostanti. Le attività applicate a un evento imprevisto vengono visualizzate nella pagina dell'evento imprevisto, quindi gli analisti hanno l'intero elenco di azioni che devono eseguire, direttamente davanti a loro e non perderanno alcun passaggio critico.

Automazione attivata da eventi imprevisti e avvisi

Le regole di automazione possono essere attivate dalla creazione o dall'aggiornamento degli eventi imprevisti e anche dalla creazione di avvisi. Queste occorrenze possono attivare tutte le catene di risposta automatizzate, che possono includere playbook (sono necessarie autorizzazioni speciali).

Attivare playbook per i provider Microsoft

Le regole di automazione consentono di automatizzare la gestione degli avvisi di sicurezza Microsoft applicando queste regole agli eventi imprevisti creati dagli avvisi. Le regole di automazione possono chiamare playbook (sono necessarie autorizzazioni speciali) e passarvi gli eventi imprevisti con tutti i relativi dettagli, inclusi avvisi ed entità. In generale, le procedure consigliate di Microsoft Sentinel determinano l'uso della coda degli eventi imprevisti come punto focale delle operazioni di sicurezza.

Gli avvisi di sicurezza Microsoft includono quanto segue:

• Microsoft Entra ID
• Microsoft Defender for Cloud
• Microsoft Defender for Cloud Apps
• Microsoft Defender per Office 365
• Microsoft Defender for Endpoint
• Microsoft Defender per identità
• Microsoft Defender per IoT

Più playbook/azioni sequenziati in una singola regola

È ora possibile avere il controllo quasi completo sull'ordine di esecuzione di azioni e playbook in una singola regola di automazione. È anche possibile controllare l'ordine di esecuzione delle regole di automazione stesse. In questo modo è possibile semplificare notevolmente i playbook, ridurli a una singola attività o a una piccola sequenza di attività semplice e combinare questi piccoli playbook in combinazioni diverse in regole di automazione diverse.

Assegnare un playbook a più regole di analisi contemporaneamente

Se si ha un'attività che si vuole automatizzare su tutte le regole di analisi, ad esempio la creazione di un ticket di supporto in un sistema di ticket esterno, è possibile applicare un unico playbook a qualsiasi o a tutte le regole di analisi, incluse eventuali regole future, in un unico colpo. Questo rende semplice ma ripetitivo manutenzione e compiti di manutenzione molto meno di un lavoro.

Assegnazione automatica degli eventi imprevisti

È possibile assegnare automaticamente gli eventi imprevisti al proprietario corretto. Se il SOC dispone di un analista specializzato in una determinata piattaforma, qualsiasi evento imprevisto relativo a tale piattaforma può essere assegnato automaticamente a tale analista.

Eliminazione degli eventi imprevisti

È possibile usare le regole per risolvere automaticamente gli eventi imprevisti noti falsi/benigni senza l'uso di playbook. Ad esempio, quando si eseguono test di penetrazione, si eseguono aggiornamenti o si eseguono aggiornamenti pianificati o si testano procedure di automazione, è possibile creare molti eventi imprevisti falsi positivi che il SOC vuole ignorare. Una regola di automazione limitata al tempo può chiudere automaticamente questi eventi imprevisti durante la creazione, contrassegnandoli con un descrittore della causa della generazione.

Automazione limitata dal tempo

È possibile aggiungere date di scadenza per le regole di automazione. Potrebbero esserci casi diversi dall'eliminazione degli eventi imprevisti che garantiscono un'automazione limitata dal tempo. È possibile assegnare un particolare tipo di evento imprevisto a un determinato utente (ad esempio, un stagista o un consulente) per un intervallo di tempo specifico. Se l'intervallo di tempo è noto in anticipo, è possibile fare in modo che la regola venga disabilitata alla fine della sua pertinenza, senza dover ricordarsi di farlo.

Contrassegna automaticamente gli eventi imprevisti

È possibile aggiungere automaticamente tag di testo libero agli eventi imprevisti per raggrupparli o classificarli in base a qualsiasi criterio scelto.

Casi d'uso aggiunti dal trigger di aggiornamento

Ora che le modifiche apportate agli eventi imprevisti possono attivare regole di automazione, altri scenari sono aperti all'automazione.

Estendere l'automazione quando si evolve l'evento imprevisto

È possibile usare il trigger di aggiornamento per applicare molti dei casi d'uso precedenti agli eventi imprevisti man mano che l'indagine avanza e gli analisti aggiungono avvisi, commenti e tag. Controllare il raggruppamento di avvisi negli eventi imprevisti.

Aggiornare l'orchestrazione e la notifica

Inviare una notifica ai vari team e ad altri team quando vengono apportate modifiche agli eventi imprevisti, in modo da non perdere aggiornamenti critici. Inoltrare gli eventi imprevisti assegnandoli ai nuovi proprietari e informando i nuovi proprietari delle loro assegnazioni. Controllare quando e come vengono riaperti gli eventi imprevisti.

Gestire la sincronizzazione con i sistemi esterni

Se sono stati usati playbook per creare ticket in sistemi esterni quando vengono creati eventi imprevisti, è possibile usare una regola di automazione del trigger di aggiornamento per chiamare un playbook che aggiornerà tali ticket.

Esecuzione delle regole di automazione

Le regole di automazione vengono eseguite in sequenza, in base all'ordine determinato. Ogni regola di automazione viene eseguita al termine dell'esecuzione di quella precedente. All'interno di una regola di automazione, tutte le azioni vengono eseguite in sequenza nell'ordine in cui sono definite.

Le azioni del playbook all'interno di una regola di automazione possono essere trattate in modo diverso in alcune circostanze, in base ai criteri seguenti:

Runtime del playbook	La regola di automazione passa all'azione successiva...
Meno di un secondo	Subito dopo il completamento del playbook
Meno di due minuti	Fino a due minuti dopo l'avvio dell'esecuzione del playbook, ma non più di 10 secondi dopo il completamento del playbook
Più di due minuti	Due minuti dopo l'inizio dell'esecuzione del playbook, indipendentemente dal fatto che sia stato completato o meno

Autorizzazioni per le regole di automazione per eseguire playbook

Quando una regola di automazione di Microsoft Sentinel esegue un playbook, usa un account speciale del servizio Microsoft Sentinel appositamente autorizzato per questa azione. L'uso di questo account al posto dell'account utente aumenta il livello di sicurezza del servizio.

Affinché una regola di automazione esegua un playbook, è necessario che a tale account siano state concesse autorizzazioni esplicite per il gruppo di risorse in cui risiede il playbook. A questo punto, qualsiasi regola di automazione sarà in grado di eseguire qualsiasi playbook in tale gruppo di risorse.

Quando si configura una regola di automazione e si aggiunge un'azione del playbook di esecuzione, verrà visualizzato un elenco a discesa di playbook. I playbook a cui Microsoft Sentinel non dispone delle autorizzazioni verranno visualizzati come non disponibili ("disattivato"). È possibile concedere l'autorizzazione di Microsoft Sentinel ai gruppi di risorse dei playbook sul posto selezionando il collegamento Gestisci autorizzazioni playbook. Per concedere tali autorizzazioni, sono necessarie autorizzazioni di proprietario per tali gruppi di risorse. Vedere i requisiti completi delle autorizzazioni.

Autorizzazioni in un'architettura multi-tenant

Le regole di automazione supportano completamente le distribuzioni tra aree di lavoro e multi-tenant ,nel caso di multi-tenant, usando Azure Lighthouse.

Pertanto, se la distribuzione di Microsoft Sentinel usa un'architettura multi-tenant, è possibile avere una regola di automazione in un tenant che esegue un playbook che si trova in un tenant diverso, ma le autorizzazioni per Sentinel per eseguire i playbook devono essere definite nel tenant in cui risiedono i playbook, non nel tenant in cui sono definite le regole di automazione.

Nel caso specifico di un provider di servizi di sicurezza gestito (MSSP), in cui un tenant del provider di servizi gestisce un'area di lavoro di Microsoft Sentinel in un tenant del cliente, esistono due scenari specifici che garantiscono l'attenzione:

• Una regola di automazione creata nel tenant del cliente è configurata per eseguire un playbook che si trova nel tenant del provider di servizi.

  Questo approccio viene in genere usato per proteggere la proprietà intellettuale nel playbook. Per il funzionamento di questo scenario non è necessario alcun elemento speciale. Quando si definisce un'azione playbook nella regola di automazione e si arriva alla fase in cui si concedono le autorizzazioni di Microsoft Sentinel per il gruppo di risorse pertinente in cui si trova il playbook (usando il pannello Gestisci autorizzazioni playbook), verranno visualizzati i gruppi di risorse appartenenti al tenant del provider di servizi tra quelli tra cui è possibile scegliere. Vedere l'intero processo descritto qui.

• Una regola di automazione creata nell'area di lavoro del cliente (mentre è connesso al tenant del provider di servizi) è configurata per eseguire un playbook che si trova nel tenant del cliente.

  Questa configurazione viene usata quando non è necessario proteggere la proprietà intellettuale. Per il funzionamento di questo scenario, le autorizzazioni per eseguire il playbook devono essere concesse a Microsoft Sentinel in entrambi i tenant. Nel tenant del cliente è possibile concedere le autorizzazioni nel pannello Gestisci autorizzazioni del playbook, proprio come nello scenario precedente. Per concedere le autorizzazioni pertinenti nel tenant del provider di servizi, è necessario aggiungere una delega di Azure Lighthouse aggiuntiva che concede i diritti di accesso all'app Azure Security Insights , con il ruolo Collaboratore automazione di Microsoft Sentinel nel gruppo di risorse in cui risiede il playbook.

  Lo scenario è simile al seguente:

  

  Vedere le istruzioni per configurare questa impostazione.

Creazione e gestione delle regole di automazione

È possibile creare e gestire regole di automazione da aree diverse in Microsoft Sentinel o dalla piattaforma unificata per le operazioni di sicurezza, a seconda delle esigenze e dei casi d'uso specifici.

• Pagina automazione

  Le regole di automazione possono essere gestite centralmente nella pagina Automazione , nella scheda Regole di automazione. Da qui è possibile creare nuove regole di automazione e modificare quelle esistenti. È anche possibile trascinare le regole di automazione per modificare l'ordine di esecuzione, nonché abilitarle o disabilitarle.

  Nella pagina Automazione vengono visualizzate tutte le regole definite nell'area di lavoro, insieme al relativo stato (Abilitato/Disabilitato) e alle regole di analisi a cui vengono applicate.

  Quando è necessaria una regola di automazione che verrà applicata agli eventi imprevisti di Microsoft Defender XDR o da molte regole di analisi in Microsoft Sentinel, crearla direttamente nella pagina Automazione .

• Procedura guidata regole di analisi

  Nella scheda Risposta automatica della procedura guidata per le regole di analisi di Microsoft Sentinel, in Regole di automazione è possibile visualizzare, modificare e creare regole di automazione applicabili alla regola di analisi specifica creata o modificata nella procedura guidata.

  Si noterà che quando si crea una regola di automazione da qui, il pannello Crea nuova regola di automazione mostra la condizione della regola di analisi come non disponibile, perché questa regola è già impostata per l'applicazione solo alla regola di analisi che si sta modificando nella procedura guidata. Tutte le altre opzioni di configurazione sono ancora disponibili.

• Pagina Eventi imprevisti

  È anche possibile creare una regola di automazione dalla pagina Eventi imprevisti per rispondere a un singolo evento imprevisto ricorrente. Ciò è utile quando si crea una regola di eliminazione per chiudere automaticamente gli eventi imprevisti "rumorosi".

  Si noterà che quando si crea una regola di automazione da qui, il pannello Crea nuova regola di automazione ha popolato tutti i campi con i valori dell'evento imprevisto. Viene assegnato alla regola lo stesso nome dell'evento imprevisto, la si applica alla regola di analisi che ha generato l'evento imprevisto e vengono usate tutte le entità disponibili nell'evento imprevisto come condizioni della regola. Vengono anche suggerite un'azione di eliminazione (chiusura) per impostazione predefinita e una data di scadenza per la regola. È possibile aggiungere o rimuovere condizioni e azioni e modificare la data di scadenza, in base alle esigenze.

Passaggi successivi

In questo documento si è appreso come le regole di automazione consentono di gestire centralmente l'automazione delle risposte per gli eventi imprevisti e gli avvisi di Microsoft Sentinel.

• Creare e usare le regole di automazione di Microsoft Sentinel per gestire gli eventi imprevisti.
• Usare le regole di automazione per creare elenchi di attività per gli analisti.
• Per altre informazioni sulle opzioni di automazione avanzate, vedere Automatizzare la risposta alle minacce con playbook in Microsoft Sentinel.
• Per informazioni sull'implementazione dei playbook, vedere Esercitazione: Usare playbook per automatizzare le risposte alle minacce in Microsoft Sentinel.