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

Znormalizowana zawartość zabezpieczeń w Microsoft Sentinel obejmuje reguły analizy, zapytania wyszukiwania zagrożeń i skoroszyty, które współpracują z analizatorami normalizacji ujednolicenia.

Znormalizowane, wbudowane treści można znaleźć w Microsoft Sentinel galeriach i rozwiązaniach, utworzyć własną znormalizowana zawartość lub zmodyfikować istniejącą zawartość niestandardową w celu użycia znormalizowanych danych.

W tym artykule wyjaśniono, jak przekonwertować istniejące reguły analizy Microsoft Sentinel w celu używania znormalizowanych danych za pomocą modelu ASIM (Advanced Security Information Model).

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 włączyć niestandardową zawartość Microsoft Sentinel do korzystania z normalizacji:

Przykładowa normalizacja reguł analizy

Rozważmy na przykład rzadki klient obserwowany z wysoką odwrotną regułą analityczną DNS z liczbą odnośników DNS , która działa na zdarzeniach DNS wysyłanych 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, niezależny od źródła wersja 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 są podobne, z tą różnicą, że warunki filtrowania są przechowywane w oryginalnym zapytaniu. 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 użytych w powyższych przykładach można znaleźć w dokumentacji usługi Kusto:

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

Inne zasoby:

Zawartość pokrewna

  • Last updated on