Dokumentacja schematu normalizacji DNS w modelu zaawansowanego zabezpieczeń zabezpieczeń (ASIM)

Model informacji DNS służy do opisywania zdarzeń zgłaszanych przez serwer DNS lub system zabezpieczeń DNS i jest używany przez usługę Microsoft Sentinel do włączania analizy niezależnej od źródła.

Aby uzyskać więcej informacji, zobacz Normalizacja i Model zaawansowanych informacji o zabezpieczeniach (ASIM) .

Przegląd schematu

Schemat DNS ASIM reprezentuje działanie protokołu DNS. Zarówno serwery DNS, jak i urządzenia wysyłające żądania DNS do aktywności DNS dziennika serwera DNS. Działanie protokołu DNS obejmuje zapytania DNS, aktualizacje serwera DNS i zbiorcze transfery danych DNS. Ponieważ schemat reprezentuje działanie protokołu, jest on zarządzany przez RFC i oficjalnie przypisane listy parametrów, które są przywołyane w tym artykule, jeśli jest to konieczne. Schemat DNS nie reprezentuje zdarzeń inspekcji serwera DNS.

Najważniejszym działaniem zgłaszanym przez serwery DNS jest zapytanie DNS, dla którego EventType pole jest ustawione na Querywartość .

Najważniejsze pola w zdarzeniu DNS to:

• DnsQuery, który zgłasza nazwę domeny, dla której zostało wystawione zapytanie.

• SrcIpAddr (aliased to IpAddr), który reprezentuje adres IP, z którego wygenerowano żądanie. Serwery DNS zazwyczaj udostępniają pole SrcIpAddr, ale klienci DNS czasami nie udostępniają tego pola i udostępniają tylko pole SrcHostname .

• EventResultDetails, który zgłasza, czy żądanie zakończyło się pomyślnie, a jeśli nie, dlaczego.

• Jeśli jest dostępna, DnsResponseName, która przechowuje odpowiedź dostarczoną przez serwer do zapytania. Usługa ASIM nie wymaga analizowania odpowiedzi, a jego format różni się między źródłami.

  Aby użyć tego pola w zawartości niezależnej od źródła, wyszukaj zawartość za has pomocą operatorów lub contains .

Zdarzenia DNS zebrane na urządzeniu klienckim mogą również zawierać informacje o użytkowniku i procesie .

Wskazówki dotyczące zbierania zdarzeń DNS

DNS jest unikatowym protokołem, który może przekraczać dużą liczbę komputerów. Ponadto, ponieważ usługa DNS używa protokołu UDP, żądania i odpowiedzi są de-sprzężone i nie są bezpośrednio powiązane ze sobą.

Na poniższej ilustracji przedstawiono uproszczony przepływ żądań DNS, w tym cztery segmenty. Rzeczywiste żądanie może być bardziej złożone, przy użyciu większej liczby segmentów.

Ponieważ segmenty żądań i odpowiedzi nie są bezpośrednio połączone ze sobą w przepływie żądań DNS, pełne rejestrowanie może spowodować znaczne duplikowanie.

Najbardziej cenną segmentem do zarejestrowania jest odpowiedź na klienta. Odpowiedź zawiera zapytania o nazwę domeny, wynik wyszukiwania i adres IP klienta. Chociaż wiele systemów DNS rejestruje tylko ten segment, istnieje wartość rejestrowania innych części. Na przykład atak zatrucia pamięcią podręczną DNS często wykorzystuje fałszywe odpowiedzi z nadrzędnego serwera.

Jeśli źródło danych obsługuje pełne rejestrowanie DNS i wybrano rejestrowanie wielu segmentów, dostosuj zapytania, aby zapobiec duplikowaniu danych w usłudze Microsoft Sentinel.

Możesz na przykład zmodyfikować zapytanie przy użyciu następującej normalizacji:

_Im_Dns | where SrcIpAddr != "127.0.0.1" and EventSubType == "response"

Parsery

Aby uzyskać więcej informacji na temat analizatorów ASIM, zobacz omówienie analizatorów ASIM.

Analizatory gotowe do użycia

Aby użyć analizatorów, które ujednolicają wszystkie gotowe analizatory ASIM i upewnij się, że analiza jest uruchamiana we wszystkich skonfigurowanych źródłach, użyj analizatora jednofikującego _Im_Dns jako nazwy tabeli w zapytaniu.

Aby uzyskać listę analizatorów DNS, usługa Microsoft Sentinel udostępnia gotowe do użycia, zapoznaj się z listą analizatorów ASIM.

Dodawanie własnych znormalizowanych analizatorów

Podczas implementowania niestandardowych analizatorów dla modelu informacji DNS nazwij funkcje KQL przy użyciu formatu vimDns<vendor><Product>. Zapoznaj się z artykułem Zarządzanie analizatorami ASIM, aby dowiedzieć się, jak dodać analizatory niestandardowe do analizatora ujednolicania DNS.

Parametry analizatora filtrowania

Analizatory DNS obsługują parametry filtrowania. Chociaż te parametry są opcjonalne, mogą zwiększyć wydajność zapytań.

Dostępne są następujące parametry filtrowania:

Aby na przykład filtrować tylko zapytania DNS z ostatniego dnia, którego nie udało się rozpoznać nazwy domeny, użyj:

_Im_Dns (responsecodename = 'NXDOMAIN', starttime = ago(1d), endtime=now())

Aby filtrować tylko zapytania DNS dla określonej listy nazw domen, użyj:

let torProxies=dynamic(["tor2web.org", "tor2web.com", "torlink.co"]);
_Im_Dns (domain_has_any = torProxies)

Niektóre parametry mogą akceptować zarówno listę wartości typu dynamic , jak i pojedynczego ciągu. Aby przekazać listę literałów do parametrów, które oczekują wartości dynamicznej, jawnie użyj literału dynamicznego. Na przykład: dynamic(['192.168.','10.']).

Znormalizowana zawartość

Aby uzyskać pełną listę reguł analizy korzystających z znormalizowanych zdarzeń DNS, zobacz Zawartość zabezpieczeń zapytań DNS.

Szczegóły schematu

Model informacji DNS jest zgodny ze schematem jednostki DNS OSSEM.

Aby uzyskać więcej informacji, zobacz dokumentacja parametrów DNS urzędu IANA (Internet Assigned Numbers Authority).

Typowe pola karty ASIM

Typowe pola z określonymi wytycznymi

Na poniższej liście wymieniono pola, które mają określone wytyczne dotyczące zdarzeń DNS:

Wszystkie typowe pola

Pola wyświetlane w poniższej tabeli są wspólne dla wszystkich schematów ASIM. Wszelkie wytyczne określone powyżej zastępują ogólne wytyczne dotyczące pola. Na przykład pole może być ogólnie opcjonalne, ale obowiązkowe dla określonego schematu. Aby uzyskać więcej informacji na temat każdego pola, zobacz artykuł Common Fields ( Wspólne pola karty ASIM).

Pola systemu źródłowego

Pola użytkownika źródłowego

Pola procesu źródłowego

Pola systemu docelowego

Pola specyficzne dla systemu DNS

Pola inspekcji

Poniższe pola są używane do reprezentowania inspekcji, którą wykonano na urządzeniu zabezpieczeń DNS. Pola związane z zagrożeniami reprezentują pojedyncze zagrożenie skojarzone z adresem źródłowym, adresem docelowym, jednym z adresów IP w odpowiedzi lub domenie zapytania DNS. Jeśli jako zagrożenie zidentyfikowano więcej niż jedno zagrożenie, informacje o innych adresach IP mogą być przechowywane w polu AdditionalFields.

Przestarzałe aliasy i pola

Poniższe pola to aliasy, które są obsługiwane w celu zapewnienia zgodności z poprzednimi wersjami. Zostały one usunięte ze schematu 31 grudnia 2021 r.

• Query (alias do DnsQuery)
• QueryType (alias do DnsQueryType)
• QueryTypeName (alias do DnsQueryTypeName)
• ResponseName (alias do DnsResponseName)
• ResponseCodeName (alias do DnsResponseCodeName)
• ResponseCode (alias do DnsResponseCode)
• QueryClass (alias do DnsQueryClass)
• QueryClassName (alias do DnsQueryClassName)
• Flags (alias do DnsFlags)
• SrcUserDomain

Aktualizacje schematu

Zmiany w wersji 0.1.2 schematu to:

• Dodano pole EventSchema.
• Dodano dedykowane pole flagi, które rozszerza połączone pole Flagi: DnsFlagsAuthoritative, , DnsFlagsCheckingDisabledDnsFlagsRecursionAvailable, DnsFlagsRecursionDesired, DnsFlagsTruncated, i DnsFlagsZ.

Zmiany w wersji 0.1.3 schematu to:

