ASIM-skjemaer (Advanced Security Information Model)

Et ASIM-skjema (Advanced Security Information Model) er et sett med felt som representerer en aktivitet eller enhet. Bruk av feltene fra et normalisert skjema i en spørring sikrer at spørringen fungerer med alle normaliserte kilder.

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

Aktivitets-/hendelsesskjemaer

Skjemareferanser beskriver feltene som utgjør hvert skjema. ASIM definerer for øyeblikket følgende skjemaer for hendelser:

Enhetsskjemaer

ASIM definerer for øyeblikket følgende skjemaer for enheter:

For enheter som er en del av andre ASIM-skjemaer, kan du se Hendelsesenheter.

Feltnavn

Kjernen i hvert skjema er feltnavnene. Feltnavn tilhører følgende grupper:

• Felt som er felles for alle skjemaer.
• Felt som er spesifikke for et skjema.
• Felt som representerer enheter, for eksempel brukere, som deltar i skjemaet. Felt som representerer enheter , er like på tvers av skjemaer.

Når kilder har felt som ikke vises i det dokumenterte skjemaet, normaliseres de for å opprettholde konsekvens. Hvis de ekstra feltene representerer en enhet, normaliseres de basert på retningslinjene for enhetsfeltet. Ellers forsøker skjemaene å holde konsekvens på tvers av alle skjemaer.

Selv om for eksempel dns-serveraktivitetslogger ikke gir brukerinformasjon, kan DNS-aktivitetslogger fra et endepunkt inneholde brukerinformasjon, som kan normaliseres i henhold til retningslinjene for brukerenheten.

Vanlige felt

Noen felt er felles for alle ASIM-skjemaer. Hvert skjema kan legge til retningslinjer for bruk av noen av fellesfeltene i konteksten til det bestemte skjemaet. Tillatte verdier for EventType-feltet kan for eksempel variere per skjema, i likhet med verdien i EventSchemaVersion-feltet .

Feltklasser

Felt kan ha flere klasser, som definerer når feltene skal implementeres av en analyse:

• Obligatoriske felt må vises i hver parser. Hvis kilden ikke oppgir informasjon for denne verdien, eller hvis ikke dataene kan legges til, støttes ikke de fleste innholdselementene som refererer til det normaliserte skjemaet.
• Anbefalte felt bør normaliseres hvis tilgjengelige. Det kan imidlertid hende at de ikke er tilgjengelige i alle kilder. Alle innholdselementer som refererer til det normaliserte skjemaet, bør ta hensyn til tilgjengelighet.
• Valgfrie felt, hvis de er tilgjengelige, kan normaliseres eller beholdes i sin opprinnelige form. Vanligvis ville ikke en minimal analyse normalisere dem av ytelsesårsaker.
• Betingede felt er obligatoriske hvis feltet de følger er fylt ut. Betingede felt brukes vanligvis til å beskrive verdien i et annet felt. For eksempel beskriver fellesfeltet DvcIdType verdien i fellesfeltet DvcId og er derfor obligatorisk hvis sistnevnte fylles ut.
• Alias er en spesiell type for et betinget felt, og er obligatorisk hvis aliasfeltet fylles ut.

Hendelsesenheter

Hendelser utvikler seg rundt enheter, for eksempel brukere, verter, prosesser eller filer. Hver enhet kan kreve flere felt for å beskrive den. En vert kan for eksempel ha et navn og en IP-adresse.

Én enkelt post kan inneholde flere enheter av samme type, for eksempel både en kilde- og målvert.

ASIM definerer hvordan du beskriver enheter konsekvent, og enheter tillater utvidelse av skjemaene.

Selv om for eksempel nettverksøktskjemaet ikke inneholder prosessinformasjon, gir noen hendelseskilder prosessinformasjon som kan legges til. Hvis du vil ha mer informasjon, kan du se Enheter.

For å aktivere enhetsfunksjonalitet har enhetsrepresentasjon følgende retningslinjer:

Hvis du vil ha mer informasjon om bestemte enhetstyper, kan du se:

• Brukerenhet
• Enhetsenhet
• Programenhet

Hvis du vil ha mer informasjon om fullstendige enhetsskjemaer, kan du se:

• Skjema for aktivaenhet

Aliaser

Aliaser tillater flere navn for en angitt verdi. I noen tilfeller forventer forskjellige brukere at et felt har forskjellige navn. I DNS-terminologi kan du for eksempel forvente et felt kalt DnsQuery, mens det generelt sett inneholder et domenenavn. Aliasdomenet hjelper brukeren ved å tillate bruk av begge navnene.

I noen tilfeller kan et alias ha verdien til ett av flere felt, avhengig av hvilke verdier som er tilgjengelige i hendelsen. Dvc-aliaset, aliasene enten DvcFQDN-, DvcId-, DvcHostname- eller DvcIpAddr- eller Event Product-feltene. Når et alias kan ha flere verdier, må typen være en streng for å få plass til alle mulige aliasverdier. Som et resultat, når du tilordner en verdi til et slikt alias, må du sørge for å konvertere typen til streng ved hjelp av KQL-funksjonen tilstrenging.

Opprinnelige normaliserte tabeller inkluderer ikke aliaser, da de innebærer duplisert datalagring. I stedet legger stub-parserne til aliasene. Hvis du vil implementere aliaser i analyser, oppretter du en kopi av den opprinnelige verdien ved hjelp av operatoren extend .

Logiske typer

Hvert skjemafelt har en type. Log Analytics-arbeidsområdet har et begrenset sett med datatyper. Derfor bruker Microsoft Sentinel en logisk type for mange skjemafelt, som Log Analytics ikke fremtvinger, men som kreves for skjemakompatibilitet. Logiske felttyper sikrer at både verdier og feltnavn er konsekvente på tvers av kilder.

Eksempel på enhetstilordning

Denne delen bruker Windows-hendelsen 4624 som et eksempel for å beskrive hvordan hendelsesdataene normaliseres for Microsoft Sentinel.

Denne hendelsen har følgende enheter:

Basert på disse enhetene normaliseres Windows-hendelse 4624 som følger (noen felt er valgfrie):

Neste trinn

Denne artikkelen gir en oversikt over normalisering i Microsoft Sentinel og ASIM.

Hvis du vil ha mer informasjon, kan du se:

• Se deep dive-nettseminaret på Microsoft Sentinel normalisere analyser og normalisert innhold, eller se gjennom lysbildene
• Oversikt over Advanced Security Information Model (ASIM)
• ASIM-analyser (Advanced Security Information Model)
• ASIM-innhold (Advanced Security Information Model)