Inhoud wijzigen om het Advanced Security Information Model (ASIM) te gebruiken

Genormaliseerde beveiligingsinhoud in Microsoft Sentinel bevat analyseregels, opsporingsquery's en werkmappen die werken met samenvoegende normalisatieparsers.

U kunt genormaliseerde, out-of-the-box-inhoud vinden in Microsoft Sentinel galerieën en Microsoft Sentinel oplossingencatalogus, uw eigen genormaliseerde inhoud maken of bestaande, aangepaste inhoud wijzigen om genormaliseerde gegevens te gebruiken.

In dit artikel wordt uitgelegd hoe u bestaande Microsoft Sentinel analyseregels converteert om genormaliseerde ASIM-gegevens te gebruiken met het Advanced Security Information Model (ASIM).

Raadpleeg het diagram ASIM-architectuur om te begrijpen hoe genormaliseerde inhoud binnen de ASIM-architectuur past.

Aangepaste inhoud wijzigen om normalisatie te gebruiken

Ga als volgt te werk om uw aangepaste Microsoft Sentinel-inhoud normalisatie te laten gebruiken:

Voorbeeldnormalisatie voor analyseregels

Denk bijvoorbeeld aan de DNS-analyseregel Zeldzame client waargenomen met een hoog aantal reverse DNS-lookups, die werkt op basis van DNS-gebeurtenissen die door Infoblox DNS-servers worden verzonden:

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

De volgende code is de bron-agnostische versie, die gebruikmaakt van normalisatie om dezelfde detectie te bieden voor elke bron die DNS-querygebeurtenissen levert. In het volgende voorbeeld worden ingebouwde ASIM-parsers gebruikt:

_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

De genormaliseerde, bron-agnostische versie heeft de volgende verschillen:

  • De _Im_Dns of imDnsgenormaliseerde parsers worden gebruikt in plaats van de Infoblox-parser.

  • De genormaliseerde parsers halen alleen DNS-querygebeurtenissen op, dus het is niet nodig om het gebeurtenistype te controleren, zoals uitgevoerd door de where ProcessName =~ "named" and Log_Type =~ "client" in de Infoblox-versie.

  • Het SrcIpAddr veld wordt gebruikt in plaats van Client_IP.

  • Parser parameter filtering wordt gebruikt voor ResponseCodeName, waardoor er geen expliciete where componenten nodig zijn.

Opmerking

Afgezien van het ondersteunen van een genormaliseerde DNS-bron, is de genormaliseerde versie korter en gemakkelijker te begrijpen.

Als het schema of de parsers geen filterparameters ondersteunen, zijn de querywijzigingen die nodig zijn om de regel te normaliseren vergelijkbaar, behalve dat de filtervoorwaarden van de oorspronkelijke query worden bewaard. Bijvoorbeeld:

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

Zie meer informatie over de volgende KQL-elementen die worden gebruikt in de voorbeelden van dns-querynormalisatie in de Kusto-documentatie:

Zie overzicht van Kusto-querytaal (KQL) voor meer informatie over KQL.

Andere bronnen:

Verwante onderwerpen

Zie de volgende bronnen voor meer informatie:

  • Last updated on