Gestire il ritardo di inserimento nelle regole di analisi pianificata

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 pianificata e come risolvere per coprire queste lacune.

Perché il ritardo è significativo

Ad esempio, è possibile scrivere una regola di rilevamento personalizzata, impostando i campi Esegui query ogni e Ricerca dati dagli ultimi in modo che la regola venga eseguita ogni cinque minuti, cercando i dati degli ultimi cinque minuti:

Il campo Ricerca dati dagli ultimi definisce un'impostazione nota come periodo di retroattività. Idealmente, quando non esiste alcun ritardo, questo rilevamento non rileva eventi, come illustrato nel diagramma seguente:

L'evento arriva quando viene generato ed è incluso nel periodo di look-back.

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

L'evento viene generato entro il primo periodo di retroattività, ma non viene inserito nell'area di lavoro di Microsoft Sentinel alla prima esecuzione. Alla successiva esecuzione della query pianificata, inserisce l'evento, ma il filtro generato dall'ora rimuove l'evento perché si è verificato più di cinque minuti prima. 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 sa già che il ritardo è di due minuti.

Per i propri dati, è possibile comprendere il ritardo usando la funzione ingestion_time() Kusto 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 nel modo seguente:

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

  

  Il diagramma seguente mostra come il periodo di retroattività ora contiene l'evento perso:

  

• Gestire la duplicazione. Aumentando semplicemente il periodo di retroattività si può creare una duplicazione, perché le finestre di retroattività ora si sovrappongono. Ad esempio, un evento diverso può essere simile a quello mostrato nel diagramma seguente:

  

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

• Associare l'evento a un periodo di retroattività specifico. Nel primo esempio si sono verificati eventi mancanti perché i dati non sono stati inseriti durante l'esecuzione della query pianificata. La retroattività è stata estesa per includere l'evento, ma ciò ha causato la duplicazione. È necessario associare l'evento alla finestra estesa per includerlo.

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

  

  La restrizione relativa al tempo di inserimento ora taglia i due minuti aggiuntivi aggiunti al periodo di retroattività. Per il primo esempio, il secondo periodo di retroattività dell'esecuzione ora cattura l'evento:

  

La query di esempio seguente riepiloga la soluzione per risolvere 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 un periodo di retroattività 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 retroattività.

Il report sull'utilizzo dell'area di lavoro, fornito già pronto in Microsoft Sentinel, 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, vedi:

• Creare regole di analisi personalizzate per rilevare le minacce
• Personalizzare i dettagli degli avvisi in Microsoft Sentinel
• Gestire le versioni dei modelli per le regole di analisi pianificata in Azure Sentinel
• Usare la cartella di lavoro di monitoraggio dell'integrità
• Time di inserimento dati in Monitoraggio di Azure