Sviluppare parser ASIM (Advanced Security Information Model)

Gli utenti di Advanced Security Information Model (ASIM) usano parser unificanti anziché nomi di tabella nelle query, per visualizzare i dati in un formato normalizzato e per includere tutti i dati rilevanti per lo schema nella query. I parser unificanti, a loro volta, usano parser specifici dell'origine per gestire i dettagli specifici di ogni origine.

Microsoft Sentinel fornisce parser predefiniti specifici dell'origine per molte origini dati. È possibile modificare o sviluppare questi parser specifici dell'origine nelle situazioni seguenti:

  • Quando il dispositivo fornisce eventi che si adattano a uno schema ASIM, ma un parser specifico dell'origine per il dispositivo e lo schema pertinente non è disponibile in Microsoft Sentinel.

  • Quando i parser specifici dell'origine ASIM sono disponibili per il dispositivo, ma il dispositivo invia eventi in un metodo o in un formato diverso da quello previsto dai parser ASIM. Ad esempio:

    • Il dispositivo di origine può essere configurato per inviare eventi in modo non standard.

    • Il dispositivo potrebbe avere una versione diversa da quella supportata dal parser ASIM.

    • Gli eventi possono essere raccolti, modificati e inoltrati da un sistema intermedio.

Per informazioni sull'adattamento dei parser all'interno dell'architettura ASIM, vedere il diagramma dell'architettura ASIM.

Processo di sviluppo del parser ASIM personalizzato

Il flusso di lavoro seguente descrive i passaggi generali per lo sviluppo di un parser personalizzato specifico dell'origine ASIM:

  1. Raccogliere i log di esempio.

  2. Identificare gli schemi o gli schemi rappresentati dagli eventi inviati dall'origine. Per altre informazioni, vedere Panoramica dello schema.

  3. Eseguire il mapping dei campi dell'evento di origine allo schema o agli schemi identificati.

  4. Sviluppare uno o più parser ASIM per l'origine. Sarà necessario sviluppare un parser di filtro e un parser senza parametri per ogni schema rilevante per l'origine.

  5. Testare il parser.

  6. Distribuire i parser nelle aree di lavoro Microsoft Sentinel.

  7. Aggiornare il parser di unificazione ASIM pertinente per fare riferimento al nuovo parser personalizzato. Per altre informazioni, vedere Gestione dei parser ASIM.

  8. È anche possibile contribuire con i parser alla distribuzione ASIM primaria. I parser forniti possono anche essere resi disponibili in tutte le aree di lavoro come parser predefiniti.

Questo articolo illustra i passaggi di sviluppo, test e distribuzione del processo.

Consiglio

Guardare anche il webinar deep dive su Microsoft Sentinel Normalizing Parsers and Normalized Content (Normalizzazione dei parser e del contenuto normalizzato) o esaminare la presentazione correlata. Per ulteriori informazioni, vedere Passaggi successivi.

Raccogliere log di esempio

Per creare parser ASIM efficaci, è necessario un set rappresentativo di log, che nella maggior parte dei casi richiederà la configurazione del sistema di origine e la connessione a Microsoft Sentinel. Se il dispositivo di origine non è disponibile, i servizi cloud con pagamento in base al consumo consentono di distribuire molti dispositivi per lo sviluppo e il test.

Inoltre, trovare la documentazione del fornitore e gli esempi per i log può aiutare ad accelerare lo sviluppo e ridurre gli errori garantendo un'ampia copertura del formato dei log.

Un set rappresentativo di log deve includere:

  • Eventi con risultati di eventi diversi.
  • Eventi con azioni di risposta diverse.
  • Formati diversi per nome utente, nome host e ID e altri campi che richiedono la normalizzazione dei valori.

Consiglio

Avviare un nuovo parser personalizzato usando un parser esistente per lo stesso schema. L'uso di un parser esistente è particolarmente importante per filtrare i parser per assicurarsi che accettino tutti i parametri richiesti dallo schema.

Pianificazione del mapping

Prima di sviluppare un parser, eseguire il mapping delle informazioni disponibili nell'evento o negli eventi di origine allo schema identificato:

  • Eseguire il mapping di tutti i campi obbligatori e preferibilmente anche dei campi consigliati.
  • Provare a eseguire il mapping di tutte le informazioni disponibili dall'origine ai campi normalizzati. Se non è disponibile come parte dello schema selezionato, è consigliabile eseguire il mapping ai campi disponibili in altri schemi.
  • Eseguire il mapping dei valori per i campi nell'origine ai valori normalizzati consentiti da ASIM. Il valore originale viene archiviato in un campo separato, ad EventOriginalResultDetailsesempio .

Sviluppo di parser

Sviluppare sia un filtro che un parser senza parametri per ogni schema pertinente.

Un parser personalizzato è una query KQL sviluppata nella pagina log Microsoft Sentinel. La query del parser è composta da tre parti:

Filtro>Parse>Preparare i campi

Filtro

Filtro dei record pertinenti

In molti casi, una tabella in Microsoft Sentinel include più tipi di eventi. Ad esempio:

  • La tabella Syslog contiene dati provenienti da più origini.
  • Le tabelle personalizzate possono includere informazioni provenienti da una singola origine che fornisce più di un tipo di evento e possono adattarsi a vari schemi.

Pertanto, un parser deve prima filtrare solo i record rilevanti per lo schema di destinazione.

Il filtro in KQL viene eseguito usando l'operatore where . Ad esempio, l'evento Sysmon 1 segnala la creazione del processo e viene quindi normalizzato nello schema ProcessEvent . L'evento Sysmon event 1 fa parte della Event tabella, pertanto è necessario usare il filtro seguente:

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Importante

Un parser non deve filtrare in base al tempo. La query che usa il parser applica un intervallo di tempo.

Filtro in base al tipo di origine tramite watchlist

In alcuni casi, l'evento stesso non contiene informazioni che consentano il filtro per tipi di origine specifici.

Ad esempio, gli eventi DNS di Infoblox vengono inviati come messaggi Syslog e sono difficili da distinguere dai messaggi Syslog inviati da altre origini. In questi casi, il parser si basa su un elenco di origini che definisce gli eventi pertinenti. Questo elenco viene mantenuto nell'elenco di controllo Sources_by_SourceType .

Per usare l'elenco di controllo ASimSourceType nei parser, usare la _ASIM_GetSourceBySourceType funzione nella sezione filtro del parser. Ad esempio, il parser DNS Infoblox include quanto segue nella sezione filtro:

  | where Computer in (_ASIM_GetSourceBySourceType('InfobloxNIOS'))

Per usare questo esempio nel parser:

  • Sostituire Computer con il nome del campo che include le informazioni di origine per l'origine. È possibile mantenere questa impostazione come Computer per qualsiasi parser basato su Syslog.

  • Sostituire il InfobloxNIOS token con un valore di propria scelta per il parser. Informare gli utenti del parser che devono aggiornare l'elenco ASimSourceType di controllo usando il valore selezionato, nonché l'elenco delle origini che inviano eventi di questo tipo.

Filtro in base ai parametri del parser

Quando si sviluppano parser di filtro, assicurarsi che il parser accetti i parametri di filtro per lo schema pertinente, come illustrato nell'articolo di riferimento per tale schema. L'uso di un parser esistente come punto di partenza garantisce che il parser includa la firma della funzione corretta. Nella maggior parte dei casi, il codice di filtro effettivo è simile anche per i parser di filtro per lo stesso schema.

Quando si filtra, assicurarsi di:

  • Filtrare prima di analizzare usando campi fisici. Se i risultati filtrati non sono sufficientemente accurati, ripetere il test dopo l'analisi per ottimizzare i risultati. Per altre informazioni, vedere Ottimizzazione dei filtri.
  • Non filtrare se il parametro non è definito e ha ancora il valore predefinito.

Gli esempi seguenti illustrano come implementare il filtro per un parametro stringa, in cui il valore predefinito è in genere '*' e per un parametro list, dove il valore predefinito è in genere un elenco vuoto.

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

Vedere altre informazioni sugli elementi seguenti nella documentazione di Kusto:

Ottimizzazione dei filtri

Per garantire le prestazioni del parser, prendere nota delle raccomandazioni di filtro seguenti:

  • Filtrare sempre in base ai campi predefiniti anziché analizzati. Anche se a volte è più semplice filtrare usando campi analizzati, influisce notevolmente sulle prestazioni.
  • Usare operatori che offrono prestazioni ottimizzate. In particolare, , ==hase startswith. L'uso di operatori come contains o matches regex influisce notevolmente sulle prestazioni.

Filtrare le raccomandazioni per le prestazioni potrebbe non essere sempre facile da seguire. Ad esempio, l'uso has di è meno accurato di contains. In altri casi, la corrispondenza con il campo predefinito, ad SyslogMessageesempio , è meno accurata rispetto al confronto di un campo estratto, ad DvcActionesempio . In questi casi, è consigliabile pre-filtrare usando un operatore di ottimizzazione delle prestazioni su un campo predefinito e ripetere il filtro usando condizioni più accurate dopo l'analisi.

Per un esempio, vedere il frammento di parser DNS Infoblox seguente. Il parser verifica innanzitutto che syslogMessage campi has la parola client. Tuttavia, il termine potrebbe essere usato in una posizione diversa nel messaggio, quindi dopo l'analisi del Log_Type campo, il parser verifica nuovamente che la parola client fosse effettivamente il valore del campo.

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

Nota

I parser non devono filtrare in base al tempo, perché la query che usa il parser filtra già per il tempo.

Analisi

Dopo che la query ha selezionato i record rilevanti, potrebbe essere necessario analizzarli. In genere, l'analisi è necessaria se più campi evento vengono trasmessi in un singolo campo di testo.

Gli operatori KQL che eseguono l'analisi sono elencati di seguito, ordinati in base all'ottimizzazione delle prestazioni. Il primo fornisce le prestazioni più ottimizzate, mentre l'ultimo fornisce le prestazioni meno ottimizzate.

Operator/function() Descrizione
funzione split() Analizzare una stringa di valori delimitati.
funzione parse_csv() Analizzare una stringa di valori formattati come riga CSV (valori delimitati da virgole).
Operatore parse-kv Estrae informazioni strutturate da un'espressione stringa e rappresenta le informazioni in un modulo chiave/valore.
Operatore parse Analizzare più valori da una stringa arbitraria usando un modello, che può essere un modello semplificato con prestazioni migliori o un'espressione regolare.
funzione extract_all() Analizzare singoli valori da una stringa arbitraria usando un'espressione regolare. extract_all ha prestazioni simili a parse se quest'ultimo usa un'espressione regolare.
funzione extract() Estrarre un singolo valore da una stringa arbitraria usando un'espressione regolare.

L'uso extract di offre prestazioni migliori rispetto parse a o extract_all se è necessario un singolo valore. Tuttavia, l'uso di più attivazioni di sulla stessa stringa di extract origine è meno efficiente di una singola parse o extract_all e deve essere evitato.
funzione parse_json() Analizzare i valori in una stringa formattata come JSON. Se sono necessari solo alcuni valori dal codice JSON, l'uso di parse, extracto extract_all offre prestazioni migliori.
funzione parse_xml() Analizzare i valori in una stringa formattata come XML. Se sono necessari solo alcuni valori dal codice XML, l'uso di parse, extracto extract_all offre prestazioni migliori.

Normalizzazione

Mapping dei nomi dei campi

La forma più semplice di normalizzazione consiste nel rinominare un campo originale in base al nome normalizzato. Usare l'operatore project-rename per questo. L'uso della ridenominazione del progetto garantisce che il campo sia ancora gestito come campo fisico e che la gestione del campo sia più efficiente. Ad esempio:

 | project-rename
    ActorUserId = InitiatingProcessAccountSid,
    ActorUserAadId = InitiatingProcessAccountObjectId,
    ActorUserUpn = InitiatingProcessAccountUpn,

Normalizzazione del formato e del tipo dei campi

In molti casi, il valore originale estratto deve essere normalizzato. Ad esempio, in ASIM un indirizzo MAC usa i due punti come separatore, mentre l'origine può inviare un indirizzo MAC delimitato da trattino. L'operatore primario per la trasformazione dei valori è extend, insieme a un ampio set di funzioni di stringa KQL, numeriche e date.

Inoltre, garantire che i campi di output del parser corrispondano al tipo definito nello schema è fondamentale per il funzionamento dei parser. Ad esempio, potrebbe essere necessario convertire una stringa che rappresenta la data e l'ora in un campo datetime. Funzioni come todatetime e tohex sono utili in questi casi.

Ad esempio, l'ID evento univoco originale può essere inviato come intero, ma ASIM richiede che il valore sia una stringa, per garantire un'ampia compatibilità tra le origini dati. Pertanto, quando si assegna il campo di project-renameorigine, utilizzare extend e tostring anziché :

  | extend EventOriginalUid = tostring(ReportId),

Campi e valori derivati

Potrebbe essere necessario eseguire il mapping del valore del campo di origine, una volta estratto, al set di valori specificato per il campo dello schema di destinazione. Le funzioni iff, casee lookup possono essere utili per eseguire il mapping dei dati disponibili ai valori di destinazione.

Ad esempio, il parser DNS Microsoft assegna il EventResult campo in base all'ID evento e al codice di risposta usando un'istruzione iff , come indicato di seguito:

   extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')

Per eseguire il mapping di diversi valori, definire il mapping usando l'operatore datatable e usare lookup per eseguire il mapping. Ad esempio, alcune origini segnalano codici di risposta DNS numerici e il protocollo di rete, mentre lo schema impone la rappresentazione di etichette di testo più comuni per entrambi. Nell'esempio seguente viene illustrato come derivare i valori necessari usando datatable e lookup:

   let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

Si noti che la ricerca è utile ed efficiente anche quando il mapping ha solo due valori possibili.

Quando le condizioni di mapping sono più complesse combinare iff, casee lookup. Nell'esempio seguente viene illustrato come combinare lookup e case. L'esempio lookup precedente restituisce un valore vuoto nel campo DnsResponseCodeName se il valore di ricerca non viene trovato. L'esempio case seguente lo aumenta usando il risultato dell'operazione lookup , se disponibile, e specificando condizioni aggiuntive in caso contrario.

   | extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

Microsoft Sentinel offre funzioni utili per i valori di ricerca comuni. Ad esempio, la DnsResponseCodeName ricerca precedente può essere implementata usando una delle funzioni seguenti:


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

La prima opzione accetta come parametro il valore da cercare e consente di scegliere il campo di output e quindi utile come funzione di ricerca generale. La seconda opzione è più orientata ai parser, accetta come input il nome del campo di origine e aggiorna il campo ASIM necessario, in questo caso DnsResponseCodeName.

Per un elenco completo delle funzioni della Guida di ASIM, vedere Funzioni ASIM

Campi di arricchimento

Oltre ai campi disponibili dall'origine, un evento ASIM risultante include campi di arricchimento che il parser deve generare. In molti casi, i parser possono assegnare un valore costante ai campi, ad esempio:

  | extend                  
     EventCount = int(1),
     EventProduct = 'M365 Defender for Endpoint',
     EventVendor = 'Microsoft',
     EventSchemaVersion = '0.1.0',
     EventSchema = 'ProcessEvent'

Un altro tipo di campi di arricchimento che i parser devono impostare sono i campi di tipo, che definiscono il tipo del valore archiviato in un campo correlato. Ad esempio, il SrcUsernameType campo definisce il tipo di valore archiviato nel SrcUsername campo. Altre informazioni sui campi tipo sono disponibili nella descrizione delle entità.

Nella maggior parte dei casi, ai tipi viene assegnato anche un valore costante. Tuttavia, in alcuni casi il tipo deve essere determinato in base al valore effettivo, ad esempio:

   DomainType = iif (array_length(SplitHostname) > 1, 'FQDN', '')

Microsoft Sentinel fornisce funzioni utili per la gestione dell'arricchimento. Ad esempio, usare la funzione seguente per assegnare automaticamente i campi SrcHostname, SrcDomainSrcDomainType e SrcFQDN in base al valore nel campo Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Questa funzione imposterà i campi come indicato di seguito:

Campo Computer Campi di output
server1 SrcHostname: server1
SrcDomain, SrcDomainType, SrcFQDN tutti vuoti
server1.microsoft.com SrcHostname: server1
SrcDomain: microsoft.com
SrcDomainType: FQDN
SrcFQDN:server1.microsoft.com

Le funzioni _ASIM_ResolveDstFQDN ed _ASIM_ResolveDvcFQDN eseguono un'attività simile popolando i campi e Dvc correlatiDst. Per un elenco completo delle funzioni della Guida di ASIM, vedere Funzioni ASIM

Selezionare i campi nel set di risultati

Il parser può selezionare facoltativamente i campi nel set di risultati. La rimozione di campi non necessario può migliorare le prestazioni e aumentare la chiarezza evitando confusione tra i campi normalizzati e i campi di origine rimanenti.

Gli operatori KQL seguenti vengono usati per selezionare i campi nel set di risultati:

Operatore Descrizione Quando usare in un parser
project-away Rimuove i campi. Usare project-away per campi specifici che si desidera rimuovere dal set di risultati. È consigliabile non rimuovere i campi originali non normalizzati dal set di risultati, a meno che non creino confusione o siano molto grandi e che abbiano implicazioni sulle prestazioni.
Progetto Seleziona i campi esistenti in precedenza o creati come parte dell'istruzione e rimuove tutti gli altri campi. Non è consigliabile usare in un parser, in quanto il parser non deve rimuovere altri campi non normalizzati.

Se è necessario rimuovere campi specifici, ad esempio i valori temporanei usati durante l'analisi, usare project-away per rimuoverli dai risultati.

Ad esempio, quando si analizza una tabella di log personalizzata, usare quanto segue per rimuovere i campi originali rimanenti che dispongono ancora di un descrittore di tipo:

    | project-away
        *_d, *_s, *_b, *_g

Gestire le varianti di analisi

Importante

Le diverse varianti rappresentano tipi di evento diversi , comunemente mappati a schemi diversi, sviluppano parser separati

In molti casi, gli eventi in un flusso di eventi includono varianti che richiedono una logica di analisi diversa. Per analizzare varianti diverse in un singolo parser, usare istruzioni condizionali come iff e caseoppure usare una struttura di unione.

Per usare union per gestire più varianti, creare una funzione separata per ogni variante e usare l'istruzione union per combinare i risultati:

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    ...
union parseLogs,  parseLogsWithUrls…

Per evitare eventi duplicati ed elaborazione eccessiva, assicurarsi che ogni funzione inizi filtrando, usando campi nativi, solo gli eventi che deve analizzare. Inoltre, se necessario, usare project-away in ogni ramo, prima dell'unione.

Distribuire i parser

Distribuire manualmente i parser copiandoli nella pagina del log di monitoraggio Azure e salvando la query come funzione. Questo metodo è utile per il test. Per altre informazioni, vedere Creare una funzione.

Per distribuire un numero elevato di parser, è consigliabile usare i modelli arm del parser, come indicato di seguito:

  1. Creare un file YAML basato sul modello pertinente per ogni schema e includervi la query. Iniziare con il modello YAML pertinente per lo schema e il tipo di parser, filtro o senza parametri.

  2. Usare il convertitore di modelli da YAML ASIM a ARM per convertire il file YAML in un modello arm.

  3. Se si distribuisce un aggiornamento, eliminare le versioni precedenti delle funzioni usando il portale o lo strumento di eliminazione della funzione di PowerShell.

  4. Distribuire il modello usando il portale di Azure o PowerShell.

È anche possibile combinare più modelli in un singolo processo di distribuzione usando modelli collegati

Consiglio

I modelli arm possono combinare risorse diverse, quindi i parser possono essere distribuiti insieme a connettori, regole analitiche o watchlist, per indicare alcune opzioni utili. Ad esempio, il parser può fare riferimento a una watchlist distribuita al suo fianco.

Parser di test

In questa sezione viene descritto che gli strumenti di test forniti da ASIM consentono di testare i parser. Detto questo, i parser sono codice, a volte complesse, e le procedure di controllo della qualità standard, ad esempio le revisioni del codice, sono consigliate oltre ai test automatizzati.

Installare gli strumenti di test ASIM

Per testare ASIM, distribuire lo strumento di test ASIM in un'area di lavoro Microsoft Sentinel in cui:

  • Il parser viene distribuito.
  • La tabella di origine usata dal parser è disponibile.
  • La tabella di origine usata dal parser viene popolata con una raccolta varia di eventi rilevanti.

Convalidare lo schema di output

Per assicurarsi che il parser produca uno schema valido, usare il tester dello schema ASIM eseguendo la query seguente nella pagina Log Microsoft Sentinel:

<parser name> | getschema | invoke ASimSchemaTester('<schema>')

Gestire i risultati come segue:

Errore Azione
Campo obbligatorio mancante [<Campo>] Aggiungere il campo al parser. In molti casi, si tratta di un valore derivato o di un valore costante e non di un campo già disponibile dall'origine.
Il campo mancante [<Campo>] è obbligatorio quando esiste la colonna obbligatoria [<Campo>] Aggiungere il campo al parser. In molti casi questo campo indica i tipi della colonna esistente a cui fa riferimento.
Il campo mancante [<Campo>] è obbligatorio quando esiste la colonna [<Campo>] Aggiungere il campo al parser. In molti casi questo campo indica i tipi della colonna esistente a cui fa riferimento.
Alias obbligatorio mancante [<Campo>] aliasing colonna esistente [<Campo>] Aggiungere l'alias al parser
Alias consigliato mancante [<Campo>] aliasing colonna esistente [<Campo>] Aggiungere l'alias al parser
Alias facoltativo mancante [<Campo>] aliasing colonna esistente [<Campo>] Aggiungere l'alias al parser
Alias obbligatorio mancante [<Campo>] aliasing colonna mancante [<Campo>] Questo errore accompagna un errore simile per il campo con alias. Correggere l'errore del campo con alias e aggiungere questo alias al parser.
Tipo non corrispondente per il campo [<Campo>]. Attualmente è [<Type>] e deve essere [<Type>] Assicurarsi che il tipo di campo normalizzato sia corretto, in genere usando una funzione di conversione come tostring.
Informazioni Azione
Campo consigliato mancante [<Campo>] Provare ad aggiungere questo campo al parser.
Informazioni Azione
Alias consigliato mancante [<Campo>] aliasing colonna inesistente [<Campo>] Se si aggiunge il campo con alias al parser, assicurarsi di aggiungere anche questo alias.
Alias facoltativo mancante [<Campo>] aliasing colonna inesistente [<Campo>] Se si aggiunge il campo con alias al parser, assicurarsi di aggiungere anche questo alias.
Campo facoltativo mancante [<Campo>] Anche se i campi facoltativi sono spesso mancanti, è opportuno esaminare l'elenco per determinare se è possibile eseguire il mapping di uno dei campi facoltativi dall'origine.
Campo extra non normalizzato [<Campo>] Anche se i campi non normalizzati sono validi, è opportuno esaminare l'elenco per determinare se è possibile eseguire il mapping di uno dei valori non normalizzati a un campo facoltativo.

Nota

Gli errori impediranno il corretto funzionamento del contenuto che usa il parser. Gli avvisi non impediscono il funzionamento del contenuto, ma possono ridurre la qualità dei risultati.

Convalidare i valori di output

Per assicurarsi che il parser produca valori validi, usare il tester dei dati ASIM eseguendo la query seguente nella pagina log Microsoft Sentinel:

<parser name> | limit <X> | invoke ASimDataTester ('<schema>')

La specifica di uno schema è facoltativa. Se non viene specificato uno schema, il EventSchema campo viene usato per identificare lo schema a cui l'evento deve rispettare. Se un evento non include un EventSchema campo, verranno verificati solo i campi comuni. Se uno schema viene specificato come parametro, questo schema verrà usato per testare tutti i record. Questa operazione è utile per i parser meno recenti che non impostano il EventSchema campo.

Nota

Anche quando non viene specificato uno schema, sono necessarie parentesi vuote dopo il nome della funzione.

Questo test richiede un elevato utilizzo di risorse e potrebbe non funzionare nell'intero set di dati. Impostare X sul numero più grande per il quale la query non scadrà o impostare l'intervallo di tempo per la query usando la selezione intervallo di tempo.

Gestire i risultati come segue:

Messaggio Azione
(0) Errore: tipo non corrispondente per la colonna [<Campo>]. Attualmente è [<Type>] e deve essere [<Type>] Assicurarsi che il tipo di campo normalizzato sia corretto, in genere usando una funzione di conversione come tostring.
(0) Errore: valore o valori non validi (fino a 10 elencati) per il campo [<Campo>] di tipo [<Tipo> logico] Assicurarsi che il parser esegga il mapping del campo di origine corretto al campo di output. Se il mapping è corretto, aggiornare il parser per trasformare il valore di origine nel tipo, nel valore o nel formato corretti. Per altre informazioni sui valori e i formati corretti per ogni tipo logico, vedere l'elenco dei tipi logici .

Si noti che lo strumento di test elenca solo un esempio di 10 valori non validi.
(1) Avviso: Valore vuoto nel campo obbligatorio [<Campo>] I campi obbligatori devono essere popolati, non solo definiti. Verificare se il campo può essere popolato da altre origini per i record per i quali l'origine corrente è vuota.
(2) Info: Valore vuoto nel campo consigliato [<Campo>] I campi consigliati devono in genere essere popolati. Verificare se il campo può essere popolato da altre origini per i record per i quali l'origine corrente è vuota.
(2) Info: Valore vuoto nel campo facoltativo [<Campo>] Verificare se il campo con alias è obbligatorio o consigliato e, in caso affermativo, se può essere popolato da altre origini.

