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

Konvertera Microsoft Sentinel-innehåll för att använda ASIM-normaliserad data

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

Du kan hitta normaliserat, out-of-the-box-innehåll i Microsoft Sentinel gallerier och Microsoft Sentinel lösningskatalog, skapa ditt eget normaliserade innehåll eller ändra befintligt anpassat innehåll för att använda normaliserade data.

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

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

Ä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

Ta till exempel DNS-analysregeln Klienten Rare observerades med ett högt antal omvända DNS-uppslagningar, som fungerar på DNS-händelser som skickas från 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 de frågeändringar som krävs för att normalisera regeln 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 KQL-element som används i DNS-frågenormaliseringsexemplen finns i Kusto-dokumentationen:

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

Andra resurser:

Relaterat innehåll

Mer information finns i följande resurser:

  • Last updated on