Condividi tramite

Normalizzazione del tempo di inserimento

  • Articolo

Analisi in fase di query

Come illustrato nella Panoramica di ASIM, Microsoft Sentinel usa sia la normalizzazione in fase di query che la normalizzazione in fase di inserimento per sfruttare i vantaggi di ognuna.

Per usare la normalizzazione in fase di query, usare i parser unificanti in fase di query, ad esempio _Im_Dns, nelle query. La normalizzazione con l'analisi in fase di query presenta diversi vantaggi:

  • Conservazione del formato originale: la normalizzazione in fase di query non richiede che i dati vengano modificati, per cui viene mantenuto il formato di dati originale inviato dall'origine.
  • Esclusione del rischio di archiviazione duplicata: poiché i dati normalizzati sono solo una visualizzazione dei dati originali, non è necessario archiviare sia i dati originali che quelli normalizzati.
  • Sviluppo più semplice: poiché i parser in fase di query presentano una visualizzazione dei dati e non li modificano, sono facili da sviluppare. Lo sviluppo, il test e la correzione di un parser possono essere eseguiti su dati esistenti. Inoltre, i parser possono essere corretti quando viene individuato un problema e la correzione verrà applicata ai dati esistenti.

Analisi in fase di inserimento

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

L'analisi in fase di inserimento consente di trasformare gli eventi in uno schema normalizzato durante l'inserimento in Microsoft Sentinel e di archiviarli in un formato normalizzato. L'analisi in fase 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 simile ma non identico a uno schema ASIM offre anche i vantaggi delle prestazioni della normalizzazione in fase di inserimento.

Attualmente, ASIM supporta le tabelle normalizzate native seguenti come destinazione per la normalizzazione in fase 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 illustrato in Gestire i parser.

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

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

Il parser stub è un parser in fase 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 con valori ripetuti, gli alias non vengono archiviati nelle tabelle native ASIM e vengono aggiunti in fase di query dai parser stub.
  • Valori costanti: come gli alias e, per lo stesso motivo, 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 in fase di inserimento possono modificare la versione di output. Di conseguenza, 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 ASIM non richiedono filtri di parser per ottenere prestazioni migliori, è necessario applicare filtri per supportare l'inclusione nel parser unificante.
  • 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 aggiungerlo 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 controparte filtro come punto di partenza. Se la tabella è semi-normalizzata, usare il parser stub per eseguire l'analisi e la normalizzazione aggiuntive necessarie.

Per altre informazioni sulla scrittura di parser, vedere Sviluppo di parser ASIM.

Implementazione della normalizzazione in fase di inserimento

Per normalizzare i dati in fase di inserimento, è necessario usare una regola di raccolta dati (DCR). La procedura per l'implementazione della 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 una DCR. La versione KQL usata nelle DCR è lievemente diversa dalla versione usata altrove in Microsoft Sentinel per soddisfare i requisiti di elaborazione degli eventi della pipeline. Pertanto, sarà necessario modificare qualsiasi parser in fase di query per usarlo in una DCR. Per altre informazioni sulle differenze e su come convertire un parser in fase di query in un parser in fase di inserimento, leggere Limitazioni KQL DCR.

Passaggi successivi

Per altre informazioni, vedi: