Gestire il ritardo di inserimento nelle regole di analisi pianificate

Anche se Microsoft Sentinel può inserire dati da diverse origini, il tempo di inserimento per ogni origine dati può variare in circostanze diverse.

Questo articolo descrive come il ritardo di inserimento potrebbe influire sulle regole di analisi pianificate e su come risolverli per coprire queste lacune.

Perché il ritardo è significativo

Ad esempio, è possibile scrivere una regola di rilevamento personalizzata, impostando la query Esegui ogni e i dati di ricerca degli ultimi campi per avere la regola eseguita ogni cinque minuti, cercando i dati degli ultimi cinque minuti:

I dati di ricerca dell'ultimo campo definiscono un'impostazione nota come periodo di ricerca . Idealmente, quando non è presente alcun ritardo, questo rilevamento non verifica alcun evento, come illustrato nel diagramma seguente:

L'evento arriva man mano che viene generato e viene incluso nel periodo di lookback .

Si supponga ora che vi sia un ritardo per l'origine dati. Per questo esempio, si supponga che l'evento sia stato inserito due minuti dopo la generazione. Il ritardo è di due minuti:

L'evento viene generato all'interno del primo periodo di ricerca, ma non viene inserito nell'area di lavoro di Microsoft Sentinel nella prima esecuzione. La successiva esecuzione della query pianificata inserisce l'evento, ma il filtro generato dall'ora rimuove l'evento perché è accaduto più di cinque minuti fa. In questo caso, la regola non genera un avviso.

Come gestire il ritardo

Per risolvere il problema, è necessario conoscere il ritardo per il tipo di dati. Per questo esempio, si conosce già il ritardo è di due minuti.

Per i dati personalizzati, è possibile comprendere il ritardo usando la funzione Kusto ingestion_time() e calcolare la differenza tra TimeGenerated e il tempo di inserimento. Per altre informazioni, vedere Calcolare il ritardo di inserimento.

Dopo aver determinato il ritardo, è possibile risolvere il problema come segue:

• Aumentare il periodo di ricerca. L'intuizione di base indica che l'aumento delle dimensioni del periodo di ricerca sarà utile. Poiché il periodo di ricerca è di cinque minuti e il ritardo è di due minuti, l'impostazione del periodo di ricerca su sette minuti aiuterà a risolvere questo problema. Ad esempio, nelle impostazioni della regola:

  

  Il diagramma seguente illustra come il periodo look-pack contiene ora l'evento perso:

  

• Gestire la duplicazione. Solo aumentando il periodo di ricerca può creare la duplicazione, perché le finestre di ricerca ora si sovrappongono. Ad esempio, un evento diverso può essere visualizzato come illustrato nel diagramma seguente:

  

  Poiché il valore TimeGenerated dell'evento viene trovato in entrambi i periodi di ricerca, l'evento genera due avvisi. È necessario trovare un modo per risolvere la duplicazione.

• Associare l'evento a un periodo di ricerca specifico. Nel primo esempio, gli eventi non sono stati inseriti perché i dati non sono stati inseriti quando è stata eseguita la query pianificata. È stato esteso il look-back per includere l'evento, ma questa causava la duplicazione. È necessario associare l'evento alla finestra estesa per contienerla.

  Eseguire questa operazione impostando ingestion_time() > ago(5m), anziché la regola look-back = 5moriginale . Questa impostazione associa l'evento alla prima finestra di ricerca. Ad esempio:

  

  La restrizione del tempo di inserimento riduce ora i due minuti aggiuntivi aggiunti al periodo di ricerca. Per il primo esempio, il secondo periodo di ricerca ora acquisisce l'evento:

  

La query di esempio seguente riepiloga la soluzione per risolvere i problemi di ritardo di inserimento:

let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)

Calcolare il ritardo di inserimento

Per impostazione predefinita, le regole di avviso pianificate di Microsoft Sentinel sono configurate per avere un periodo di ricerca di 5 minuti. Tuttavia, ogni origine dati può avere il proprio ritardo di inserimento individuale. Quando si unisce più tipi di dati, è necessario comprendere i diversi ritardi per ogni tipo di dati per configurare correttamente il periodo di ricerca.

Il report sull'utilizzo dell'area di lavoro, fornito in Microsoft Sentinel out-of-the-box, include un dashboard che mostra latenza e ritardi per i diversi tipi di dati che passano all'area di lavoro.

Ad esempio:

Passaggi successivi

Per altre informazioni, vedere:

• Creare regole di analisi personalizzate per rilevare le minacce
• Personalizzare i dettagli dell'avviso in Azure Sentinel
• Gestire le versioni del modello per le regole di analisi pianificate in Azure Sentinel
• Usare la cartella di lavoro di monitoraggio dell'integrità
• Time di inserimento dati in Monitoraggio di Azure