Normalizzazione del tempo di inserimento

  • Articolo

Analisi dell'ora di query

Come illustrato nella panoramica di ASIM, Microsoft Sentinel usa sia il tempo di query che la normalizzazione del tempo di inserimento per sfruttare i vantaggi di ognuno di essi.

Per usare la normalizzazione dell'ora di query, usare i parser in fase di query che unificano i parser, ad esempio _Im_Dns nelle query. La normalizzazione tramite l'analisi del tempo di query presenta diversi vantaggi:

  • Mantenimento del formato originale: la normalizzazione dell'ora di query non richiede la modifica dei dati, mantenendo così il formato di dati originale inviato dall'origine.
  • Evitare potenziali archivi duplicati: poiché i dati normalizzati sono solo una visualizzazione dei dati originali, non è necessario archiviare i dati originali e normalizzati.
  • Sviluppo più semplice: poiché i parser in fase di query presentano una visualizzazione dei dati e non modificano i dati, sono facili da sviluppare. Lo sviluppo, il test e la correzione di un parser possono essere eseguiti tutti sui dati esistenti. Inoltre, i parser possono essere risolti quando viene individuato un problema e la correzione verrà applicata ai dati esistenti.

Analisi del tempo di inserimento

Anche se i parser del tempo di query ASIM sono ottimizzati, l'analisi del tempo di query può rallentare le query, soprattutto nei set di dati di grandi dimensioni.

L'analisi del tempo di inserimento consente di trasformare gli eventi in uno schema normalizzato durante l'inserimento in Microsoft Sentinel e l'archiviazione in un formato normalizzato. L'analisi del tempo di inserimento è meno flessibile e i parser sono più difficili da sviluppare, ma poiché i dati vengono archiviati in un formato normalizzato, offre prestazioni migliori.

I dati normalizzati possono essere archiviati nelle tabelle normalizzate native di Microsoft Sentinel o in una tabella personalizzata che usa uno schema ASIM. Una tabella personalizzata con uno schema vicino, ma non identico a uno schema ASIM, offre anche i vantaggi delle prestazioni della normalizzazione del tempo di inserimento.

Attualmente, ASIM supporta le tabelle normalizzate native seguenti come destinazione per la normalizzazione del tempo di inserimento:

Il vantaggio delle tabelle normalizzate native è che sono incluse per impostazione predefinita nei parser unificanti ASIM. Le tabelle normalizzate personalizzate possono essere incluse nei parser unificanti, come descritto in Gestire i parser.

Combinazione della normalizzazione del tempo di inserimento e del tempo di query

Le query devono usare sempre i parser di tempo di query che unificano, ad esempio _Im_Dns per sfruttare sia il tempo di query che la normalizzazione del tempo di inserimento. Le tabelle normalizzate native sono incluse nei dati sottoposti a query usando un parser stub.

Il parser stub è un parser dell'ora di query che usa come input la tabella normalizzata. Poiché la tabella normalizzata non richiede l'analisi, il parser stub è efficiente.

Il parser stub presenta una visualizzazione alla query chiamante che aggiunge alla tabella nativa ASIM:

  • Alias : per non sprecare spazio di archiviazione sui valori ripetuti, gli alias non vengono archiviati nelle tabelle native di ASIM e vengono aggiunti in fase di query dai parser stub.
  • Valori costanti: come gli alias e, per lo stesso motivo, anche le tabelle normalizzate ASIM non archiviano valori costanti come EventSchema. Il parser stub aggiunge tali campi. La tabella normalizzata ASIM è condivisa da molte origini e i parser del tempo di inserimento possono modificare la versione di output. Di conseguenza, i campi come EventProduct, EventVendor e EventSchemaVersion non sono costanti e non vengono aggiunti dal parser stub.
  • Filtro: il parser stub implementa anche il filtro. Anche se le tabelle native di ASIM non necessitano di filtri per ottenere prestazioni migliori, è necessario applicare filtri per supportare l'inclusione nel parser unificatore.
  • Aggiornamenti e correzioni: l'uso di un parser stub consente di risolvere i problemi più velocemente. Ad esempio, se i dati sono stati inseriti in modo errato, è possibile che un indirizzo IP non sia stato estratto dal campo del messaggio durante l'inserimento. L'indirizzo IP può essere estratto dal parser stub in fase di query.

Quando si usano tabelle normalizzate personalizzate, creare un parser stub personalizzato per implementare questa funzionalità e aggiungerla ai parser unificanti, come descritto in Gestire i parser. Usare il parser stub per la tabella nativa, ad esempio il parser stub della tabella nativa DNS e la relativa controparte di filtro, come punto di partenza. Se la tabella è semi normalizzata, usare il parser stub per eseguire l'analisi e la normalizzazione aggiuntive necessarie.

Altre informazioni sulla scrittura di parser in Sviluppo di parser ASIM.

Implementazione della normalizzazione del tempo di inserimento

Per normalizzare i dati in fase di inserimento, è necessario usare una regola di raccolta dati .To normalize data at ingest, you will need to use a Data Collection Rule (DCR). La procedura per l'implementazione di DCR dipende dal metodo usato per inserire i dati. Per altre informazioni, vedere l'articolo Trasformare o personalizzare i dati in fase di inserimento in Microsoft Sentinel.

Una query di trasformazione KQL è il nucleo di un DCR. La versione KQL usata nelle DDR è leggermente diversa dalla versione usata altrove in Microsoft Sentinel per soddisfare i requisiti di elaborazione degli eventi della pipeline. Sarà quindi necessario modificare qualsiasi parser in fase di query per usarlo in un record di controllo dati. Per altre informazioni sulle differenze e su come convertire un parser in fase di query in un parser in fase di inserimento, vedere le limitazioni di DCR KQL.

Passaggi successivi

Per altre informazioni, vedere: