Gestire il ritardo di acquisizione nelle regole di analisi pianificate

Sebbene Microsoft Sentinel possa assorbire dati da fonti di dati connesse, il tempo di ingestione per ciascuna fonte di dati può variare in circostanze diverse.

Questo articolo descrive in che modo il ritardo di inserimento potrebbe influire sulle regole di analisi pianificate e come è possibile correggerle per coprire queste lacune.

Perché il ritardo è significativo

Ad esempio, è possibile scrivere una regola di rilevamento personalizzata, impostando l'opzione Esegui query ogni e Cerca i dati degli ultimi campi in modo che la regola venga 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 c'è alcun ritardo, questo rilevamento non perde eventi, come illustrato nel diagramma seguente:

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

Supponiamo ora che ci sia un certo ritardo nella sorgente 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 nel primo periodo di lookback, ma non viene acquisito nell'area di lavoro di Microsoft Sentinel durante la prima esecuzione. La volta successiva in cui viene eseguita la query pianificata, inserisce l'evento, ma il filtro generato dal tempo rimuove l'evento perché si è verificato più di cinque minuti fa. In questo caso, la regola non genera un avviso.

Come gestire il ritardo

Usare l'approccio seguente per tenere conto del ritardo di inserimento nelle regole di analisi pianificate.

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

Per i dati personali, è possibile comprendere il ritardo usando la funzione Kusto ingestion_time() e calcolando la differenza tra TimeGenerated e il tempo di inserimento. Per altre informazioni, vedi Calcolare il ritardo di acquisizione.

Dopo aver determinato il ritardo, è possibile risolvere il problema come indicato di seguito:

• Aumenta il periodo di retrospettiva: L'intuizione di base ti dice che aumentare la durata del periodo di retroscena aiuterà. Poiché il periodo di ricerca è di cinque minuti e il ritardo è di due minuti, l'impostazione del periodo di ricerca su sette minuti consentirà di risolvere questo problema. Ad esempio, nelle impostazioni delle regole:

  

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

  

• * Gestione della duplicazione: Solo l’aumento del periodo di look-back può causare duplicazioni, perché le finestre di look-back ora si sovrappongano. Ad esempio, un evento diverso può apparire come illustrato nel diagramma seguente:

  

  Poiché il valore TimeGenerated dell'evento si trova in entrambi i periodi di lookback, l'evento lancia due allarmi. È necessario trovare un modo per risolvere la duplicazione.

• Associa l'evento a un periodo di revisione specifico: nel primo esempio, hai perso eventi perché i tuoi dati non sono stati ingeriti quando la query programmata è stata eseguita. Hai esteso il periodo di retrospettiva per includere l'evento, ma questo ha causato duplicazioni. È necessario associare l'evento alla finestra che hai esteso per includerlo.

  A tale scopo, impostare ingestion_time() > ago(5m), anziché la regola look-back = 5moriginale. Questa impostazione associa l'evento alla prima finestra look-back. Ad esempio:

  

  La restrizione del tempo di acquisizione ora elimina i due minuti extra che hai aggiunto al periodo retrospettivo. E per il primo esempio, il periodo di look-back della seconda esecuzione ora rileva l'evento:

  

La query di esempio seguente riassume la soluzione per risolvere i problemi di ritardo di inserimento dei dati:

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)

Vedi ulteriori informazioni sui seguenti elementi utilizzati nell'esempio precedente nella documentazione Kusto:

• let istruzione
• operatore where
• funzione ago()

Calcolare il ritardo di acquisizione

Di default, le regole di avviso programmato di Microsoft Sentinel sono configurate per avere un periodo di retrospezione di cinque minuti. Tuttavia, ogni fonte di dati potrebbe avere un proprio ritardo di ingestione individuale. Quando si uniscono 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 predefinito, include un dashboard che mostra latenza e ritardi per i diversi tipi di dati che passano nell'area di lavoro.

Ad esempio:

Contenuti correlati

• Crea una regola di analisi programmata da zero
• Personalizzare i dettagli dell'avviso in Microsoft Sentinel
• Gestisci le versioni dei template per le tue regole di analisi programmate in Microsoft Sentinel
• Monitorare l'integrità dei connettori dati
• Registrare il tempo di inserimento dei dati in Monitoraggio Azure