Utvikle ASIM-analyser (Advanced Security Information Model)

ASIM-brukere (Advanced Security Information Model) bruker samlende analyser i stedet for tabellnavn i spørringene sine, til å vise data i et normalisert format og inkludere alle data som er relevante for skjemaet i spørringen. Samlende parsers, i sin tur, bruke kildespesifikke parsers til å håndtere de spesifikke detaljene for hver kilde.

Microsoft Sentinel inneholder innebygde kildespesifikke analyser for mange datakilder. Du kan endre eller utvikle disse kildespesifikke parserne i følgende situasjoner:

  • Når enheten inneholder hendelser som passer til et ASIM-skjema, men en kildespesifikk parser for enheten og det relevante skjemaet ikke er tilgjengelig i Microsoft Sentinel.

  • Når ASIM kildespesifikke parsers er tilgjengelige for enheten, men enheten sender hendelser i en metode eller et format som er forskjellig fra forventet av ASIM-parserne. Eksempel:

    • Kildeenheten kan konfigureres til å sende hendelser på en ikke-standard måte.

    • Enheten kan ha en annen versjon enn den som støttes av ASIM-parseren.

    • Hendelsene kan samles inn, endres og videresendes av et mellomleddssystem.

Hvis du vil forstå hvordan analyser passer inn i ASIM-arkitekturen, kan du se ASIM-arkitekturdiagrammet.

Utviklingsprosess for egendefinert ASIM-analyse

Følgende arbeidsflyt beskriver trinnene på høyt nivå i utviklingen av en egendefinert ASIM, kildespesifikk parser:

  1. Samle inn eksempellogger.

  2. Identifiser skjemaene eller skjemaene som hendelsene sendt fra kilden representerer. Hvis du vil ha mer informasjon, kan du se Skjemaoversikt.

  3. Tilordne kildehendelsesfeltene til det identifiserte skjemaet eller skjemaene.

  4. Utvikle én eller flere ASIM-analyser for kilden. Du må utvikle en filtreringsanalyse og en parameterløs parser for hvert skjema som er relevant for kilden.

  5. Test analyseren.

  6. Distribuer analyser i Microsoft Sentinel arbeidsområder.

  7. Oppdater den relevante ASIM-parseren for å referere til den nye egendefinerte parseren. Hvis du vil ha mer informasjon, kan du se Administrere ASIM-analyser.

  8. Det kan også være lurt å bidra med analyser i den primære ASIM-fordelingen. Bidragsanalyser kan også gjøres tilgjengelig i alle arbeidsområder som innebygde analyser.

Denne artikkelen veileder deg gjennom prosessens trinn for utvikling, testing og distribusjon.

Tips

Se også nettseminaret Deep Dive på Microsoft Sentinel Normalisere analyser og normalisert innhold, eller se gjennom den relaterte lysbildevisningen. Hvis du vil ha mer informasjon, kan du se Neste trinn.

Samle inn eksempellogger

Hvis du vil bygge effektive ASIM-analyser, trenger du et representativt sett med logger, som i de fleste tilfeller krever at du konfigurerer kildesystemet og kobler det til Microsoft Sentinel. Hvis du ikke har kildeenheten tilgjengelig, kan du bruke skytjenester til å distribuere mange enheter for utvikling og testing.

I tillegg kan det å finne leverandørdokumentasjonen og eksemplene for loggene bidra til å akselerere utviklingen og redusere feil ved å sikre bred dekning av loggformat.

Et representativt sett med logger bør omfatte:

  • Hendelser med ulike hendelsesresultater.
  • Hendelser med ulike svarhandlinger.
  • Ulike formater for brukernavn, vertsnavn og ID-er og andre felt som krever verdinormalisering.

Tips

Start en ny egendefinert analyse ved hjelp av en eksisterende analyse for samme skjema. Bruk av en eksisterende parser er spesielt viktig for filtrering av parsere for å sikre at de godtar alle parameterne som kreves av skjemaet.

Planleggingstilordning

Før du utvikler en analyse, må du tilordne informasjonen som er tilgjengelig i kildehendelsen eller -hendelsene, til skjemaet du identifiserte:

  • Tilordne alle obligatoriske felt, og fortrinnsvis også anbefalte felt.
  • Prøv å tilordne all informasjon som er tilgjengelig fra kilden til normaliserte felt. Hvis det ikke er tilgjengelig som en del av det valgte skjemaet, kan du vurdere å tilordne til felt som er tilgjengelige i andre skjemaer.
  • Tilordne verdier for felt ved kilden til de normaliserte verdiene som tillates av ASIM. Den opprinnelige verdien lagres i et eget felt, for eksempel EventOriginalResultDetails.

Utvikle analyser

Utvikle både en filtrering og en parameterløs parser for hvert relevante skjema.

En egendefinert analyse er en KQL-spørring som er utviklet på Microsoft Sentinel Logs-siden. Analysespørringen har tre deler:

Filter>Analysere>Klargjøre felt

Filtrering

Filtrere de relevante postene

I mange tilfeller inneholder en tabell i Microsoft Sentinel flere typer hendelser. Eksempel:

  • Syslog-tabellen har data fra flere kilder.
  • Egendefinerte tabeller kan inneholde informasjon fra én enkelt kilde som inneholder mer enn én hendelsestype, og som kan passe til ulike skjemaer.

Derfor bør en parser først filtrere bare postene som er relevante for målskjemaet.

Filtrering i KQL gjøres ved hjelp av operatoren where . For eksempel: Oppretting av Sysmon-hendelse 1-rapporter , og normaliseres derfor til ProcessEvent-skjemaet . Hendelsen Sysmon event 1 er en del av Event tabellen, så du bruker følgende filter:

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

Viktig

En parser bør ikke filtrere etter tid. Spørringen som bruker parseren, bruker et tidsintervall.

Filtrering etter kildetype ved hjelp av en visningsliste

I noen tilfeller inneholder ikke selve hendelsen informasjon som tillater filtrering for bestemte kildetyper.

Infoblox DNS-hendelser sendes for eksempel som Syslog-meldinger og er vanskelige å skille fra Syslog-meldinger som sendes fra andre kilder. I slike tilfeller er analyseren avhengig av en liste over kilder som definerer de relevante hendelsene. Denne listen beholdes i den Sources_by_SourceType visningslisten.

Hvis du vil bruke ASimSourceType-visningslisten i analyser, bruker _ASIM_GetSourceBySourceType du funksjonen i inndelingen for analysefiltrering. Infoblox DNS-parseren inkluderer for eksempel følgende i filtreringsdelen:

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

Slik bruker du dette eksemplet i analyseren:

  • Erstatt Computer med navnet på feltet som inneholder kildeinformasjonen for kilden. Du kan beholde dette som Computer for alle parsere basert på Syslog.

  • Erstatt tokenet InfobloxNIOS med en verdi du ønsker for analyseren. Informer parserbrukere om at de må oppdatere ASimSourceType visningslisten ved hjelp av den valgte verdien, i tillegg til listen over kilder som sender hendelser av denne typen.

Filtrering basert på parserparametere

Når du utvikler filtreringsparsere, må du kontrollere at parseren godtar filtreringsparameterne for det aktuelle skjemaet, som dokumentert i referanseartikkelen for dette skjemaet. Hvis du bruker en eksisterende analyse som utgangspunkt, sikrer du at parseren inneholder riktig funksjonssignatur. I de fleste tilfeller er den faktiske filtreringskoden også lik for filtrering av parsere for samme skjema.

Når du filtrerer, må du kontrollere at du:

  • Filtrer før du analyserer ved hjelp av fysiske felt. Hvis de filtrerte resultatene ikke er nøyaktige nok, gjentar du testen etter analyse for å finjustere resultatene. Hvis du vil ha mer informasjon, kan du se filtreringsoptimalisering.
  • Ikke filtrer hvis parameteren ikke er definert og fortsatt har standardverdien.

Eksemplene nedenfor viser hvordan du implementerer filtrering for en strengparameter, der standardverdien vanligvis er *, og for en listeparameter, der standardverdien vanligvis er en tom liste.

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

Se mer informasjon om følgende elementer i Kusto-dokumentasjonen:

Filtreringsoptimalisering

Legg merke til følgende filtreringsanbefalinger for å sikre ytelsen til parseren:

  • Filtrer alltid på innebygde felt i stedet for analyserte felt. Selv om det noen ganger er enklere å filtrere ved hjelp av analyserte felt, påvirker det ytelsen dramatisk.
  • Bruk operatorer som gir optimalisert ytelse. Spesielt , ==, hasog startswith. Bruk av operatorer, for eksempel contains eller matches regex , påvirker ytelsen dramatisk.

Filtreringsanbefalinger for ytelse er kanskje ikke alltid enkle å følge. Bruk er has for eksempel mindre nøyaktig enn contains. I andre tilfeller er det mindre nøyaktig å sammenligne det innebygde feltet, for eksempel SyslogMessage, enn å sammenligne et utpakket felt, for eksempel DvcAction. I slike tilfeller anbefaler vi at du fortsatt forhåndsfiltrerer ved hjelp av en ytelsesoptimaliseringsoperator over et innebygd felt, og gjentar filteret ved hjelp av mer nøyaktige betingelser etter analyse.

Hvis du vil ha et eksempel, kan du se følgende Infoblox DNS-parsersnutt. Parseren kontrollerer først at SyslogMessage-feltet has er ordet client. Termen kan imidlertid brukes på et annet sted i meldingen, så etter å ha analysert Log_Type feltet, kontrollerer parseren igjen at ordet client faktisk var feltets verdi.

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

Obs!

Analyser bør ikke filtrere etter tid, da spørringen som bruker parseren, allerede filtrerer for tid.

Analyse

Når spørringen velger de relevante postene, må den kanskje analysere dem. Analyse er vanligvis nødvendig hvis flere hendelsesfelt formidles i ett enkelt tekstfelt.

KQL-operatorene som utfører analysering, er oppført nedenfor, sortert etter ytelsesoptimalisering. Den første gir den mest optimaliserte ytelsen, mens den siste gir den minst optimaliserte ytelsen.

Operator/funksjon() Beskrivelse
split() funksjon Analyser en streng med verdier med skilletegn.
parse_csv() funksjon Analyser en streng med verdier som er formatert som en CSV-linje (kommadelte verdier).
parse-kv-operator Trekker ut strukturert informasjon fra et strenguttrykk og representerer informasjonen i et nøkkel-/verdiskjema.
parse-operator Analyser flere verdier fra en vilkårlig streng ved hjelp av et mønster, som kan være et forenklet mønster med bedre ytelse eller et vanlig uttrykk.
extract_all() funksjon Analyser enkeltverdier fra en vilkårlig streng ved hjelp av et vanlig uttrykk. extract_all har en lignende ytelse som parse hvis sistnevnte bruker et vanlig uttrykk.
extract() funksjon Trekk ut én enkelt verdi fra en vilkårlig streng ved hjelp av et vanlig uttrykk.

Bruk extract gir bedre ytelse enn parse eller extract_all hvis en enkelt verdi er nødvendig. Bruk av flere aktiveringer for extract den samme kildestrengen er imidlertid mindre effektivt enn én enkelt parse eller extract_all bør unngås.
parse_json() funksjon Analyser verdiene i en streng formatert som JSON. Hvis bare noen få verdier er nødvendig fra JSON, bruker parse, extracteller extract_all gir bedre ytelse.
parse_xml() funksjon Analyser verdiene i en streng formatert som XML. Hvis bare noen få verdier er nødvendig fra XML-filen, bruker parse, extracteller extract_all gir bedre ytelse.

Normalisering

Tilordne feltnavn

Den enkleste formen for normalisering gir et opprinnelig felt nytt navn. Bruk operatoren project-rename for dette. Hvis du bruker prosjektgøving, sikrer du at feltet fortsatt administreres som et fysisk felt, og at håndteringen av feltet er mer effektivt. Eksempel:

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

Normalisere feltformatering og -type

I mange tilfeller må den opprinnelige verdien som trekkes ut, normaliseres. I ASIM bruker for eksempel en MAC-adresse kolon som skilletegn, mens kilden kan sende en MAC-adresse med bindestrek med skilletegn. Den primære operatoren for å transformere verdier er extendsammen med et bredt sett med KQL-strenger, numeriske funksjoner og datofunksjoner.

Det er også viktig at analysering av utdatafelt samsvarer med typen som er definert i skjemaet, for at analyser skal fungere. Du må for eksempel kanskje konvertere en streng som representerer dato og klokkeslett til et datetime-felt. Funksjoner som todatetime og tohex er nyttige i disse tilfellene.

Den opprinnelige unike hendelses-ID-en kan for eksempel sendes som et heltall, men ASIM krever at verdien er en streng, for å sikre bred kompatibilitet mellom datakilder. Derfor, når du tilordner bruk extend av project-renamekildefeltet og tostring i stedet for :

  | extend EventOriginalUid = tostring(ReportId),

Avledede felt og verdier

Verdien for kildefeltet, når det er trukket ut, må kanskje tilordnes verdisettet som er angitt for målskjemafeltet. Funksjonene iff, caseog lookup kan være nyttige for å tilordne tilgjengelige data til målverdier.

Microsoft DNS-analyse tilordner for eksempel feltet basert på hendelses-ID-en EventResult og svarkoden ved hjelp av en iff setning, som følger:

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

Hvis du vil tilordne flere verdier, definerer du tilordningen ved hjelp av operatoren datatable og bruker lookup til å utføre tilordningen. Noen kilder rapporterer for eksempel numeriske DNS-svarkoder og nettverksprotokollen, mens skjemaet krever den vanligste tekstetikettrepresentasjonen for begge. Følgende eksempel viser hvordan du kan utlede de nødvendige verdiene ved hjelp av datatable og 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

Legg merke til at oppslag er nyttig og effektivt også når tilordningen bare har to mulige verdier.

Når tilordningsbetingelsene er mer komplekse kombinerer iff, caseog lookup. Eksemplet nedenfor viser hvordan du kombinerer lookup og case. Eksemplet lookup ovenfor returnerer en tom verdi i feltet DnsResponseCodeName hvis oppslagsverdien ikke blir funnet. Eksemplet case nedenfor forsterker det ved å bruke resultatet av lookup operasjonen hvis tilgjengelig, og angi flere betingelser ellers.

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

Microsoft Sentinel gir praktiske funksjoner for vanlige oppslagsverdier. Oppslaget ovenfor kan for eksempel DnsResponseCodeName implementeres ved hjelp av én av følgende funksjoner:


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

Det første alternativet godtar som en parameter verdien du vil slå opp, og lar deg velge utdatafeltet og derfor nyttig som en generell oppslagsfunksjon. Det andre alternativet er mer rettet mot parsers, tar som inndata navnet på kildefeltet, og oppdaterer det nødvendige ASIM-feltet, i dette tilfellet DnsResponseCodeName.

Hvis du vil ha en fullstendig liste over hjelpefunksjoner for ASIM, kan du se ASIM-funksjoner

Berikelsesfelt

I tillegg til feltene som er tilgjengelige fra kilden, inneholder en resulterende ASIM-hendelse berikelsesfelt som parseren skal generere. I mange tilfeller kan parserne tilordne en konstant verdi til feltene, for eksempel:

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

En annen type berikelsesfelt som parserne skal angi, er typefelt, som angir verditypen som er lagret i et relatert felt. Feltet angir for eksempel SrcUsernameType verditypen som er lagret i feltet SrcUsername . Du finner mer informasjon om typefelt i enhetsbeskrivelsen.

I de fleste tilfeller tilordnes også typer en konstant verdi. I noen tilfeller må imidlertid typen fastsettes basert på den faktiske verdien, for eksempel:

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

Microsoft Sentinel inneholder nyttige funksjoner for håndtering av berikelse. Bruk for eksempel følgende funksjon til automatisk å tilordne feltene SrcHostname, SrcDomainTypeSrcDomainog SrcFQDN basert på verdien i feltet Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Denne funksjonen angir feltene som følger:

Datamaskinfelt Utdatafelt
server1 SrcHostname: server1
SrcDomain, SrcDomainType, SrcFQDN alle tomme
server1.microsoft.com SrcHostname: server1
SrcDomain: microsoft.com
SrcDomainType: FQDN
SrcFQDN:server1.microsoft.com

Funksjonene _ASIM_ResolveDstFQDN og _ASIM_ResolveDvcFQDN utføre en lignende aktivitet som fyller ut de relaterte Dst og Dvc feltene. Hvis du vil ha en fullstendig liste over hjelpefunksjoner for ASIM, kan du se ASIM-funksjoner

Velg felt i resultatsettet

Parseren kan eventuelt velge felt i resultatsettet. Fjerning av unødvendige felt kan forbedre ytelsen og gjøre ytelsen mer tydelig ved å unngå forvirrende mellom normaliserte felt og gjenværende kildefelt.

Følgende KQL-operatorer brukes til å velge felt i resultatsettet:

Operatør Beskrivelse Når du skal bruke i en analyser
project-away Fjerner felt. Brukes project-away for bestemte felt som du vil fjerne fra resultatsettet. Vi anbefaler at du ikke fjerner de opprinnelige feltene som ikke er normalisert fra resultatsettet, med mindre de skaper forvirring eller er svært store og kan ha ytelsesimplikasjoner.
Prosjektet Merker felt som fantes før, eller som ble opprettet som en del av setningen, og fjerner alle andre felt. Anbefales ikke for bruk i en analyse, da analyseren ikke bør fjerne andre felt som ikke er normalisert.

Hvis du må fjerne bestemte felt, for eksempel midlertidige verdier som brukes under analysering, kan du bruke project-away til å fjerne dem fra resultatene.

Når du for eksempel analyserer en egendefinert loggtabell, kan du bruke følgende til å fjerne de gjenværende opprinnelige feltene som fortsatt har en typebeskrivelse:

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

Håndter analysevarianter

Viktig

De ulike variantene representerer forskjellige hendelsestyper, vanligvis tilordnet til forskjellige skjemaer, og utvikler separate parsere

I mange tilfeller inkluderer hendelser i en hendelsesstrøm varianter som krever forskjellig analyselogikk. Hvis du vil analysere forskjellige varianter i én enkelt parser, kan du enten bruke betingede setninger, for eksempel iff og case, eller bruke en unionsstruktur.

Hvis du vil bruke union til å håndtere flere varianter, oppretter du en separat funksjon for hver variant og bruker unionsetningen til å kombinere resultatene:

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…

Hvis du vil unngå dupliserte hendelser og overflødig behandling, må du sørge for at hver funksjon starter ved å filtrere, ved hjelp av opprinnelige felt, bare hendelsene den er ment å analysere. Du kan også, om nødvendig, bruke prosjekt-away på hver gren, før unionen.

Distribuer analyser

Distribuer analyser manuelt ved å kopiere dem til siden Azure overvåkingslogg og lagre spørringen som en funksjon. Denne metoden er nyttig for testing. Hvis du vil ha mer informasjon, kan du se Opprette en funksjon.

Hvis du vil distribuere et stort antall parsere, anbefaler vi at du bruker ARM-maler for analyser, som følger:

  1. Opprett en YAML-fil basert på den relevante malen for hvert skjema, og inkluder spørringen i den. Start med YAML-malen som er relevant for skjema- og parsertype, filtrering eller parameterfri.

  2. Bruk ASIM YAML til ARM-malkonverteringsprogrammet for å konvertere YAML-filen til en ARM-mal.

  3. Hvis du distribuerer en oppdatering, sletter du eldre versjoner av funksjonene ved hjelp av portalen eller funksjonen sletter PowerShell-verktøyet.

  4. Distribuer malen ved hjelp av Azure Portal eller PowerShell.

Du kan også kombinere flere maler til én enkelt distribusjonsprosess ved hjelp av koblede maler

Tips

ARM-maler kan kombinere ulike ressurser, slik at analyser kan distribueres sammen med koblinger, analytiske regler eller visningslister for å nevne noen nyttige alternativer. Analyseren kan for eksempel referere til en visningsliste som er distribuert sammen med den.

Testanalyser

Denne delen beskriver at testverktøyene ASIM gir deg mulighet til å teste analyser. Når det er sagt, parsers er kode, noen ganger komplekse, og standard kvalitetssikring praksis som kode vurderinger anbefales i tillegg til automatisert testing.

Installer ASIM-testverktøy

Hvis du vil teste ASIM, distribuerer du ASIM-testverktøyet til et Microsoft Sentinel arbeidsområde der:

  • Analyseren distribueres.
  • Kildetabellen som brukes av analyseren, er tilgjengelig.
  • Kildetabellen som brukes av parseren, fylles ut med en variert samling av relevante hendelser.

Validere utdataskjemaet

For å sikre at parseren produserer et gyldig skjema, kan du bruke ASIM-skjematesteren ved å kjøre følgende spørring på Microsoft Sentinel Logger-siden:

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

Behandle resultatene på følgende måte:

Feil Handling
Mangler obligatorisk felt [<Felt>] Legg til feltet i analyseren. I mange tilfeller vil dette være en avledet verdi eller en konstant verdi, og ikke et felt som allerede er tilgjengelig fra kilden.
Manglende felt [<Felt>] er obligatorisk når obligatorisk kolonne [<Felt>] finnes Legg til feltet i analyseren. I mange tilfeller angir dette feltet typene for den eksisterende kolonnen den refererer til.
Manglende felt [<Felt>] er obligatorisk når kolonnen [<Felt>] finnes Legg til feltet i analyseren. I mange tilfeller angir dette feltet typene for den eksisterende kolonnen den refererer til.
Mangler obligatorisk alias [<Felt>]-alias for eksisterende kolonne [<Felt>] Legg til aliaset i analyseren
Mangler anbefalt alias [<Felt>] alias for eksisterende kolonne [<Felt>] Legg til aliaset i analyseren
Mangler valgfritt alias [<Felt>]-alias for eksisterende kolonne [<Felt>] Legg til aliaset i analyseren
Mangler obligatorisk alias [<Felt>] alias mangler kolonne [<Felt>] Denne feilen følger med en lignende feil for aliasfeltet. Rett opp aliasfeltfeilen, og legg til dette aliaset i analyseren.
Typekonflikt for feltet [<Felt>]. Den er for øyeblikket [<Type>] og må være [<Type>] Kontroller at typen normalisert felt er riktig, vanligvis ved hjelp av en konverteringsfunksjon , for eksempel tostring.
Info Handling
Mangler anbefalt felt [<Felt>] Vurder å legge til dette feltet i analyseren.
Info Handling
Mangler anbefalt alias [<Felt>]-alias for ikke-eksisterende kolonne [<Felt>] Hvis du legger til aliasfeltet i analyseren, må du også legge til dette aliaset.
Mangler valgfritt alias [<Felt>]-alias for ikke-eksisterende kolonne [<Felt>] Hvis du legger til aliasfeltet i analyseren, må du også legge til dette aliaset.
Mangler valgfritt felt [<Felt>] Selv om valgfrie felt ofte mangler, er det verdt å se gjennom listen for å avgjøre om noen av de valgfrie feltene kan tilordnes fra kilden.
Ekstra unormalisert felt [<Felt>] Selv om unormaliserte felt er gyldige, er det verdt å se gjennom listen for å avgjøre om noen av de unormaliserte verdiene kan tilordnes til et valgfritt felt.

Obs!

Feil hindrer at innhold som bruker analyseren, fungerer som det skal. Advarsler hindrer ikke innhold i å fungere, men kan redusere kvaliteten på resultatene.

Valider utdataverdiene

Hvis du vil forsikre deg om at analyseren produserer gyldige verdier, kan du bruke ASIM-datatesteren ved å kjøre følgende spørring på Microsoft Sentinel Logger-siden:

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

Det er valgfritt å angi et skjema. Hvis et skjema ikke er angitt, EventSchema brukes feltet til å identifisere skjemaet hendelsen skal følge. Hvis en hendelse ikke inkluderer et EventSchema felt, blir bare fellesfelt bekreftet. Hvis et skjema er angitt som en parameter, brukes dette skjemaet til å teste alle poster. Dette er nyttig for eldre analyser som ikke angir EventSchema feltet.

Obs!

Selv når et skjema ikke er angitt, kreves tomme parenteser etter funksjonsnavnet.

Denne testen er ressurskrevende og fungerer kanskje ikke på hele datasettet. Angi X til det største tallet som spørringen ikke blir tidsavbrutt for, eller angi tidsintervallet for spørringen ved hjelp av tidsområdevelgeren.

Behandle resultatene på følgende måte:

Melding Handling
(0) Feil: typekonflikt for kolonnen [<Felt>]. Den er for øyeblikket [<Type>] og må være [<Type>] Kontroller at typen normalisert felt er riktig, vanligvis ved hjelp av en konverteringsfunksjon , for eksempel tostring.
(0) Feil: Ugyldige verdier (opptil 10 oppført) for feltet [<Felt>] av typen [<Logisk type>] Kontroller at analyseren tilordner riktig kildefelt til utdatafeltet. Hvis den er tilordnet riktig, oppdaterer du parseren for å transformere kildeverdien til riktig type, verdi eller format. Se listen over logiske typer for mer informasjon om de riktige verdiene og formatene for hver logiske type.

Vær oppmerksom på at testverktøyet bare viser et utvalg på 10 ugyldige verdier.
(1) Advarsel! Tom verdi i obligatorisk felt [<Felt>] Obligatoriske felt skal fylles ut, ikke bare definert. Kontroller om feltet kan fylles ut fra andre kilder for poster der gjeldende kilde er tom.
(2) Informasjon: Tom verdi i anbefalt felt [<Felt>] Anbefalte felt skal vanligvis fylles ut. Kontroller om feltet kan fylles ut fra andre kilder for poster der gjeldende kilde er tom.
(2) Informasjon: Tom verdi i valgfritt felt [<Felt>] Kontroller om aliasfeltet er obligatorisk eller anbefalt, og i så fall om det kan fylles ut fra andre kilder.

Mange av meldingene rapporterer også hvor mange poster som genererte meldingen og prosentandelen av det totale utvalget. Denne prosentandelen er en god indikator på viktigheten av problemet. For et anbefalt felt:

  • 90 % tomme verdier kan indikere et generelt analyseproblem.
  • 25 % tomme verdier kan indikere en hendelsesvariant som ikke ble analysert riktig.
  • En håndfull tomme verdier kan være et ubetydelig problem.

Obs!

Feil hindrer at innhold som bruker analyseren, fungerer som det skal. Advarsler hindrer ikke innhold i å fungere, men kan redusere kvaliteten på resultatene.

Bidra med analyser

Det kan være lurt å bidra med analyse til den primære ASIM-fordelingen. Hvis de godtas, vil parserne være tilgjengelige for hver kunde som innebygde ASIM-parsere.

Slik bidrar du med analyser:

Dokumenterer godkjente advarsler

Hvis advarsler oppført av ASIM-testverktøyene anses som gyldige for en parser, dokumenterer du de godtatte advarslene i parser YAML-filen ved hjelp av Unntak-delen som vist i eksemplet nedenfor.

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

Advarselen som er angitt i YAML-filen, bør være en kort form for advarselen som identifiseres unikt. Verdien brukes til å sammenligne advarsler når du utfører automatiserte tester og ignorerer dem.

Retningslinjer for innsending av eksempler

Eksempeldata er nødvendig når du feilsøker analyseproblemer og for å sikre at fremtidige oppdateringer til analyseren samsvarer med eldre eksempler. Eksemplene du sender, bør inneholde alle hendelsesvarianter som parseren støtter. Kontroller at eksempelhendelsene inkluderer alle mulige hendelsestyper, hendelsesformater og variasjoner, for eksempel hendelser som representerer vellykket og mislykket aktivitet. Kontroller også at variasjoner i verdiformater er representert. Hvis for eksempel et vertsnavn kan representeres som et FQDN eller et enkelt vertsnavn, bør eksempelhendelsene inneholde begge formatene.

Bruk følgende fremgangsmåte for å sende inn hendelseseksempler:

  • Kjør en spørring som bare vil trekke ut fra kildetabellen Logs , i skjermbildet som er valgt av parseren. Bruk for eksempel følgende spørring for Infoblox DNS-parseren:
    Syslog
    | where ProcessName == "named"

  • Eksporter resultatene ved hjelp av alternativet Eksporter til CSV til en fil med navnet <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, Hvor EventProduct, EventProductog EventSchema er verdiene tilordnet av analyseren til disse feltene.

  • Logs Kjør en spørring som skal sende skjemaet eller inndatatabellen for analysering på skjermen. Spørringen er for eksempel for den samme Infoblox DNS-parseren:

    Syslog
    | getschema

  • Eksporter resultatene ved hjelp av alternativet Eksporter til CSV til en fil kalt <TableName>_schema.csv, der TableName er navnet på kildetabellen som analyseren bruker.

  • Inkluder begge filene i pull-forespørselen i mappen /Sample Data/ASIM. Hvis filen allerede finnes, kan du legge til GitHub-håndtaket i navnet, for eksempel: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Retningslinjer for innsending av testresultater

Testresultater er viktige for å bekrefte korrektheten til analyseren og forstå eventuelle rapporterte unntak.

Bruk følgende fremgangsmåte for å sende inn testresultatene:

  • Kjør analysetestene og beskrevet i testdelen .

  • og eksporter testresultatene ved hjelp av alternativet Eksporter til CSV til filer med navn <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv og <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv henholdsvis.

  • Inkluder begge filene i pull-forespørselen i mappen /Parsers/ASim<schema>/Tests.

Neste trinn

Denne artikkelen tar for seg utvikling av ASIM-analyser.

Mer informasjon om ASIM-analyser:

Mer informasjon om ASIM generelt:

  • Last updated on