• Schemat teraz jawnie dokumentuje Src*pola , Dst*Process* i User* .
• Dodano więcej Dvc* pól, aby dopasować je do najnowszej typowej definicji pól.
• Dodano Src aliasy i Dst jako aliasy do wiodącego identyfikatora dla systemów źródłowych i docelowych.
• Dodano opcjonalny DnsNetworkDuration i Durationalias do niego.
• Dodano opcjonalne pola Lokalizacja geograficzna i Poziom ryzyka.

Zmiany w wersji 0.1.4 schematu to:

• Dodano opcjonalne pola ThreatIpAddr, , ThreatFieldThreatNameThreatConfidenceThreatOriginalConfidenceThreatOriginalRiskLevelThreatIsActive, ThreatFirstReportedTime, i .ThreatLastReportedTime

Zmiany w wersji 0.1.5 schematu to:

• Dodano pola SrcUserScope, , , SrcUserSessionIdSrcDvcScopeIdSrcDvcScopeDstDvcScopeIdDstDvcScope, DvcScopeIdi .DvcScope

Zmiany w wersji 0.1.6 schematu to:

• Dodano pola DnsResponseIpCountry, , DnsResponseIpRegion, DnsResponseIpCityDnsResponseIpLatitude, i DnsResponseIpLongitude.

Zmiany w wersji 0.1.7 schematu to:

• Dodano pola SrcDescription, SrcOriginalRiskLevelDstDescriptionDstOriginalRiskLevelSrcUserScopeIdNetworkProtocolVersionRule, , RuleNameRuleNumberi .ThreatId

Rozbieżności specyficzne dla źródła

Celem normalizacji jest zapewnienie, że wszystkie źródła zapewniają spójne dane telemetryczne. Nie można znormalizować źródła, które nie udostępnia wymaganych danych telemetrycznych, takich jak obowiązkowe pola schematu. Jednak źródła, które zwykle dostarczają wszystkie wymagane dane telemetryczne, nawet jeśli występują pewne rozbieżności, mogą być znormalizowane. Rozbieżności mogą mieć wpływ na kompletność wyników zapytania.

W poniższej tabeli wymieniono znane rozbieżności:

Obsługa odpowiedzi DNS

W większości przypadków zarejestrowane zdarzenia DNS nie zawierają informacji o odpowiedzi, które mogą być duże i szczegółowe. Jeśli rekord zawiera więcej informacji o odpowiedzi, zapisz go w polu ResponseName , jak jest wyświetlany w rekordzie.

Możesz również podać dodatkową funkcję KQL o nazwie _imDNS<vendor>Response_, która przyjmuje nieparzystą odpowiedź jako dane wejściowe i zwraca wartość dynamiczną z następującą strukturą:

[
    {
        "part": "answer"
        "query": "yahoo.com."
        "TTL": 1782
        "Class": "IN"
        "Type": "A"
        "Response": "74.6.231.21"
    }
    {
        "part": "authority"
        "query": "yahoo.com."
        "TTL": 113066
        "Class": "IN"
        "Type": "NS"
        "Response": "ns5.yahoo.com"
    }
    ...
]

Pola w każdym słowniku w wartości dynamicznej odpowiadają polam w każdej odpowiedzi DNS. Wpis part powinien zawierać wartość answer, authoritylub additional , aby odzwierciedlić część w odpowiedzi, do którego należy słownik.

Obsługa flag DNS

Analizowanie i normalizacja nie są wymagane dla danych flagi. Zamiast tego zapisz dane flagi dostarczone przez urządzenie raportowania w polu Flags . Jeśli określenie wartości poszczególnych flag jest proste, możesz również użyć dedykowanych pól flag.

Możesz również podać dodatkową funkcję KQL o nazwie _imDNS<vendor>Flags_, która przyjmuje nieparzystą odpowiedź lub dedykowane pola flagi, jako dane wejściowe i zwraca listę dynamiczną z wartościami logicznymi reprezentującymi każdą flagę w następującej kolejności:

• Uwierzytelnione (AD)
• Autorytatywne (AA)
• Sprawdzanie wyłączone (CD)
• Rekursja dostępna (RA)
• Żądana rekursja (RD)
• Obcięte (TC)
• Z

Następne kroki

Aby uzyskać więcej informacji, zobacz:

• Obejrzyj seminarium internetowe ASIM lub przejrzyj slajdy
• Omówienie zaawansowanego modelu informacji o zabezpieczeniach (ASIM)
• Schematy zaawansowanego modelu informacji o zabezpieczeniach (ASIM)
• Analizatory zaawansowanego modelu informacji o zabezpieczeniach (ASIM)
• Zawartość usługi Advanced Security Information Model (ASIM)