Rediger indhold for at bruge ASIM (Advanced Security Information Model)

Normaliseret sikkerhedsindhold i Microsoft Sentinel omfatter analyseregler, jagtforespørgsler og projektmapper, der fungerer sammen med samlende normaliseringsparsere.

Du kan finde normaliseret, køreklart indhold i Microsoft Sentinel gallerier og løsninger, oprette dit eget normaliserede indhold eller redigere eksisterende brugerdefineret indhold for at bruge normaliserede data.

I denne artikel forklares det, hvordan du konverterer eksisterende Microsoft Sentinel analyseregler til at bruge normaliserede data med ASIM (Advanced Security Information Model).

Hvis du vil vide, hvordan normaliseret indhold passer inden for ASIM-arkitekturen, skal du se ASIM-arkitekturdiagrammet.

Rediger brugerdefineret indhold, så det bruger normalisering

Sådan gør du det muligt for dit brugerdefinerede Microsoft Sentinel indhold at bruge normalisering:

  • Rediger dine forespørgsler, så de bruger de forenende fortolkninger, der er relevante for forespørgslen.

  • Rediger feltnavnene i forespørgslen, så de bruger de normaliserede skemafeltnavne .

  • Når det er relevant, skal du ændre betingelserne for at bruge de normaliserede værdier for felterne i forespørgslen.

Eksempel på normalisering for analyseregler

Overvej f.eks. den sjældne klient, der blev observeret med stort omvendt DNS-opslagsantal FOR DNS-analyseregel, som fungerer på DNS-hændelser, der sendes af Infoblox DNS-servere:

let threshold = 200;
InfobloxNIOS
| where ProcessName =~ "named" and Log_Type =~ "client"
| where isnotempty(ResponseCode)
| where ResponseCode =~ "NXDOMAIN"
| summarize count() by Client_IP, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (InfobloxNIOS
    | where ProcessName =~ "named" and Log_Type =~ "client"
    | where isnotempty(ResponseCode)
    | where ResponseCode =~ "NXDOMAIN"
    ) on Client_IP
| extend timestamp = TimeGenerated, IPCustomEntity = Client_IP

Følgende kode er den kildeagnostiske version, som bruger normalisering til at levere den samme registrering for alle kilder, der leverer DNS-forespørgselshændelser. I følgende eksempel bruges indbyggede ASIM-fortolkninger:

_Im_Dns(responsecodename='NXDOMAIN')
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns(responsecodename='NXDOMAIN')) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Den normaliserede kildeagnostiske version har følgende forskelle:

  • De _Im_Dns eller imDnsnormaliserede fortolkere bruges i stedet for Infoblox Parser.

  • De normaliserede fortolkere henter kun DNS-forespørgselshændelser, så det er ikke nødvendigt at kontrollere hændelsestypen, som udført af where ProcessName =~ "named" and Log_Type =~ "client" i Infoblox-versionen.

  • Feltet SrcIpAddr bruges i stedet for Client_IP.

  • Parser-parameterfiltrering bruges til ResponseCodeName, hvilket fjerner behovet for eksplicitte where delsætninger.

Bemærk!

Ud over at understøtte en normaliseret DNS-kilde er den normaliserede version kortere og nemmere at forstå.

Hvis skemaet eller fortolkerne ikke understøtter filtreringsparametre, er ændringerne de samme, bortset fra at filtreringsbetingelserne holdes fra den oprindelige forespørgsel. Det kan f.eks. være:

let threshold = 200;
imDns
| where isnotempty(ResponseCodeName)
| where ResponseCodeName =~ "NXDOMAIN"
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns
    | where isnotempty(ResponseCodeName)
    | where ResponseCodeName =~ "NXDOMAIN"
    ) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Du kan få flere oplysninger om følgende elementer, der bruges i de foregående eksempler, i dokumentationen til Kusto:

Du kan få flere oplysninger om KQL i oversigten over Kusto Query Language (KQL).

Andre ressourcer:

Næste trin

I denne artikel beskrives ASIM-indholdet (Advanced Security Information Model).

Du kan finde flere oplysninger under: