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

Questo articolo illustra le regole di automazione di Microsoft Sentinel e come usarle per implementare le operazioni Security Orchestration, Automation and Response (SOAR). Le regole di automazione aumentano l'efficacia del SOC e consentono di risparmiare tempo e risorse.

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 è possibile applicare 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 incidenti senza usare playbook. Ad esempio:

  • Aggiungere attività sugli incidenti che gli analisti devono seguire.
  • Elimina gli incidenti rumorosi.
  • Valutare i nuovi incidenti modificandone lo stato da Nuovo a Attivo e assegnando un proprietario.
  • Contrassegnare gli incidenti per classificarli.
  • Inoltrare un incidente assegnando un nuovo proprietario.
  • Chiudere gli incidenti 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 incidente (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 avviso non associato a un incidente.

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 incidente che causerà l'esecuzione della regola, in base alle condizioni.
• Condizioni che determineranno le circostanze esatte in cui la regola verrà eseguita e svolge azioni.
• Azioni per modificare l'evento imprevisto in qualche modo o chiamare un playbook, che esegue azioni più complesse e interagisce con altri servizi.

Trigger

Le regole di automazione vengono attivate quando viene creato o aggiornato un incidente o quando viene creato un avviso. Tenere presente che gli incidenti includono avvisi e che è possibile creare sia gli avvisi che gli incidenti dalle regole di analisi, come illustrato in Rilevamento minacce in Microsoft Sentinel.

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

Automazione basata su incidenti o basata su avvisi?

Con le regole di automazione che gestiscono centralmente la risposta a eventi imprevisti e avvisi, come scegliere quali automatizzare e in quali circostanze?

Per la maggior parte dei casi d'uso, l'automazione attivata dagli incidenti è l'approccio preferibile. In Microsoft Sentinel, un incidente è 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 incidenti sono modificabili, hanno lo stato più aggiornato ed è possibile arricchirli con commenti, tag e segnalibri. L'incidente 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 incidenti. Il modo più appropriato per creare playbook è quindi basarli sul trigger degli incidenti 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 incidenti, ovvero quando la creazione degli incidenti è disabilitata nella scheda Impostazioni incidente della procedura guidata per le regole di analisi.

Questo motivo è particolarmente rilevante quando l'area di lavoro di Microsoft Sentinel viene onboarding nel portale di Defender. In questo scenario, tutta la creazione di eventi imprevisti avviene nel portale di Defender 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 desidera usare un'altra logica esterna per determinare se e quando creare incidenti dagli avvisi, nonché come vengono raggruppati gli avvisi. Ad esempio:

• Un playbook attivato da un avviso a cui non è associato un incidente è in grado di arricchire l'avviso con informazioni provenienti da altre origini e decidere in base a una logica esterna se creare un incidente o meno.

• Un playbook attivato da un avviso è invece in grado di creare un incidente e cercare un incidente esistente appropriato a cui aggiungere l'avviso. Altre informazioni sull'espansione degli incidenti.

• Un playbook attivato da un avviso è in grado di avvisare il personale SOC dell'avviso, in modo che il team possa decidere se creare o meno un incidente.

• Un playbook attivato da un avviso è in grado di inviare l'avviso a un sistema di ticket esterno per la creazione e la gestione degli incidenti, il quale crea un nuovo ticket per ogni avviso.

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 (creazione o aggiornamento di un incidente o creazione di un avviso), gli stati o i valori delle proprietà dell'incidente delle proprietà dell'entità (solo per il trigger degli incidenti) e anche la regola o le regole di analisi che hanno generato l'incidente o l'avviso.

Quando viene attivata una regola di automazione, controlla l'incidente di attivazione o l'avviso in base alle condizioni definite nella regola. Per gli incidenti 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 incidente 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 sono eseguite solo se tutte le condizioni sono soddisfatte.

Trigger di creazione di incidenti

Per le regole definite usando il trigger Quando viene creato un incidente, è possibile definire condizioni che controllano lo stato corrente dei valori di un determinato elenco di proprietà degli incidenti, 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 si definisce il nome della regola analitica come Contiene == Attacco di forza bruta contro un Cloud PC, una regola analitica con l'attacco di forza bruta contro il portale di Azure non soddisfa la condizione. Tuttavia, se si definisce il nome della regola analitica come Non contiene == Credenziali utente, entrambe le regole di analisi Attacco di forza bruta contro un Cloud PC e Forza bruta contro il portale di Azure soddisfano la condizione.

Trigger di aggiornamento degli incidenti

Le condizioni valutate nelle regole definite usando il trigger Quando un incidente viene aggiornato includono tutte quelle elencate per il trigger di creazione dell'incidente. Ma il trigger di aggiornamento include più proprietà che è possibile valutare.

Una di queste proprietà è Aggiornato da. Questa proprietà consente di tenere traccia del tipo di origine che ha apportato la modifica nell'incidente. È possibile creare una condizione che valuta se l'evento imprevisto è stato aggiornato da uno dei valori seguenti, a seconda che sia stata eseguita l'onboarding dell'area di lavoro nel portale di Defender:

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

Inoltre, il trigger di aggiornamento usa anche altri operatori che controllano le modifiche dello stato nei valori delle proprietà degli incidenti e il relativo stato corrente. Una condizione di modifica dello stato verrebbe soddisfatta se:

Il valore di una proprietà dell'incidente è stato

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

Proprietà Tag: individuale rispetto raccolta

La proprietà dell'incidente Tag è una raccolta di singoli elementi. A un singolo incidente è possibile applicare più tag. È possibile definire condizioni che controllano singolarmente ogni tag nella raccolta e le condizioni che controllano la raccolta di tag come unità.

• Gli operatori Qualsiasi tag individuale controllano la condizione rispetto a ogni tag nella raccolta. La valutazione è true quando almeno un tag soddisfa la condizione.
• Gli operatori Raccolta di tutti i tag controllano 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 incidenti, ognuno con due tag:

In questo esempio, in Incidente 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'incidente come singola unità, poiché esiste almeno un tag che non soddisfa la condizione (che contiene "2024"), la condizione complessiva è false.

Nell'incidente 2 il risultato è lo stesso, indipendentemente dal tipo di condizione definito.

Proprietà di entità supportate

Per l'elenco delle proprietà di entità supportate come condizioni per le regole di automazione, vedere Informazioni di riferimento sulle regole di automazione di Microsoft Sentinel.

Trigger di creazione avvisi

Attualmente l'unica condizione che è possibile configurare per il trigger di creazione dell'avviso è il set di regole di analisi per cui viene eseguita la regola di automazione.

Azioni

È possibile definire le azioni per l'esecuzione quando vengono soddisfatte le condizioni (vedere sopra). È possibile definire molte azioni in una regola, oltre che scegliere l'ordine in cui vengono 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 incidente: è possibile creare un elenco di controllo delle attività che gli analisti devono seguire in tutti i processi di valutazione, indagine e correzione dell'incidente, 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 l'uso 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 incidenti possono essere eseguiti da regole di automazione dei trigger di incidenti e solo i playbook di attivazione degli avvisi possono essere eseguiti da regole di automazione dei trigger di avvisi. È possibile definire più azioni che chiamano playbook o combinazioni di playbook e altre azioni. Le azioni sono eseguite nell'ordine in cui sono elencate nella regola.

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

Data di scadenza

È possibile definire una data di scadenza in una regola di automazione. La regola viene disabilitata dopo il passaggio di 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 sono eseguite le regole di automazione. Le regole di automazione successive valutano le condizioni dell'evento imprevisto in base al relativo stato dopo che il suddetto è stato soggetto alle 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" è definita per l'esecuzione solo su eventi imprevisti con gravità Media o più alta, la suddetta non viene eseguita su tale evento imprevisto.

L'ordine delle regole di automazione che aggiungono attività di eventi imprevisti determina l'ordine in cui le attività vengono visualizzate in un determinato incidente.

Le regole basate sul trigger di aggiornamento hanno una coda di ordini separata. Se tali regole vengono attivate per l'esecuzione in un incidente appena creato (da una modifica apportata da un'altra regola di automazione), vengono 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 nel portale di Azure, il campo dell'ordine è 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 vengono eseguite in quale ordine.
• Per le regole di tipi di trigger di incidenti differenti, tutte le regole applicabili con il tipo di trigger di creazione dell'incidente vengono eseguite per prime (in base ai relativi numeri di ordine) seguite dalle regole con il tipo di trigger di aggiornamento dell'incidente (in base ai relativi numeri di ordine).
• Le regole vengono sempre eseguite in sequenza, mai in parallelo.

Casi d'uso e scenari comuni

Attività degli incidenti

Le regole di automazione consentono di standardizzare e formalizzare i passaggi necessari per la valutazione, l'analisi e la correzione degli incidenti, creando attività che è possibile applicare a un singolo incidente, a gruppi di incidenti o a tutti gli incidenti, 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 incidente vengono visualizzate nella pagina dell'incidente, quindi gli analisti hanno l'intero elenco di azioni che devono eseguire, direttamente davanti a loro e non perdono alcun passaggio critico.

Automazione attivata da incidenti e avvisi

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

Attiva i playbook per i provider Microsoft

Le regole di automazione consentono di automatizzare la gestione degli avvisi di sicurezza Microsoft applicando queste regole agli incidenti creati dagli avvisi. Le regole di automazione possono chiamare playbook (sono necessarie autorizzazioni speciali) e passarvi gli incidenti con tutti i relativi dettagli, inclusi avvisi ed entità. In generale, le procedure consigliate di Microsoft Sentinel determinano l'uso della coda degli incidenti 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 desidera 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 incidenti

È possibile assegnare automaticamente gli incidenti al proprietario corretto. Se il SOC dispone di un analista specializzato in una determinata piattaforma, è possibile assegnare automaticamente qualsiasi incidente relativo alla piattaforma a tale analista.

Eliminazione degli incidenti

È possibile usare le regole per risolvere automaticamente gli incidenti 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 incidenti falsi positivi che il SOC vuole ignorare. Una regola di automazione limitata al tempo può chiudere automaticamente questi incidenti 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 incidenti che garantiscono un'automazione limitata dal tempo. È possibile assegnare un particolare tipo di incidente 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 incidenti

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

Casi d'uso aggiunti dal trigger di aggiornamento

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

Estendere l'automazione quando si evolve l'incidente

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

Aggiornare l'orchestrazione e la notifica

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

Gestire la sincronizzazione con i sistemi esterni

Se sono stati usati playbook per creare ticket in sistemi esterni quando vengono creati incidenti, è possibile usare una regola di automazione del trigger di aggiornamento per chiamare un playbook che aggiorna 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.

È possibile trattare le azioni del playbook all'interno di una regola di automazione in modo diverso in alcune circostanze, in base ai criteri seguenti:

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 può eseguire qualsiasi playbook in tale gruppo di risorse.

Quando si configura una regola di automazione e si aggiunge un'azione esegui playbook, viene visualizzato un elenco a discesa di playbook. I playbook a cui Microsoft Sentinel non dispone delle autorizzazioni sono visualizzati come non disponibili ("disattivato"). È possibile concedere l'autorizzazione di Microsoft Sentinel ai gruppi di risorse dei playbook on-the-spot selezionando il link Gestisci autorizzazioni playbook. Per concedere tali autorizzazioni, sono necessarie autorizzazioni 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), sono visualizzati i gruppi di risorse appartenenti al tenant del provider di servizi tra quelli tra cui è possibile scegliere. 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 nel portale di Defender, a seconda delle esigenze e dei casi d'uso specifici.

• Pagina Automazione

  È possibile gestire le regole di automazione 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 viene applicata agli incidenti di Microsoft Defender XDR o da molte regole di analisi in Microsoft Sentinel, crearla direttamente nella pagina Automazione.

• Procedura guidata per le regole di analisi

  Nella scheda Risposta automatica della procedura guidata per la 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.

  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 Incidenti

  È anche possibile creare una regola di automazione dalla pagina Incidenti per rispondere a un singolo incidente ricorrente. Ciò è utile quando si crea una regola di eliminazione per chiudere automaticamente gli incidenti "rumorosi".

  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'incidente. 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.

Esportare e importare regole di automazione

Esportare le regole di automazione nei file modello di Azure Resource Manager (ARM) e importare regole da questi file, come parte della gestione e del controllo delle distribuzioni di Microsoft Sentinel come codice. L'azione di esportazione crea un file JSON nel percorso di download del browser, che è quindi possibile rinominare, spostare e gestire in altro modo come qualsiasi altro file.

Il file JSON esportato è indipendente dall'area di lavoro, quindi può essere importato in altre aree di lavoro e anche in altri tenant. Come codice, può anche essere controllato dalla versione, aggiornato e distribuito in un framework CI/CD gestito.

Il file include tutti i parametri definiti nella regola di automazione. Le regole di qualsiasi tipo di trigger possono essere esportate in un file JSON.

Per istruzioni sull'esportazione e l'importazione di regole di automazione, vedere Esportare e importare regole di automazione di Microsoft Sentinel.

Passaggi successivi

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

• Creare e usare regole di automazione di Microsoft Sentinel per gestire gli incidenti.
• 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.