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 ritardare l'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 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 è presente alcun ritardo, questo rilevamento non rileva eventi, come illustrato nel diagramma seguente:

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

Si supponga ora che ci 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 entro il primo periodo di ricerca, 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 fa. In questo caso, la regola non genera un avviso.

Come gestire il ritardo

Nota

È possibile risolvere il problema usando il processo descritto di seguito o implementare le regole di rilevamento quasi in tempo reale (NRT) di Microsoft Sentinel. Per altre informazioni, vedere Rilevare rapidamente le minacce con regole di analisi near real-time (NRT) in Microsoft Sentinel.

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

Per i propri dati, è 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 nel modo seguente:

• 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 consentirà di risolvere questo problema. Ad esempio, nelle impostazioni della regola:

  

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

  

• Gestire la duplicazione. L'aumento del periodo di ricerca può creare duplicazione solo perché le finestre look-back ora si sovrappongono. Ad esempio, un evento diverso può essere simile a quello illustrato nel diagramma seguente:

  

  Poiché il valore TimeGenerated dell'evento si trova 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 rilevati perché i dati non sono stati inseriti durante l'esecuzione della query pianificata. È stato esteso il lookback per includere l'evento, ma questa operazione ha causato la duplicazione. È necessario associare l'evento alla finestra estesa per contenerla.

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

  

  La restrizione relativa al tempo di inserimento riduce ora i due minuti aggiuntivi aggiunti al periodo di ricerca. Per il primo esempio, il secondo periodo di ricerca acquisisce ora 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 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, disponibile 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, vedere:

• Creare regole di analisi personalizzate per rilevare le minacce
• Personalizzare i dettagli degli avvisi in Azure Sentinel
• Gestire le versioni dei modelli 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