Modyfikowanie zawartości w celu korzystania z zaawansowanego modelu informacji o zabezpieczeniach (ASIM)

Konwertowanie treści Microsoft Sentinel na wykorzystanie danych ASIM znormalizowanych

Znormalizowana zawartość dotycząca zabezpieczeń w usłudze Microsoft Sentinel obejmuje reguły analityczne, zapytania do wyszukiwania zagrożeń oraz skoroszyty, które współpracują z parserami ujednolicającej normalizacji.

Możesz znaleźć znormalizowaną, gotową do użycia zawartość w galeriach Microsoft Sentinel i katalogu rozwiązań Microsoft Sentinel, utworzyć własną znormalizowaną zawartość lub zmodyfikować istniejącą zawartość niestandardową, aby korzystać ze znormalizowanych danych.

W tym artykule wyjaśniono, jak przekształcić istniejące reguły analityczne Microsoft Sentinel tak, aby używały danych znormalizowanych zgodnie z modelem ASIM przy użyciu modelu Advanced Security Information Model (ASIM).

Aby zrozumieć, jak znormalizowana zawartość mieści się w architekturze ASIM, zapoznaj się z diagramem architektury ASIM.

Modyfikowanie zawartości niestandardowej w celu korzystania z normalizacji

Aby umożliwić niestandardowym treściom Microsoft Sentinel korzystanie z normalizacji:

Przykładowa normalizacja reguł analizy

Rozważmy na przykład regułę analityczną DNS Rzadki klient zaobserwowany przy wysokiej liczbie odwrotnych zapytań DNS, która działa w oparciu o zdarzenia DNS wysyłane przez serwery DNS Infoblox:

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

Poniższy kod to wersja niezależne od źródła, która używa normalizacji w celu zapewnienia tego samego wykrywania dla dowolnego źródła dostarczającego zdarzenia zapytania DNS. W poniższym przykładzie użyto wbudowanych analizatorów ASIM:

_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

Znormalizowana wersja, niezależna od źródła, ma następujące różnice:

  • Analizatory _Im_Dns lub imDnsznormalizowane są używane zamiast analizatora Infoblox.

  • Znormalizowane analizatory pobierają tylko zdarzenia zapytań DNS, więc nie ma potrzeby sprawdzania typu zdarzenia, zgodnie z poleceniem where ProcessName =~ "named" and Log_Type =~ "client" w wersji Infoblox.

  • Pole SrcIpAddr jest używane zamiast Client_IP.

  • Filtrowanie parametrów analizatora jest używane dla parametru ResponseCodeName, eliminując konieczność stosowania jawnych where klauzul.

Uwaga

Oprócz obsługi znormalizowanego źródła DNS znormalizowana wersja jest krótsza i łatwiejsza do zrozumienia.

Jeśli schemat lub analizatory nie obsługują parametrów filtrowania, zmiany zapytania potrzebne do normalizacji reguły są podobne, z tą różnicą, że warunki filtrowania są przechowywane z oryginalnego zapytania. Przykład:

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

Więcej informacji na temat następujących elementów języka KQL używanych w przykładach normalizacji zapytań DNS można znaleźć w dokumentacji usługi Kusto:

Aby uzyskać więcej informacji na temat języka KQL, zobacz omówienie języka zapytań Kusto (KQL).

Inne zasoby:

Zawartość pokrewna

Aby uzyskać więcej informacji, zobacz następujące zasoby:

  • Last updated on