Regole di analisi pianificate in Microsoft Sentinel

Per gran parte il tipo più comune di regola di analisi, regole di pianificate sono basate su query Kusto configurate per l'esecuzione a intervalli regolari ed esaminare i dati non elaborati da un periodo di "lookback" definito. Le query possono eseguire operazioni statistiche complesse sui dati di destinazione, rivelando baseline e outlier in gruppi di eventi. Se il numero di risultati acquisiti dalla query supera la soglia configurata nella regola, la regola genera un avviso.

Questo articolo illustra come vengono compilate le regole di analisi pianificate e presenta tutte le opzioni di configurazione e i relativi significati. Le informazioni contenute in questo articolo sono utili in due scenari:

• Creare una regola di analisi da un modello: usare la logica di query e le impostazioni di pianificazione e lookback come definito nel modello o personalizzarle per creare nuove regole.

• Creare una regola di analisi da zero: creare una propria query e una regola da zero. A tale scopo, è necessario disporre di un grounding approfondito nel linguaggio di query Kusto e Data Science.

Modelli di regole di analisi

Le query in modelli di regole pianificati sono state scritte da esperti di sicurezza e data science, Microsoft o dal fornitore della soluzione che fornisce il modello.

Usare un modello regola di analisi selezionando un nome di modello dall'elenco dei modelli e creando una regola basata su di esso.

Ogni modello include un elenco delle origini dati necessarie. Quando si apre il modello, le origini dati vengono controllate automaticamente per la disponibilità. La disponibilità indica che l'origine dati è connessa e che i dati vengono inseriti regolarmente attraverso di essa. Se una delle origini dati necessarie non è disponibile, non sarà consentito creare la regola e potrebbe essere visualizzato anche un messaggio di errore.

Quando si crea una regola da un modello, viene aperta la creazione guidata delle regole in base al modello selezionato. Tutti i dettagli vengono compilati automaticamente ed è possibile personalizzare la logica e altre impostazioni delle regole in base alle esigenze specifiche. È possibile ripetere questo processo per creare più regole in base al modello. Quando si raggiunge la fine della creazione guidata delle regole, le personalizzazioni vengono convalidate e la regola viene creata. Le nuove regole vengono visualizzate nella scheda Regole attive nella pagina Analisi. Analogamente, nella scheda Modelli di regola, il modello da cui è stata creata la regola viene ora visualizzato con il tag In use.

I modelli di regola di analisi vengono costantemente gestiti dagli autori, per correggere i bug o per perfezionare la query. Quando un modello riceve un aggiornamento, tutte le regole basate su tale modello vengono visualizzate con il tag Update e si ha la possibilità di modificare tali regole per includere le modifiche apportate al modello. È anche possibile ripristinare le modifiche apportate in una regola alla versione originale basata su modello. Per altre informazioni, vedere Gestire le versioni dei modelli per le regole di analisi pianificate in Microsoft Sentinel.

Dopo aver familiarità con le opzioni di configurazione in questo articolo, vedere Creare regole di analisi pianificate dai modelli.

Il resto di questo articolo illustra tutte le possibilità per personalizzare la configurazione delle regole.

Configurazione delle regole di analisi

Questa sezione illustra le considerazioni chiave da tenere in considerazione prima di iniziare a configurare le regole.

Nome e dettagli della regola di analisi

La prima pagina della procedura guidata delle regole di analisi contiene le informazioni di base della regola.

Nome: il nome della regola come viene visualizzato nell'elenco delle regole e in qualsiasi filtro basato su regole. Il nome deve essere univoco nell’area di lavoro.

Descrizione: una descrizione in formato testo libero dello scopo della regola.

ID: GUID della regola come risorsa di Azure, usata in richieste e risposte API, tra l'altro. Questo GUID viene assegnato solo quando viene creata la regola, quindi viene visualizzato solo quando si modifica una regola esistente. Poiché si tratta di un campo di sola lettura, viene visualizzato come disattivato e non può essere modificato. Non esiste ancora quando si crea una nuova regola, da un modello o da zero.

Gravità: una valutazione per assegnare gli avvisi generati da questa regola. La gravità di un'attività è un calcolo del potenziale impatto negativo dell'occorrenza dell'attività.

Le impostazioni predefinite del livello di gravità non sono una garanzia del livello di impatto corrente o ambientale. Personalizzare i dettagli dell'avviso per personalizzare la gravità, le tattiche e altre proprietà di una determinata istanza di un avviso con i valori di tutti i campi pertinenti di un output della query.

Le definizioni di gravità per i modelli di regole di analisi di Microsoft Sentinel sono rilevanti solo per gli avvisi creati dalle regole di analisi. Per gli avvisi inseriti da altri servizi, la gravità viene definita dal servizio di sicurezza di origine.

MITRE ATT&CK: una specifica delle tattiche e delle tecniche di attacco rappresentate dalle attività acquisite da questa regola. Si basano sulle tattiche e sulle tecniche del framework MITRE ATT&CK®.

Le tattiche e le tecniche MITRE ATT&CK definite qui nella regola si applicano a tutti gli avvisi generati dalla regola. Si applicano anche a tutti gli eventi imprevisti creati da questi avvisi.

Per altre informazioni sull'ottimizzazione della copertura del panorama delle minacce MITRE ATT&CK, vedere Informazioni sulla copertura della sicurezza da parte del framework MITRE ATT&CK®.

Stato: quando si crea la regola, il relativo Stato è Abilitato per impostazione predefinita, il che significa che viene eseguito immediatamente dopo averlo creato. Se non si vuole eseguirlo immediatamente, sono disponibili due opzioni:

• Selezionare Disabilitato e la regola viene creata senza eseguire. Quando si vuole che la regola venga eseguita, trovarla nella scheda Regole attive e abilitarla da questa posizione.
• Pianificare la prima esecuzione della regola in una data e un'ora specifiche. Questo metodo è attualmente in ANTEPRIMA. Vedere Pianificazione delle query più avanti in questo articolo.

Query delle regole

Questa è l'essenza della regola: si decide quali informazioni si trovano negli avvisi creati da questa regola e come vengono organizzate le informazioni. Questa configurazione ha effetti di follow-on sull'aspetto degli eventi imprevisti risultanti e su quanto siano facili o difficili da analizzare, correggere e risolvere. È importante rendere gli avvisi il più ricco possibile di informazioni e rendere tali informazioni facilmente accessibili.

Visualizzare o immettere la query Kusto che analizza i dati di log non elaborati. Se si crea una regola da zero, è consigliabile pianificare e progettare la query prima di aprire questa procedura guidata. È possibile compilare e testare query nella pagina Log.

Tutto ciò che si digita nella finestra di query delle regole viene convalidato immediatamente, quindi è possibile individuare immediatamente se si verificano errori.

Procedure consigliate per le query sulle regole di analisi

• È consigliabile usare un parser ASIM (Advanced Security Information Model) come origine query, anziché usare una tabella nativa. In questo modo, la query supporta qualsiasi origine dati corrente o futura pertinente o famiglia di origini dati, anziché basarsi su una singola origine dati.

• La lunghezza della query deve essere compresa tra 1 e 10.000 caratteri e non può contenere "search *" o "union *". È possibile usare funzioni definite dall'utente per superare la limitazione della lunghezza della query, in quanto una singola funzione può sostituire decine di righe di codice.

• L'uso delle funzioni ADX per creare query di Esplora dati di Azure all'interno della finestra di query di Log Analytics non è supportato.

• Quando si utilizza la funzione bag_unpack in una query, se si proiettano le colonne come campi utilizzando "project field1" e la colonna non esiste, la query fallisce. Per evitare questo problema, è necessario proiettare la colonna come indicato di seguito:

  project field1 = column_ifexists("field1","")

Per altre informazioni, vedere:

• Linguaggio di query Kusto in Microsoft Sentinel
• Guida di riferimento rapido di KQL
• Procedure consigliate per Linguaggio di query Kusto

Miglioramento degli avvisi

Per visualizzare i risultati degli avvisi in modo che possano essere immediatamente visibili negli eventi imprevisti e monitorati e esaminati in modo appropriato, usare la configurazione di miglioramento dell'avviso per visualizzare tutte le informazioni importanti negli avvisi.

Questo miglioramento dell'avviso ha il vantaggio aggiunto di presentare i risultati in modo facilmente visibile e accessibile.

Sono disponibili tre tipi di miglioramenti per gli avvisi che è possibile configurare:

• Mapping di entità
• Dettagli personalizzati
• Dettagli avviso (noto anche come contenuto dinamico)

Mapping di entità

Le entità sono gli attori su entrambi i lati di qualsiasi storia di attacco. L'identificazione di tutte le entità in un avviso è essenziale per rilevare e analizzare le minacce. Per assicurarsi che Microsoft Sentinel identifichi le entità nei dati non elaborati, è necessario eseguire il mapping dei tipi di entità riconosciuti da Microsoft Sentinel nei campi nei risultati della query. Questo mapping integra le entità identificate nel campo Entità nello schema di avviso.

Per altre informazioni sul mapping delle entità e per ottenere istruzioni complete, vedere Eseguire il mapping dei campi dati alle entità in Microsoft Sentinel.

Dettagli personalizzati

Per impostazione predefinita, solo le entità di avviso e i metadati sono visibili negli eventi imprevisti senza eseguire il drill-down negli eventi non elaborati nei risultati della query. Per assegnare agli altri campi la visibilità immediata dei risultati della query negli avvisi e negli eventi imprevisti, definirli come dettagli personalizzati. Microsoft Sentinel integra questi dettagli personalizzati nel campo ExtendedProperties negli avvisi, causando la visualizzazione prima degli avvisi e in tutti gli eventi imprevisti creati da tali avvisi.

Per altre informazioni sulla visualizzazione dei dettagli personalizzati e per ottenere istruzioni complete, vedere Dettagli degli eventi personalizzati di Surface negli avvisi in Microsoft Sentinel.

Dettagli degli avvisi

Questa impostazione consente di personalizzare le proprietà degli avvisi standard in base al contenuto di vari campi in ogni singolo avviso. Queste personalizzazioni sono integrate nel campo ExtendedProperties negli avvisi. Ad esempio, è possibile personalizzare il nome o la descrizione dell'avviso per includere un nome utente o un indirizzo IP in primo piano nell'avviso.

Per altre informazioni sulla personalizzazione dei dettagli degli avvisi e per ottenere istruzioni complete, vedere Personalizzare i dettagli degli avvisi in Microsoft Sentinel.

Pianificazione delle query

I parametri seguenti determinano la frequenza con cui viene eseguita la regola pianificata e il periodo di tempo esaminato ogni volta che viene eseguito.

• L'intervallo consentito per entrambi questi parametri è compreso tra 5 minuti e 14 giorni.

• L'intervallo di query deve essere più breve o uguale al periodo di ricerca. Se è più breve, i periodi di query si sovrappongono, causando una duplicazione dei risultati. La convalida della regola non consente di impostare un intervallo più lungo del periodo di lookback, tuttavia, in quanto ciò provocherebbe lacune nella copertura.

L'impostazione Avvia l'esecuzione, ora in ANTEPRIMA, consente di creare una regola con stato Abilitato, ma di ritardare la prima esecuzione fino a una data e un'ora predeterminate. Questa impostazione è utile se si vuole temporizzare l'esecuzione delle regole in base a quando si prevede che i dati vengano inseriti dall'origine o quando gli analisti SOC iniziano la giornata lavorativa.

• L’orario di avvio dell'esecuzione deve essere compreso tra 10 minuti e 30 giorni dopo l'ora di creazione o abilitazione della regola.

• La riga di testo sotto l'impostazione Avvia esecuzione (con l'icona delle informazioni a sinistra) riepiloga le impostazioni correnti di pianificazione delle query e lookback.

  

Soglia di avviso

Molti tipi di eventi di sicurezza sono normali o addirittura previsti in piccoli numeri, ma sono un segno di una minaccia in numeri maggiori. Diverse scale di numeri elevati possono significare diversi tipi di minacce. Ad esempio, due o tre tentativi di accesso non riusciti nello spazio di un minuto è un segno di un utente che non ricorda una password, ma 50 in un minuto potrebbe essere un segno di un attacco umano e mille è probabilmente un attacco automatico.

A seconda del tipo di attività che la regola sta tentando di rilevare, è possibile impostare un numero minimo di eventi (risultati della query) necessari per attivare un avviso. La soglia viene applicata separatamente a ogni esecuzione della regola, non collettivamente.

La soglia può anche essere impostata su un numero massimo di risultati o su un numero esatto.

Raggruppamento di eventi

Esistono due modi per gestire il raggruppamento di eventi in avvisi:

• Raggruppa tutti gli eventi in un singolo avviso: Questa è l'impostazione predefinita. La regola genera un singolo avviso ogni volta che viene eseguito, purché la query restituisca più risultati rispetto alla soglia di avviso specificata illustrata nella sezione precedente. Questo singolo avviso riepiloga tutti gli eventi restituiti nei risultati della query.

• Attivare un avviso per ogni evento: la regola genera un avviso univoco per ogni evento (risultato) restituito dalla query. Questa modalità è utile se si vuole che gli eventi vengano visualizzati singolarmente o se si vuole raggrupparli in base a determinati parametri, ad esempio utente, nome host o altro. È possibile definire questi parametri nella query.

Le regole di analisi possono generare fino a 150 avvisi. Se Raggruppamento di eventi è impostato su Attivare un avviso per ogni evento e la query della regola restituisce più di 150 eventi, i primi 149 eventi genereranno un avviso univoco (per 149 avvisi) e il 150° avviso riepilogherà l'intero set di eventi restituiti. In altre parole, il 150° avviso è quello che sarebbe stato generato se Raggruppamento di eventi fosse stato impostato su Raggruppa tutti gli eventi in un singolo avviso.

La sezione Query dell'avviso è diversa in ognuna di queste due modalità. In Raggruppa tutti gli eventi in una singola modalità di avviso , l'avviso restituisce una query che consente di visualizzare tutti gli eventi che hanno attivato l'avviso. È possibile eseguire il drill-down nei risultati della query per visualizzare i singoli eventi. Nella modalità Attivare un avviso per ogni evento, l'avviso restituisce un risultato codificato in Base64 nell'area della query. Copiare ed eseguire questo output in Log Analytics per decodificare base64 e visualizzare l'evento originale.

L'impostazione Attiva un avviso per ogni evento potrebbe causare un problema per cui i risultati della query sembrano mancanti o diversi dal previsto. Per altre informazioni su questo scenario, vedere Regole di analisi della risoluzione dei problemi in Microsoft Sentinel | Problema: non vengono visualizzati eventi nei risultati della query.

Eliminazione

Se si vuole che questa regola smetta di funzionare per un periodo di tempo dopo la generazione di un avviso, attivare Arresta l'esecuzione della query dopo la generazione dell'avviso impostando Attiva. È quindi necessario impostare Interrompere l'esecuzione della query per sulla quantità di tempo in cui la query deve interrompere l'esecuzione, fino a 24 ore.

Simulazione dei risultati

La procedura guidata per la regola di analisi consente di testarne l'efficacia eseguendola nel set di dati corrente. Quando si esegue il test, la finestra Simulazione risultati mostra un grafico dei risultati che la query avrebbe generato negli ultimi 50 volte che sarebbe stata eseguita, in base alla pianificazione attualmente definita. Se si modifica la query, è possibile eseguire di nuovo il test per aggiornare il grafico. Il grafico mostra il numero di risultati nel periodo di tempo definito, determinato dalla pianificazione della query definita.

