Gestire il ritardo di acquisizione nelle regole di analisi pianificate

Anche se Microsoft Sentinel possono inserire dati da diverse origini, il tempo di inserimento per ogni origine 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:

• Aumentare il periodo di riferimento retrospettivo. L’intuizione suggerisce che aumentare l’ampiezza del periodo di osservazione 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 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 uno specifico periodo retrospettivo. Nel primo esempio, alcuni eventi sono andati persi perché i dati non erano ancora stati acquisiti quando è stata eseguita la query pianificata. 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)

Per altre informazioni sugli elementi seguenti usati nell'esempio precedente, vedere la documentazione di Kusto:

• let istruzione
• operatore where
• funzione ago()

Calcolare il ritardo di acquisizione

Per impostazione predefinita, le regole di avviso pianificate di Microsoft Sentinel sono configurate con un intervallo di ricerca retrospettiva di 5 minuti. Tuttavia, ogni origine dati può avere un proprio ritardo di inserimento 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:

Passaggi successivi

Per ulteriori informazioni, vedere:

• Creare regole di analisi personalizzate per rilevare le minacce
• Personalizzare i dettagli dell'avviso in Azure Sentinel
• Gestire le versioni dei modelli per le regole di analisi pianificate in Azure Sentinel
• Usa la cartella di lavoro per il monitoraggio dello stato di integrità
• Registrare il tempo di inserimento dei dati in Monitoraggio Azure