Gestire il ritardo di inserimento nelle regole di analisi pianificate

Importante

I rilevamenti personalizzati sono ora il modo migliore per creare nuove regole in Microsoft Sentinel Microsoft Defender XDR SIEM. Con i rilevamenti personalizzati, è possibile ridurre i costi di inserimento, ottenere rilevamenti in tempo reale illimitati e trarre vantaggio dall'integrazione senza problemi con dati, funzioni e azioni di correzione Defender XDR con il mapping automatico delle entità. Per altre informazioni, leggere questo blog.

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 .

Si supponga ora che si sia verificato 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 nel primo periodo di ricerca, ma non viene inserito nell'area di lavoro Microsoft Sentinel alla 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

Nota

È possibile risolvere il problema usando il processo descritto di seguito oppure 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 quasi in tempo reale (NRT) in Microsoft Sentinel.

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, vedere Calcolare il ritardo di inserimento.

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

• Aumentare il periodo di ricerca. L'intuizione di base ti dice che l'aumento delle dimensioni del periodo look-back 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:

  

• Gestire la duplicazione. Solo aumentando il periodo di ricerca è possibile creare una duplicazione, perché le finestre look-back ora si sovrappongono. 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 un periodo di ricerca specifico. Nel primo esempio gli eventi non sono stati inseriti perché i dati non sono stati inseriti durante l'esecuzione della query pianificata. È stato esteso il look-back per includere l'evento, ma ciò ha causato la duplicazione. È necessario associare l'evento alla finestra estesa per contenerlo.

  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 limitazione del tempo di inserimento ora taglia i due minuti aggiuntivi aggiunti al periodo di ricerca. Per il primo esempio, il secondo periodo di esecuzione look-back acquisisce ora l'evento:

  

La query di esempio seguente riepiloga la soluzione per risolvere i problemi di ritardo dell'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)

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

• istruzione let
• operatore where
• funzione ago()

Calcolare il ritardo di inserimento

Per impostazione predefinita, Microsoft Sentinel regole di avviso pianificate sono configurate per avere un periodo 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
• Usare la cartella di lavoro di monitoraggio dell'integrità
• Registrare il tempo di inserimento dei dati in Monitoraggio Azure