Ecco l'aspetto della simulazione dei risultati per la query nello screenshot precedente. Il lato sinistro è la visualizzazione predefinita e il lato destro è quello che viene visualizzato quando si passa il puntatore del mouse su un punto nel tempo sul grafico.

Se si nota che la query attiverebbe troppi avvisi o troppo frequenti, è possibile sperimentare le impostazioni di pianificazione e soglia ed eseguire di nuovo la simulazione.

Impostazioni degli incidenti

Scegliere se Microsoft Sentinel trasforma gli avvisi in incidenti interattivi.

La creazione di eventi imprevisti è abilitata per impostazione predefinita. Microsoft Sentinel crea un singolo evento imprevisto separato da ogni avviso generato dalla regola.

Se non si vuole che questa regola comporti la creazione di incidenti, ad esempio se questa regola serve solo per raccogliere informazioni per l'analisi successiva, impostare questa opzione su Disabilitato.

Se si vuole creare un singolo incidente da un gruppo di avvisi, anziché uno per ogni singolo avviso, vedere la sezione successiva.

Raggruppamento di avvisi

Scegliere se raggruppare gli avvisi in incidenti. Per impostazione predefinita, Microsoft Sentinel crea un evento imprevisto per ogni avviso generato. È possibile raggruppare diversi avvisi in un singolo evento imprevisto.

L'evento imprevisto viene creato solo dopo la generazione di tutti gli avvisi. Tutti gli avvisi vengono aggiunti all'incidente subito dopo la creazione.

È possibile raggruppare fino a 150 avvisi in un singolo incidente. Se più di 150 avvisi vengono generati da una regola che li raggruppa in un singolo, viene generato un nuovo incidente con gli stessi dettagli dell'incidente originario e gli avvisi in eccesso vengono raggruppati nel nuovo incidente.

Per raggruppare gli avvisi, impostare l'impostazione di raggruppamento degli avvisi su Abilitato.

Esistono alcune opzioni da considerare quando si raggruppano gli avvisi:

• Intervallo di tempo: per impostazione predefinita, gli avvisi creati fino a 5 ore dopo il primo avviso in un evento imprevisto vengono aggiunti allo stesso evento imprevisto. Dopo 5 ore viene creato un nuovo incidente. È possibile modificare questo periodo di tempo in qualsiasi punto tra 5 minuti e sette giorni.

• Criteri di raggruppamento: scegliere come determinare quali avvisi sono inclusi nel gruppo. La tabella seguente illustra le possibili scelte:

  Opzione	Descrizione
  Raggruppa gli avvisi in un singolo incidente se tutte le entità corrispondono	Gli avvisi vengono raggruppati se condividono valori identici per ognuna delle entità mappate definite in precedenza. Questa è l'impostazione consigliata.
  Raggruppa tutti gli avvisi generati da questa regola in un singolo incidente	Tutti gli avvisi generati da questa regola vengono raggruppati insieme anche se non condividono valori identici.
  Raggruppamento degli avvisi in un singolo incidente in caso di corrispondenza dei tipi di entità e dei dettagli selezionati	Gli avvisi vengono raggruppati se condividono valori identici per tutte le entità mappate, dettagli dell'avviso e dettagli personalizzati selezionati per questa impostazione. Scegliere le entità e i dettagli dagli elenchi a discesa visualizzati quando si seleziona questa opzione. È possibile usare questa impostazione se, ad esempio, si desidera creare incidenti separati in base agli indirizzi IP di origine o di destinazione oppure se si desidera raggruppare avvisi che corrispondono a un'entità e una gravità specifiche. Nota: quando si seleziona questa opzione, è necessario avere almeno un'entità o un dettaglio selezionato per la regola. In caso contrario, la convalida della regola non riesce e la regola non viene creata.

• Riaprire gli eventi imprevisti: se un evento imprevisto è stato risolto e chiuso e successivamente viene generato un altro avviso che deve appartenere a tale evento imprevisto, impostare questa impostazione su Abilitato se si vuole riaprire l'evento imprevisto chiuso e lasciare Disabilitato se si vuole che il nuovo avviso crei un nuovo evento imprevisto.

  L'opzione per riaprire gli incidenti chiusi non è disponibile se è stato eseguito l'onboarding di Microsoft Sentinel nel portale di Defender.

Risposta automatica

Microsoft Sentinel consente di impostare risposte automatizzate in modo che si verifichino quando:

• Un avviso viene generato da questa regola di analisi.
• Un evento imprevisto viene creato dagli avvisi generati da questa regola di analisi.
• Un evento imprevisto viene aggiornato con gli avvisi generati da questa regola di analisi.

Per informazioni sui diversi tipi di risposte che possono essere create e automatizzate, vedere Automatizzare la risposta alle minacce in Microsoft Sentinel con regole di automazione.

Nell'intestazione Regole di automazione, la procedura guidata visualizza un elenco delle regole di automazione già definite nell'intera area di lavoro, le cui condizioni si applicano a questa regola di analisi. È possibile modificare una di queste regole esistenti oppure creare una nuova regola di automazione applicabile solo a questa regola di analisi.

Usare le regole di automazione per eseguire valutazione di base, assegnazione, flusso di lavoro e chiusura degli incidenti.

Automatizzare attività più complesse e richiamare risposte da sistemi remoti per correggere le minacce chiamando playbook da queste regole di automazione. È possibile richiamare playbook per incidenti e per singoli avvisi.

• Per altre informazioni e istruzioni sulla creazione di playbook e regole di automazione, vedere Automatizzare le risposte alle minacce.

• Per altre informazioni su quando usare il trigger creato evento imprevisto, il trigger aggiornato evento imprevisto o il trigger creato avviso, vedere Usare trigger e azioni nei playbook di Microsoft Sentinel.

• Nell'intestazione Automazione avvisi (versione classica) potrebbe essere visualizzato un elenco di playbook configurati per l'esecuzione automatica usando un metodo precedente a causa della deprecata nel mese di marzo 2026. Non è possibile aggiungere nulla a questo elenco. Tutti i playbook elencati qui devono avere regole di automazione create, in base al trigger di avviso creato, per richiamare i playbook. Dopo aver completato questa operazione, selezionare i puntini di sospensione alla fine della riga del playbook elencato qui e selezionare Rimuovi. Per le istruzioni complete, vedere Eseguire la migrazione dei playbook di attivazione degli avvisi di Microsoft Sentinel alle regole di automazione.

Passaggi successivi

Quando si usano le regole di analisi di Microsoft Sentinel per rilevare minacce nell'ambiente, assicurarsi di abilitare tutte le regole associate alle origini dati connesse per garantire la copertura completa della sicurezza per l'ambiente.

Per automatizzare l'abilitazione delle regole, eseguire il push delle regole in Microsoft Sentinel tramite l'API e PowerShell, anche se questa operazione richiede più impegno. Quando si usa l'API o PowerShell, è necessario prima esportare le regole in JSON prima di abilitare le regole. L'API o PowerShell può essere utile quando si abilitano regole in più istanze di Microsoft Sentinel con impostazioni identiche in ogni istanza.

Per altre informazioni, vedere:

• Esportare e importare regole di analisi da/verso modelli Azure Resource Manager
• Risoluzione dei problemi relativi alle regole di analisi in Microsoft Sentinel
• Esplorare e analizzare gli incidenti in Microsoft Sentinel
• Entità in Microsoft Sentinel
• Esercitazione: Usare playbook con regole di automazione in Microsoft Sentinel

Inoltre, sono fornite informazioni su un esempio dell'uso di regole di analisi personalizzate durante il monitoraggio di Zoom con un connettore personalizzato.