Molti messaggi segnalano anche il numero di record che hanno generato il messaggio e la relativa percentuale del campione totale. Questa percentuale è un buon indicatore dell'importanza del problema. Ad esempio, per un campo consigliato:

  • Il 90% di valori vuoti può indicare un problema di analisi generale.
  • Il 25% di valori vuoti può indicare una variante di evento non analizzata correttamente.
  • Una manciata di valori vuoti può essere un problema trascurabile.

Nota

Gli errori impediranno il corretto funzionamento del contenuto che usa il parser. Gli avvisi non impediscono il funzionamento del contenuto, ma possono ridurre la qualità dei risultati.

Contribuire ai parser

È possibile contribuire con il parser alla distribuzione ASIM primaria. Se accettati, i parser saranno disponibili per ogni cliente come parser predefiniti ASIM.

Per contribuire ai parser:

Documentazione degli avvisi accettati

Se gli avvisi elencati dagli strumenti di test ASIM sono considerati validi per un parser, documentare gli avvisi accettati nel file YAML del parser usando la sezione Eccezioni, come illustrato nell'esempio seguente.

Exceptions:
- Field: DnsQuery 
  Warning: Invalid value
  Exception: May have values such as "1164-ms-7.1440-9fdc2aab.3b2bd806-978e-11ec-8bb3-aad815b5cd42" which are not valid domains names. Those are related to TKEY RR requests.
- Field: DnsQuery
  Warning: Empty value in mandatory field
  Exception: May be empty for requests for root servers and for requests for RR type DNSKEY

L'avviso specificato nel file YAML deve essere una forma breve del messaggio di avviso che identifica in modo univoco. Il valore viene usato per trovare la corrispondenza con i messaggi di avviso durante l'esecuzione di test automatizzati e ignorarli.

Linee guida per l'invio di esempi

I dati di esempio sono necessari per la risoluzione dei problemi del parser e per garantire che gli aggiornamenti futuri al parser siano conformi agli esempi precedenti. Gli esempi inviati devono includere qualsiasi variante di evento supportata dal parser. Assicurarsi che gli eventi di esempio includano tutti i possibili tipi di evento, formati di evento e varianti, ad esempio eventi che rappresentano un'attività riuscita e non riuscita. Assicurarsi anche che le variazioni nei formati di valore siano rappresentate. Ad esempio, se un nome host può essere rappresentato come fqdn o come nome host semplice, gli eventi di esempio devono includere entrambi i formati.

Per inviare gli esempi di evento, seguire questa procedura:

  • Logs Nella schermata eseguire una query che estrarrà dalla tabella di origine solo gli eventi selezionati dal parser. Ad esempio, per il parser DNS Infoblox, usare la query seguente:
    Syslog
    | where ProcessName == "named"

  • Esportare i risultati usando l'opzione Esporta in csv in un file denominato <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, Where EventProduct, EventProducte EventSchema sono i valori assegnati dal parser a tali campi.

  • Logs Nella schermata eseguire una query che restituisca lo schema o la tabella di input del parser. Ad esempio, per lo stesso parser DNS Infoblox, la query è:

    Syslog
    | getschema

  • Esportare i risultati usando l'opzione Esporta in csv in un file denominato <TableName>_schema.csv, dove TableName è il nome della tabella di origine usata dal parser.

  • Includere entrambi i file nella richiesta pull nella cartella /Sample Data/ASIM. Se il file esiste già, aggiungere l'handle di GitHub al nome, ad esempio: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Linee guida per l'invio dei risultati dei test

I risultati dei test sono importanti per verificare la correttezza del parser e comprendere eventuali eccezioni segnalate.

Per inviare i risultati del test, seguire questa procedura:

  • Eseguire i test del parser e descritti nella sezione test .

  • ed esportare i risultati dei test usando l'opzione Esporta in CSV rispettivamente in file denominati <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv e <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv .

  • Includere entrambi i file nella richiesta pull nella cartella /Parsers/ASim<schema>/Tests.

Passaggi successivi

Questo articolo illustra lo sviluppo di parser ASIM.

Altre informazioni sui parser ASIM:

Altre informazioni su ASIM in generale:

  • Last updated on