Ändra innehåll för att använda Advanced Security Information Model (ASIM)

Normaliserat säkerhetsinnehåll i Microsoft Sentinel innehåller analysregler, jaktfrågor och arbetsböcker som fungerar med enhetlig normaliseringsparsrar.

Du kan hitta normaliserat, inbyggt innehåll i Microsoft Sentinel gallerier och lösningar, skapa ditt eget normaliserade innehåll eller ändra befintligt anpassat innehåll så att normaliserade data används.

Den här artikeln beskriver hur du konverterar befintliga Microsoft Sentinel analysregler för att använda normaliserade data med ASIM (Advanced Security Information Model).

Information om hur normaliserat innehåll passar in i ASIM-arkitekturen finns i ASIM-arkitekturdiagrammet.

Tips

Titta också på webbseminariet för djupdykning på Microsoft Sentinel Normalisera parsrar och normaliserat innehåll eller granska bilderna. Mer information finns i Nästa steg.

Ändra anpassat innehåll så att det använder normalisering

Så här gör du så att ditt anpassade Microsoft Sentinel innehåll kan använda normalisering:

Exempelnormalisering för analysregler

Anta till exempel att rare-klienten observerats med hög omvänd DNS-uppslagsregel för DNS-analys, som fungerar på DNS-händelser som skickas av Infoblox DNS-servrar:

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öljande kod är den källagnostiska versionen, som använder normalisering för att tillhandahålla samma identifiering för alla källor som tillhandahåller DNS-frågehändelser. I följande exempel används inbyggda ASIM-parsers:

_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 normaliserade, källagnostiska versionen har följande skillnader:

  • De _Im_Dns eller imDnsnormaliserade parsarna används i stället för Infoblox-parsern.

  • De normaliserade parsarna hämtar endast DNS-frågehändelser, så det finns inget behov av att kontrollera händelsetypen, som utförs av where ProcessName =~ "named" and Log_Type =~ "client" i Infoblox-versionen.

  • Fältet SrcIpAddr används i stället för Client_IP.

  • Parserparameterfiltrering används för ResponseCodeName, vilket eliminerar behovet av explicita where satser.

Obs!

Förutom att stödja en normaliserad DNS-källa är den normaliserade versionen kortare och lättare att förstå.

Om schemat eller parsarna inte stöder filtreringsparametrar är ändringarna liknande, förutom att filtreringsvillkoren sparas från den ursprungliga frågan. Till exempel:

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

Mer information om följande objekt som används i föregående exempel finns i Kusto-dokumentationen:

Mer information om KQL finns i översikten över Kusto-frågespråk (KQL).

Andra resurser:

Nästa steg

Den här artikeln beskriver innehållet i ASIM (Advanced Security Information Model).

Mer information finns i:

  • Last updated on