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 Orchestrazione, automazione e risposta della sicurezza (SOAR), aumentando l'efficacia del SOC e risparmiando tempo e risorse.
Importante
Microsoft Sentinel è disponibile al pubblico nel portale di Microsoft Defender nella della piattaforma operativa di sicurezza unificata Microsoft. 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 è 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, soggetto a...
- Condizioni che determineranno le circostanze esatte in cui la regola verrà eseguita e svolta...
- Azioni per modificare l'incidente in qualche modo o chiamare un playbook.
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, di cui esistono diversi tipi, come illustrato in Rilevamento minacce 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 incidente | Piattaforma operativa di sicurezza unificata in Microsoft Defender: Non è stato eseguito l'onboarding di Microsoft Sentinel nella piattaforma: |
| Quando viene aggiornato un incidente | |
| Quando viene creato un avviso |
Automazione basata su incidenti o basata su avvisi?
Ora che l'automazione degli incidenti 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 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 è stata disabilitata nella scheda Impostazioni incidente della procedura guidata per le regole di analisi.
Questo motivo è particolarmente rilevante quando viene eseguito l'onboarding dell'area di lavoro di Microsoft Sentinel nella piattaforma operativa di sicurezza unificata, poiché tutte le operazioni di creazione degli incidenti si verificano in Microsoft Defender XDR e pertanto le regole di creazione degli incidenti 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 come vengono creati incidenti dagli avvisi, nonché se e come vengono raggruppati gli avvisi in incidenti. Ad esempio:
È possibile attivare un playbook da un avviso a cui non è associato un incidente, inoltre è possibile arricchire l'avviso con informazioni provenienti da altre origini e in base a una logica esterna decidere se creare un incidente o meno.
È attivare un playbook da un avviso e, invece di creare un incidente, cercare un incidente esistente appropriato a cui aggiungere l'avviso. Altre informazioni sull'espansione degli incidenti.
È attivare un playbook da un avviso e avvisa il personale SOC dell'avviso, in modo che il team possa decidere se creare o meno un incidente.
È attivare un playbook da un avviso e inviare l'avviso a un sistema di ticket esterno per la creazione e la gestione degli incidenti, creando un nuovo ticket per ogni avviso.
Nota
L'automazione attivata dagli avvisi è disponibile solo per gli avvisi creati da regole di analisi pianificate,NRT e Microsoft Security.
L'automazione attivata dagli avvisi per gli avvisi creati da Microsoft Defender XDR non è disponibile nella piattaforma operativa di sicurezza unificata. 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 (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 verranno 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.
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 incidente, le modifiche apportate all'incidente da una regola di automazione eseguita in precedenza vengono considerate lo stato corrente per le regole di esecuzione successiva.
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'incidente è stato aggiornato da uno dei valori seguenti, a seconda che l'area di lavoro sia stata onboarding nella piattaforma operativa di sicurezza unificata:
- 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 indagine e reazione automatizzati in Microsoft Defender per Office 365
- Raggruppamento di avvisi (che ha aggiunto avvisi all'incidente), 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
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:
| \ Incidenti ▶ Condizione ^ \ |
Incidente 1 Tag 1: 2024 Tag 2: 2023 |
Incidente 2 Tag 1: 2023 Tag 2: 2022 |
|---|---|---|
| Qualsiasi tag individuale non contiene "2024" |
TRUE | TRUE |
| Raccolta di tutti i tag non contiene "2024" |
FALSE | TRUE |
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 sarà lo stesso, indipendentemente dal tipo di condizione definito.
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 verrà 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 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 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 verranno 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) saranno disponibili per l'esecuzione da regole di automazione.
Data di scadenza
È 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 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), 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 nel 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 incidenti differenti, tutte le regole applicabili con il tipo di trigger di creazione dell'incidente verranno 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.
Nota
Dopo l'onboarding nella piattaforma operativa di sicurezza unificata, se vengono apportate più modifiche allo stesso incidente 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 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 perderanno 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 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.
È possibile trattare le azioni del playbook all'interno di una regola di automazione 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 esegui playbook, 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 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), verranno 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 differenti in Microsoft Sentinel o dalla piattaforma operativa di sicurezza unificata, 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 verrà 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.
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 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".
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'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.
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.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per