Udvikl ASIM-fortolkere (Advanced Security Information Model)

ASIM-brugere (Advanced Security Information Model) bruger samlende fortolkere i stedet for tabelnavne i deres forespørgsler til at få vist data i et normaliseret format og til at inkludere alle data, der er relevante for skemaet, i forespørgslen. Forenende fortolkninger bruger til gengæld kildespecifikke fortolkninger til at håndtere de specifikke oplysninger om hver kilde.

Microsoft Sentinel indeholder indbyggede, kildespecifikke fortolkninger til mange datakilder. Det kan være en god idé at ændre eller udvikle disse kildespecifikke fortolkninger i følgende situationer:

• Når enheden leverer hændelser, der passer til et ASIM-skema, men en kildespecifik parser til din enhed og det relevante skema ikke er tilgængelig i Microsoft Sentinel.

• Når ASIM-kildespecifikke fortolkninger er tilgængelige for din enhed, men enheden sender hændelser i en metode eller et andet format end forventet af ASIM-fortolkerne. Det kan f.eks. være:

  • Kildeenheden kan være konfigureret til at sende hændelser på en måde, der ikke er standard.

  • Enheden kan have en anden version end den, der understøttes af ASIM-fortolkeren.

  • Hændelserne kan indsamles, ændres og videresendes af et mellemliggende system.

Se ASIM-arkitekturdiagrammet for at forstå, hvordan fortolkere passer inden for ASIM-arkitekturen.

Brugerdefineret udviklingsproces for ASIM-parser

I følgende arbejdsproces beskrives de overordnede trin til udvikling af en brugerdefineret ASIM-kildespecifik parser:

1. Indsaml eksempellogge.

2. Identificer de skemaer eller skemaer, som hændelserne, der sendes fra kilden, repræsenterer. Du kan få flere oplysninger under Skemaoversigt.

3. Knyt kildehændelsesfelterne til det eller de identificerede skemaer.

4. Udvikl en eller flere ASIM-fortolkere til din kilde. Du skal udvikle en filtreringsparser og en parser uden parametre for hvert skema, der er relevant for kilden.

5. Test din parser.

6. Udrul fortolkerne i dine Microsoft Sentinel arbejdsområder.

7. Opdater den relevante ASIM-samlende parser for at referere til den nye brugerdefinerede parser. Du kan finde flere oplysninger under Administration af ASIM-fortolkere.

8. Det kan også være en god idé at bidrage med dine fortolkninger til den primære ASIM-distribution. Bidragsparsere kan også gøres tilgængelige i alle arbejdsområder som indbyggede fortolkere.

Denne artikel fører dig gennem processens udviklings-, test- og udrulningstrin.

Indsaml eksempellogge

Hvis du vil oprette effektive ASIM-fortolkninger, skal du bruge et repræsentativt sæt logge, hvilket i de fleste tilfælde kræver, at kildesystemet konfigureres og forbindes med Microsoft Sentinel. Hvis du ikke har kildeenheden tilgængelig, kan du med cloudtjenester med betaling efter forbrug udrulle mange enheder til udvikling og test.

Derudover kan det hjælpe med at fremskynde udviklingen og reducere antallet af fejl ved at sikre bred dækning af logformatet, hvis du finder leverandørdokumentationen og eksemplerne til loggene.

Et repræsentativt sæt logge skal omfatte:

• Hændelser med forskellige hændelsesresultater.
• Hændelser med forskellige svarhandlinger.
• Forskellige formater for brugernavn, værtsnavn og id'er og andre felter, der kræver normalisering af værdien.

Planlægningstilknytning

Før du udvikler en parser, skal du knytte de oplysninger, der er tilgængelige i kildehændelsen eller -hændelserne, til det skema, du har identificeret:

• Tilknyt alle obligatoriske felter og helst også anbefalede felter.
• Prøv at knytte alle tilgængelige oplysninger fra kilden til normaliserede felter. Hvis den ikke er tilgængelig som en del af det valgte skema, kan du overveje at knytte til felter, der er tilgængelige i andre skemaer.
• Knyt værdier for felter i kilden til de normaliserede værdier, der er tilladt af ASIM. Den oprindelige værdi gemmes i et separat felt, f.eks EventOriginalResultDetails. .

Udvikling af fortolkere

Udvikl både en filtrering og en parameterfri parser for hvert relevant skema.

En brugerdefineret parser er en KQL-forespørgsel, der er udviklet på siden logfiler for Microsoft Sentinel. Parserforespørgslen indeholder tre dele:

Filter>Parse>Forbered felter

Filtrering

Filtrering af de relevante poster

I mange tilfælde indeholder en tabel i Microsoft Sentinel flere typer hændelser. Det kan f.eks. være:

• Tabellen Syslog indeholder data fra flere kilder.
• Brugerdefinerede tabeller kan indeholde oplysninger fra en enkelt kilde, der indeholder mere end én hændelsestype og kan passe til forskellige skemaer.

Derfor skal en parser først filtrere de poster, der er relevante for målskemaet.

Filtrering i KQL udføres ved hjælp af operatoren where . Sysmon-hændelse 1 rapporterer f.eks. procesoprettelse og normaliseres derfor til ProcessEvent-skemaet. Sysmon-hændelsen 1-hændelsen er en del af Event tabellen, så du skal bruge følgende filter:

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

Filtrering efter kildetype ved hjælp af en visningsliste

I nogle tilfælde indeholder selve hændelsen ikke oplysninger, der tillader filtrering for bestemte kildetyper.

Infoblox DNS-hændelser sendes f.eks. som Syslog-meddelelser og er svære at skelne fra Syslog-meddelelser, der sendes fra andre kilder. I sådanne tilfælde er fortolkeren afhængig af en liste over kilder, der definerer de relevante hændelser. Denne liste vedligeholdes på Sources_by_SourceType visningsliste.

Hvis du vil bruge ASimSourceType-visningslisten i dine fortolkninger, skal du bruge _ASIM_GetSourceBySourceType funktionen i afsnittet parserfiltrering. Infoblox DNS-fortolkeren indeholder f.eks. følgende i afsnittet om filtrering:

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

Sådan bruger du dette eksempel i din parser:

• Erstat Computer med navnet på det felt, der indeholder kildeoplysningerne for kilden. Du kan bevare dette som Computer for alle fortolkere, der er baseret på Syslog.

• Erstat tokenet InfobloxNIOS med en værdi efter eget valg for din parser. Informer parserbrugerne om, at de skal opdatere visningslisten ASimSourceType ved hjælp af den valgte værdi samt listen over kilder, der sender hændelser af denne type.

Filtrering baseret på parserparametre

Når du udvikler filtreringsparsere, skal du sørge for, at fortolkeren accepterer filtreringsparametrene for det relevante skema, som beskrevet i referenceartiklen for det pågældende skema. Brug af en eksisterende parser som udgangspunkt sikrer, at fortolkeren indeholder den korrekte funktionssignatur. I de fleste tilfælde er den faktiske filtreringskode også den samme for filtreringsparsere for det samme skema.

Når du filtrerer, skal du sørge for, at du:

• Filtrer, før du fortolker ved hjælp af fysiske felter. Hvis de filtrerede resultater ikke er nøjagtige nok, skal du gentage testen efter parsing for at finjustere resultaterne. Du kan få flere oplysninger under Optimering af filtrering.
• Filtrer ikke, hvis parameteren ikke er defineret og stadig har standardværdien.

Følgende eksempler viser, hvordan du implementerer filtrering for en strengparameter, hvor standardværdien normalt er '*' og for en listeparameter, hvor standardværdien normalt er en tom liste.

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

Du kan få flere oplysninger om følgende elementer i dokumentationen til Kusto:

• funktionen array_length
• operatoren has_any

Optimering af filtrering

Hvis du vil sikre fortolkerens ydeevne, skal du bemærke følgende filtreringsanbefalinger:

• Filtrer altid på indbyggede felter i stedet for fortolkede felter. Selvom det nogle gange er nemmere at filtrere ved hjælp af fortolkede felter, påvirker det ydeevnen dramatisk.
• Brug operatorer, der leverer optimeret ydeevne. Især , ==hasog startswith. Brug af operatorer som contains f.eks. eller matches regex påvirker også ydeevnen dramatisk.

Filtreringsanbefalinger til ydeevne er muligvis ikke altid nemme at følge. Brug has er f.eks. mindre præcis end contains. I andre tilfælde er det mindre nøjagtigt at matche det indbyggede felt, f.eks SyslogMessage. , end at sammenligne et udtrukket felt, f.eks DvcAction. . I sådanne tilfælde anbefaler vi, at du stadig filtrerer på forhånd ved hjælp af en operator til optimering af ydeevnen over et indbygget felt og gentager filteret ved hjælp af mere nøjagtige betingelser efter fortolkning.

Du kan finde et eksempel i følgende Infoblox DNS-parser-kodestykke. Fortolkeren kontrollerer først, at feltet SyslogMessage indeholder has ordet client. Udtrykket kan dog bruges et andet sted i meddelelsen, så efter fortolkning af Log_Type feltet kontrollerer fortolkeren igen, at ordet client faktisk var feltets værdi.

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

Parsing

Når forespørgslen vælger de relevante poster, kan det være nødvendigt at fortolke dem. Fortolkning er typisk nødvendig, hvis flere hændelsesfelter formidles i et enkelt tekstfelt.

De KQL-operatorer, der udfører fortolkning, er angivet nedenfor, sorteret efter deres optimering af ydeevnen. Den første leverer den mest optimerede ydeevne, mens den sidste leverer den mindst optimerede ydeevne.

Normalisere

Tilknytning af feltnavne

Den nemmeste form for normalisering er at omdøbe et oprindeligt felt til det normaliserede navn. Brug operatoren project-rename til dette. Hvis du bruger omdøbning af projekter, sikrer du, at feltet stadig administreres som et fysisk felt, og at håndteringen af feltet er mere effektiv. Det kan f.eks. være:

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

Normaliserer felters format og type

I mange tilfælde skal den udtrukne oprindelige værdi normaliseres. I ASIM bruger en MAC-adresse f.eks. kolon som separator, mens kilden kan sende en bindestreg afgrænset MAC-adresse. Den primære operator til transformering af værdier er extendsammen med et bredt sæt KQL-strengfunktioner, numeriske funktioner og datofunktioner.

Det er også vigtigt at sikre, at parseroutputfelter svarer til den type, der er defineret i skemaet, for at fortolkere kan fungere. Det kan f.eks. være, at du skal konvertere en streng, der repræsenterer dato og klokkeslæt, til et datetime-felt. Funktioner som todatetime og tohex er nyttige i disse tilfælde.

Det oprindelige entydige hændelses-id kan f.eks. sendes som et heltal, men ASIM kræver, at værdien er en streng for at sikre bred kompatibilitet mellem datakilder. Når du tildeler brug extend af kildefeltet og tostring i stedet for project-rename:

  | extend EventOriginalUid = tostring(ReportId),

Afledte felter og værdier

Når kildefeltet er udtrukket, skal værdien muligvis knyttes til det værdisæt, der er angivet for destinationsskemafeltet. Funktionerne iff, caseog lookup kan være nyttige til at knytte tilgængelige data til målværdier.

Microsoft DNS-fortolkeren tildeler f.eks. feltet baseret på hændelses-id'et EventResult og svarkoden ved hjælp af en iff sætning på følgende måde:

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

Hvis du vil tilknytte flere værdier, skal du definere tilknytningen ved hjælp af operatoren datatable og bruge lookup til at udføre tilknytningen. Nogle kilder rapporterer f.eks. numeriske DNS-svarkoder og netværksprotokollen, mens skemaet giver den mere almindelige repræsentation af tekstmærkater for begge. I følgende eksempel vises, hvordan du kan udlede de nødvendige værdier ved hjælp af 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

Bemærk, at opslag er nyttigt og effektivt, også når tilknytningen kun indeholder to mulige værdier.

Når tilknytningsbetingelserne er mere komplekse, skal du kombinere iff, caseog lookup. I nedenstående eksempel kan du se, hvordan du kombinerer lookup og case. Ovenstående lookup eksempel returnerer en tom værdi i feltet DnsResponseCodeName , hvis opslagsværdien ikke blev fundet. I case eksemplet nedenfor tilføjes den ved hjælp af resultatet af handlingen, hvis den lookup er tilgængelig, og ellers angives yderligere betingelser.

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

Microsoft Sentinel indeholder praktiske funktioner til almindelige opslagsværdier. Opslaget DnsResponseCodeName ovenfor kan f.eks. implementeres ved hjælp af en af følgende funktioner:

| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

Den første indstilling accepterer som en parameter den værdi, der skal søges efter, og lader dig vælge outputfeltet og er derfor nyttigt som en generel opslagsfunktion. Den anden indstilling er mere gearet mod fortolkere, tager navnet på kildefeltet som input og opdaterer det nødvendige ASIM-felt i dette tilfælde DnsResponseCodeName.

Du kan finde en komplet liste over HJÆLPEfunktioner til ASIM i ASIM-funktioner

Berigelsesfelter

Ud over de felter, der er tilgængelige fra kilden, indeholder en deraf følgende ASIM-hændelse berigelsesfelter, som parseren skal generere. I mange tilfælde kan fortolkerne tildele en konstant værdi til felterne, f.eks.:

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

En anden type berigelsesfelter, som dine fortolkere skal angive, er typefelter, som angiver typen af den værdi, der er gemt i et relateret felt. Feltet angiver f.eks. den type værdi, SrcUsernameType der er gemt i feltet SrcUsername . Du kan finde flere oplysninger om typefelter i objektbeskrivelsen.

I de fleste tilfælde tildeles typer også en konstant værdi. I nogle tilfælde skal typen dog bestemmes ud fra den faktiske værdi, f.eks.:

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

Microsoft Sentinel indeholder nyttige funktioner til håndtering af berigelse. Brug f.eks. følgende funktion til automatisk at tildele felterne SrcHostname, SrcDomainSrcDomainType og SrcFQDN på baggrund af værdien i feltet Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Denne funktion angiver felterne på følgende måde:

_ASIM_ResolveDstFQDN Funktionerne og _ASIM_ResolveDvcFQDN udfører en lignende opgave ved at udfylde de relaterede Dst felter og Dvc . Du kan finde en komplet liste over HJÆLPEfunktioner til ASIM i ASIM-funktioner

Vælg felter i resultatsættet

Fortolkeren kan vælge felter i resultatsættet. Hvis du fjerner unødvendige felter, kan det forbedre ydeevnen og skabe klarhed ved at undgå forvirring mellem normaliserede felter og resterende kildefelter.

Følgende KQL-operatorer bruges til at vælge felter i resultatsættet:

Når du f.eks. fortolker en brugerdefineret logtabel, skal du bruge følgende til at fjerne de resterende oprindelige felter, der stadig har en typebeskrivelse:

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

Håndter fortolkningsvarianter

I mange tilfælde omfatter hændelser i en hændelsesstrøm varianter, der kræver anden fortolkningslogik. Hvis du vil fortolke forskellige varianter i en enkelt parser, skal du enten bruge betingede sætninger som iff og caseeller bruge en foreningsstruktur.

Hvis du vil bruge union til at håndtere flere varianter, skal du oprette en separat funktion for hver variant og bruge foreningssætningen til at kombinere resultaterne:

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 undgå dublethændelser og overdreven behandling, skal du sørge for, at hver funktion starter med at filtrere ved hjælp af oprindelige felter og kun de hændelser, den er beregnet til at fortolke. Hvis det er nødvendigt, skal du også bruge projekt uden for hver gren før foreningen.

Udrul fortolkere

Udrul fortolkere manuelt ved at kopiere dem til siden Azure Overvåg log og gemme forespørgslen som en funktion. Denne metode er nyttig til test. Du kan få flere oplysninger under Opret en funktion.

Hvis du vil udrulle et stort antal fortolkere, anbefaler vi, at du bruger parser-ARM-skabeloner på følgende måde:

1. Opret en YAML-fil baseret på den relevante skabelon for hvert skema, og medtag din forespørgsel i den. Start med den YAML-skabelon , der er relevant for din skema- og parsertype, filtrering eller parameter-less.

2. Brug ASIM YAML til ARM-skabelonkonverteringsprogrammet til at konvertere YAML-filen til en ARM-skabelon.

3. Hvis du installerer en opdatering, skal du slette ældre versioner af funktionerne ved hjælp af portalen eller funktionen slet PowerShell-værktøjet.

4. Udrul skabelonen ved hjælp af Azure Portal eller PowerShell.

Du kan også kombinere flere skabeloner til en enkelt installationsproces ved hjælp af sammenkædede skabeloner

Testparsers

I dette afsnit beskrives det, at testværktøjer som ASIM giver dig mulighed for at teste dine fortolkninger. Når det er sagt, er fortolkere kode, nogle gange komplekse, og standardpraksis for kvalitetssikring, f.eks. kodegennemgange, anbefales ud over automatiseret test.

Installér ASIM-testværktøjer

Hvis du vil teste ASIM, skal du installere ASIM-testværktøjet i et Microsoft Sentinel arbejdsområde, hvor:

• Din parser er installeret.
• Den kildetabel, der bruges af fortolkeren, er tilgængelig.
• Den kildetabel, der bruges af fortolkeren, udfyldes med en varieret samling af relevante hændelser.

Valider outputskemaet

Hvis du vil sikre dig, at fortolkeren opretter et gyldigt skema, skal du bruge ASIM-skematesteren ved at køre følgende forespørgsel på siden Microsoft Sentinel Logfiler:

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

Håndter resultaterne på følgende måde:

Valider outputværdierne

Hvis du vil sikre dig, at fortolkeren producerer gyldige værdier, skal du bruge ASIM-datatesteren ved at køre følgende forespørgsel på siden Microsoft Sentinel Logfiler:

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

Det er valgfrit at angive et skema. Hvis der ikke er angivet et skema, bruges feltet EventSchema til at identificere det skema, hændelsen skal overholde. Hvis en hændelse ikke indeholder et EventSchema felt, er det kun almindelige felter, der bekræftes. Hvis der er angivet et skema som en parameter, bruges dette skema til at teste alle poster. Dette er nyttigt for ældre fortolkere, der ikke angiver feltet EventSchema .

Denne test er ressourcekrævende og fungerer muligvis ikke på hele dit datasæt. Angiv X til det største tal, som forespørgslen ikke får timeout for, eller angiv tidsinterval for forespørgslen ved hjælp af tidsintervalvælgeren.

Håndter resultaterne på følgende måde:

Mange af meddelelserne rapporterer også antallet af poster, der genererede meddelelsen, og deres procentdel af det samlede eksempel. Denne procentdel er en god indikator for problemets betydning. For et anbefalet felt:

• 90 % tomme værdier kan indikere et generelt problem med fortolkning.
• 25 % tomme værdier kan angive en hændelsesvariant, der ikke blev fortolket korrekt.
• En håndfuld tomme værdier kan være et ubetydeligt problem.

Bidrag med fortolkninger

Det kan være en god idé at bidrage med fortolkeren til den primære ASIM-distribution. Hvis de accepteres, vil fortolkerne være tilgængelige for alle kunder som indbyggede ASIM-fortolkere.

Sådan bidrager du med dine fortolkninger:

• Udvikl både en filtreringsparser og en parameterfri parser.
• Opret en YAML-fil til fortolkeren som beskrevet i Deploying Parsers ovenfor.
• Sørg for, at dine fortolkere passerer alle test uden fejl. Hvis der er nogen advarsler tilbage, skal du dokumentere dem i PARSER YAML-filen.
• Opret en pullanmodning i forhold til Microsoft Sentinel GitHub-lageret, herunder:
  • Dine YAML-fortolkere i ASIM-parsermapperne (/Parsers/ASim<schema>/Parsers)
  • Repræsentative eksempeldata i henhold til retningslinjerne for indsendelse af eksempler.
  • Testresultater i henhold til retningslinjerne for indsendelse af testresultater.

Dokumentation af accepterede advarsler

Hvis advarsler, der er angivet af ASIM-testværktøjerne, anses for at være gyldige for en parser, skal du dokumentere de accepterede advarsler i yaml-parserfilen ved hjælp af afsnittet Undtagelser som vist i nedenstående eksempel.

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

Advarslen, der er angivet i YAML-filen, skal være en kort form for advarselsmeddelelsen, der entydigt identificeres. Værdien bruges til at matche advarselsmeddelelser, når der udføres automatiserede test, og ignorerer dem.

Retningslinjer for indsendelse af eksempler

Eksempeldata er nødvendige ved fejlfinding af parserproblemer og for at sikre, at fremtidige opdateringer af fortolkeren er i overensstemmelse med ældre eksempler. De eksempler, du sender, skal indeholde en hvilken som helst hændelsesvariant, som fortolkeren understøtter. Sørg for, at eksempelhændelserne omfatter alle mulige hændelsestyper, hændelsesformater og variationer, f.eks. hændelser, der repræsenterer vellykket og mislykket aktivitet. Sørg også for, at variationer i værdiformater er repræsenteret. Hvis et værtsnavn f.eks. kan repræsenteres som et FQDN eller et simpelt værtsnavn, skal eksempelhændelserne indeholde begge formater.

Hvis du vil sende hændelseseksempler, skal du følge disse trin:

• Logs Kør en forespørgsel på skærmen, der kun udtrækker de hændelser, der er valgt af fortolkeren, fra kildetabellen. For Infoblox DNS-fortolkeren skal du f.eks. bruge følgende forespørgsel:

    Syslog
    | where ProcessName == "named"

• Eksportér resultaterne ved hjælp af indstillingen Eksportér til CSV til en fil med navnet <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, Hvor EventProduct, EventProductog EventSchema er de værdier, der er tildelt disse felter af fortolkeren.

• Logs Kør en forespørgsel på skærmen, der skriver skemaet eller parserinputtabellen. For den samme Infoblox DNS-parser er forespørgslen f.eks.:

    Syslog
    | getschema

• Eksportér resultaterne ved hjælp af indstillingen Eksportér til CSV til en fil med navnet <TableName>_schema.csv, hvor TableName er navnet på den kildetabel, fortolkeren bruger.

• Medtag begge filer i pullanmodningen i mappen /Sample Data/ASIM. Hvis filen allerede findes, skal du føje dit GitHub-håndtag til navnet, f.eks.: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Retningslinjer for indsendelse af testresultater

Testresultater er vigtige for at bekræfte korrektheden af fortolkeren og forstå eventuelle rapporterede undtagelser.

Hvis du vil indsende dine testresultater, skal du bruge følgende trin:

• Kør parsertestene og beskrevet i afsnittet test .

• og eksportér testresultaterne ved hjælp af indstillingen Eksportér til CSV til henholdsvis navngivne <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv<EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv filer.

• Medtag begge filer i pullanmodningen i mappen /Parsers/ASim<schema>/Tests.

Næste trin

I denne artikel beskrives udvikling af ASIM-fortolkere.

Få mere at vide om ASIM-fortolkere:

• Oversigt over ASIM-fortolkninger
• Brug ASIM-fortolkninger
• Administrer ASIM-fortolkninger
• Listen over ASIM-fortolkninger

Få mere at vide om ASIM generelt:

• Se webinaret med detaljeret gennemgang på Microsoft Sentinel normalisere fortolkere og normaliseret indhold, eller gennemse slidene
• Oversigt over ASIM (Advanced Security Information Model)
• ASIM-skemaer (Advanced Security Information Model)
• Asim-indhold (Advanced Security Information Model)