Opracowywanie analizatorów zaawansowanego modelu informacji o zabezpieczeniach (ASIM)

Użytkownicy zaawansowanego modelu informacji o zabezpieczeniach (ASIM) używają analizatorów jednoczących zamiast nazw tabel w swoich zapytaniach, aby wyświetlać dane w znormalizowanym formacie i uwzględniać wszystkie dane istotne dla schematu w zapytaniu. Z kolei analizatory ujednolicenia używają analizatorów specyficznych dla źródła do obsługi konkretnych szczegółów każdego źródła.

Microsoft Sentinel udostępnia wbudowane analizatory specyficzne dla źródła dla wielu źródeł danych. Możesz zmodyfikować lub opracować te analizatory specyficzne dla źródła w następujących sytuacjach:

Gdy urządzenie udostępnia zdarzenia, które pasują do schematu ASIM, ale analizator specyficzny dla źródła dla urządzenia i odpowiedni schemat nie jest dostępny w Microsoft Sentinel.
Gdy analizatory specyficzne dla źródła usługi ASIM są dostępne dla urządzenia, ale urządzenie wysyła zdarzenia w metodzie lub formacie innym niż oczekiwano przez analizatory ASIM. Przykład:
- Urządzenie źródłowe może być skonfigurowane do wysyłania zdarzeń w niestandardowy sposób.
- Urządzenie może mieć inną wersję niż ta obsługiwana przez analizator ASIM.
- Zdarzenia mogą być zbierane, modyfikowane i przekazywane przez system pośredniczący.

Aby zrozumieć, jak analizatory mieszczą się w architekturze ASIM, zapoznaj się z diagramem architektury ASIM.

Niestandardowy proces programowania analizatora ASIM

W poniższym przepływie pracy opisano ogólne kroki tworzenia niestandardowego analizatora ASIM specyficznego dla źródła:

Zbierz przykładowe dzienniki.
Zidentyfikuj schematy lub schematy, które reprezentują zdarzenia wysyłane ze źródła. Aby uzyskać więcej informacji, zobacz Omówienie schematu.
Zamapuj pola zdarzenia źródłowego na zidentyfikowany schemat lub schematy.
Opracuj co najmniej jeden analizator ASIM dla źródła. Należy opracować analizator filtrowania i analizator bez parametrów dla każdego schematu odpowiedniego dla źródła.
Przetestuj analizator.
Wdróż analizatory w obszarach roboczych Microsoft Sentinel.
Zaktualizuj odpowiedni analizator ujednolicenia ASIM, aby odwoływał się do nowego analizatora niestandardowego. Aby uzyskać więcej informacji, zobacz Zarządzanie analizatorami ASIM.
Możesz również współtworzyć analizatory do podstawowej dystrybucji ASIM. Współtworzenie analizatorów może być również dostępne we wszystkich obszarach roboczych jako wbudowane analizatory.

W tym artykule przedstawiono kroki programowania, testowania i wdrażania procesu.

Porada

Obejrzyj również seminarium internetowe deep dive na Microsoft Sentinel Normalizing Parsers and Normalized Content (Normalizowanie analizatorów i znormalizowana zawartość) lub zapoznaj się z powiązanym pokazem slajdów. Aby uzyskać więcej informacji, zobacz Następne kroki.

Zbieranie przykładowych dzienników

Do kompilowania skutecznych analizatorów ASIM potrzebny jest reprezentatywny zestaw dzienników, które w większości przypadków będą wymagały skonfigurowania systemu źródłowego i połączenia go z Microsoft Sentinel. Jeśli nie masz dostępnego urządzenia źródłowego, usługi w chmurze z płatnością zgodnie z rzeczywistym użyciem umożliwiają wdrażanie wielu urządzeń na potrzeby programowania i testowania.

Ponadto znalezienie dokumentacji dostawcy i przykładów dla dzienników może pomóc przyspieszyć opracowywanie i zmniejszanie błędów poprzez zapewnienie szerokiego pokrycia formatu dziennika.

Reprezentatywny zestaw dzienników powinien obejmować:

Zdarzenia z różnymi wynikami zdarzeń.
Zdarzenia z różnymi akcjami odpowiedzi.
Różne formaty nazwy użytkownika, nazwy hosta i identyfikatorów oraz innych pól, które wymagają normalizacji wartości.

Porada

Uruchom nowy analizator niestandardowy przy użyciu istniejącego analizatora dla tego samego schematu. Użycie istniejącego analizatora jest szczególnie ważne w przypadku analizatorów filtrowania, aby upewnić się, że akceptują wszystkie parametry wymagane przez schemat.

Mapowanie planowania

Przed utworzeniem analizatora zamapuj informacje dostępne w zdarzeniu źródłowym lub zdarzeniach na zidentyfikowany schemat:

Mapuj wszystkie pola obowiązkowe, a najlepiej także zalecane pola.
Spróbuj zamapować wszystkie informacje dostępne ze źródła na znormalizowane pola. Jeśli nie jest dostępny jako część wybranego schematu, rozważ mapowanie na pola dostępne w innych schematach.
Mapuj wartości pól w źródle na znormalizowane wartości dozwolone przez usługę ASIM. Oryginalna wartość jest przechowywana w oddzielnym polu, takim jak EventOriginalResultDetails.

Tworzenie analizatorów

Opracuj zarówno filtrowanie, jak i analizator bez parametrów dla każdego odpowiedniego schematu.

Analizator niestandardowy to zapytanie KQL opracowane na stronie dzienników Microsoft Sentinel. Zapytanie analizatora ma trzy części:

Filtr>Przeanalizować>Przygotowywanie pól

Filtrowanie

Filtrowanie odpowiednich rekordów

W wielu przypadkach tabela w Microsoft Sentinel zawiera wiele typów zdarzeń. Przykład:

Tabela Syslog zawiera dane z wielu źródeł.
Tabele niestandardowe mogą zawierać informacje z jednego źródła, które udostępnia więcej niż jeden typ zdarzenia i może pasować do różnych schematów.

W związku z tym analizator powinien najpierw filtrować tylko rekordy istotne dla schematu docelowego.

Filtrowanie w języku KQL odbywa się przy użyciu where operatora . Na przykład zdarzenie Sysmon 1 raportuje tworzenie procesu i dlatego jest znormalizowane ze schematem ProcessEvent . Zdarzenie Sysmon event 1 jest częścią Event tabeli, więc należy użyć następującego filtru:

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Ważna

Analizator nie powinien filtrować według czasu. Zapytanie używające analizatora zastosuje zakres czasu.

Filtrowanie według typu źródła przy użyciu listy obserwowanych

W niektórych przypadkach samo zdarzenie nie zawiera informacji, które zezwalają na filtrowanie dla określonych typów źródeł.

Na przykład zdarzenia DNS infoblox są wysyłane jako komunikaty dziennika systemu i trudno odróżnić od komunikatów dziennika systemu wysyłanych z innych źródeł. W takich przypadkach analizator opiera się na liście źródeł definiujących odpowiednie zdarzenia. Ta lista jest przechowywana na liście obserwowanych Sources_by_SourceType .

Aby użyć listy obserwowanych ASimSourceType w analizatorach, użyj _ASIM_GetSourceBySourceType funkcji w sekcji filtrowania analizatora. Na przykład analizator DNS infoblox zawiera następujące elementy w sekcji filtrowania:

  | where Computer in (_ASIM_GetSourceBySourceType('InfobloxNIOS'))

Aby użyć tego przykładu w analizatorze:

Zastąp Computer ciąg nazwą pola zawierającego informacje o źródle. Można zachować to tak jak Computer w przypadku wszystkich analizatorów opartych na dzienniku Syslog.
Zastąp InfobloxNIOS token wybraną wartością analizatora. Poinformuj użytkowników analizatora, że muszą zaktualizować listę ASimSourceType obserwowanych przy użyciu wybranej wartości, a także listę źródeł, które wysyłają zdarzenia tego typu.

Filtrowanie na podstawie parametrów analizatora

Podczas tworzenia analizatorów filtrowania upewnij się, że analizator akceptuje parametry filtrowania dla odpowiedniego schematu, jak opisano w artykule referencyjnym dla tego schematu. Użycie istniejącego analizatora jako punktu początkowego gwarantuje, że analizator zawiera poprawny podpis funkcji. W większości przypadków rzeczywisty kod filtrowania jest również podobny do analizatorów filtrowania dla tego samego schematu.

Podczas filtrowania upewnij się, że:

Filtruj przed przeanalizowaniem przy użyciu pól fizycznych. Jeśli przefiltrowane wyniki nie są wystarczająco dokładne, powtórz test po przeanalizowaniu, aby dostosować wyniki. Aby uzyskać więcej informacji, zobacz optymalizację filtrowania.
Nie filtruj, jeśli parametr nie jest zdefiniowany i nadal ma wartość domyślną.

W poniższych przykładach pokazano, jak zaimplementować filtrowanie dla parametru ciągu, gdzie wartość domyślna to zwykle "*", oraz dla parametru listy, gdzie wartość domyślna jest zwykle pustą listą.

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

Zobacz więcej informacji na temat następujących elementów w dokumentacji usługi Kusto:

Optymalizacja filtrowania

Aby zapewnić wydajność analizatora, zwróć uwagę na następujące zalecenia dotyczące filtrowania:

Zawsze filtruj według pól wbudowanych, a nie analizowanych. Chociaż czasami łatwiej jest filtrować przy użyciu analizowanych pól, znacznie wpływa to na wydajność.
Użyj operatorów zapewniających zoptymalizowaną wydajność. W szczególności , ==, hasi startswith. Używanie operatorów, takich jak contains lub matches regex , znacząco wpływa na wydajność.

Zalecenia dotyczące filtrowania wydajności mogą nie zawsze być łatwe do wykonania. Na przykład użycie jest has mniej dokładne niż contains. W innych przypadkach dopasowanie wbudowanego pola, takiego jak SyslogMessage, jest mniej dokładne niż porównanie wyodrębnionego pola, takiego jak DvcAction. W takich przypadkach zalecamy, aby nadal wstępnie filtrować za pomocą operatora optymalizacji wydajności za pośrednictwem wbudowanego pola i powtarzać filtr przy użyciu dokładniejszych warunków po przeanalizowaniu.

Aby zapoznać się z przykładem, zobacz poniższy fragment kodu analizatora DNS infoblox . Analizator najpierw sprawdza, czy w polu has SyslogMessage jest wyraz client. Jednak termin ten może być używany w innym miejscu w komunikacie, więc po przeanalizowaniu Log_Type pola analizator ponownie sprawdza, czy słowo client rzeczywiście było wartością pola.

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

Uwaga

Analizatory nie powinny filtrować według czasu, ponieważ zapytanie używające analizatora już filtruje czas.

Analizowania

Gdy zapytanie wybierze odpowiednie rekordy, może być konieczne ich przeanalizowanie. Zazwyczaj analizowanie jest wymagane, jeśli wiele pól zdarzeń jest przekazywanych w jednym polu tekstowym.

Poniżej wymieniono operatory KQL, które przeprowadzają analizę, uporządkowane według ich optymalizacji wydajności. Pierwsza z nich zapewnia najbardziej zoptymalizowaną wydajność, a ostatnia zapewnia najmniej zoptymalizowaną wydajność.

Operator/function()	Opis
split() , funkcja	Przeanalizuj ciąg wartości rozdzielanych.
funkcja parse_csv()	Przeanalizuj ciąg wartości sformatowanych jako wiersz CSV (wartości rozdzielone przecinkami).
operator parse-kv	Wyodrębnia informacje strukturalne z wyrażenia ciągu i reprezentuje informacje w postaci klucz/wartość.
operator analizy	Przeanalizuj wiele wartości z dowolnego ciągu przy użyciu wzorca, który może być uproszczonym wzorcem o lepszej wydajności lub wyrażeniem regularnym.
funkcja extract_all()	Przeanalizuj pojedyncze wartości z dowolnego ciągu przy użyciu wyrażenia regularnego. `extract_all` Ma wydajność podobną do `parse` tej, jeśli ta ostatnia używa wyrażenia regularnego.
extract() , funkcja	Wyodrębnij pojedynczą wartość z dowolnego ciągu przy użyciu wyrażenia regularnego. Użycie `extract` zapewnia lepszą wydajność niż `parse` lub `extract_all` jeśli wymagana jest pojedyncza wartość. Jednak użycie wielu aktywacji za pośrednictwem tego samego `extract` ciągu źródłowego jest mniej wydajne niż pojedyncze `parse` lub `extract_all` i należy ich unikać.
funkcja parse_json()	Przeanalizuj wartości w ciągu sformatowanym jako JSON. Jeśli w formacie JSON jest potrzebnych tylko kilka wartości, użycie `parse`polecenia , `extract`lub `extract_all` zapewnia lepszą wydajność.
funkcja parse_xml()	Przeanalizuj wartości w ciągu sformatowanym jako XML. Jeśli w kodzie XML jest potrzebnych tylko kilka wartości, użycie polecenia `parse`, `extract`lub `extract_all` zapewnia lepszą wydajność.

Normalizacji

Nazwy pól mapowania

Najprostszą formą normalizacji jest zmiana nazwy oryginalnego pola na jego znormalizowana nazwa. W tym celu użyj operatora project-rename . Użycie zmiany nazwy projektu gwarantuje, że pole jest nadal zarządzane jako pole fizyczne, a obsługa pola jest bardziej wydajna. Przykład:

 | project-rename
    ActorUserId = InitiatingProcessAccountSid,
    ActorUserAadId = InitiatingProcessAccountObjectId,
    ActorUserUpn = InitiatingProcessAccountUpn,

Normalizowanie formatu i typu pól

W wielu przypadkach wyodrębniona oryginalna wartość musi zostać znormalizowana. Na przykład w usłudze ASIM adres MAC używa dwukropków jako separatora, podczas gdy źródło może wysłać rozdzielany łącznikiem adres MAC. Podstawowym operatorem przekształcania wartości jest extend, obok szerokiego zestawu funkcji ciągów KQL, liczbowych i date.

Ponadto zapewnienie, że pola wyjściowe analizatora są zgodne z typem zdefiniowanym w schemacie, ma kluczowe znaczenie dla działania analizatorów. Na przykład może być konieczne przekonwertowanie ciągu reprezentującego datę i godzinę na pole data/godzina. Funkcje takie jak todatetime i tohex są pomocne w takich przypadkach.

Na przykład oryginalny unikatowy identyfikator zdarzenia może być wysyłany jako liczba całkowita, ale usługa ASIM wymaga, aby wartość była ciągiem, aby zapewnić szeroką zgodność między źródłami danych. W związku z tym podczas przypisywania pola źródłowego należy użyć polecenia extend i tostring zamiast :project-rename

  | extend EventOriginalUid = tostring(ReportId),

Pola i wartości pochodne

Wartość pola źródłowego po wyodrębnieniu może wymagać zamapowania na zestaw wartości określonych dla pola schematu docelowego. Funkcje iff, casei lookup mogą być przydatne do mapowania dostępnych danych na wartości docelowe.

Na przykład analizator DNS firmy Microsoft przypisuje EventResult pole na podstawie identyfikatora zdarzenia i kodu odpowiedzi przy użyciu iff instrukcji w następujący sposób:

   extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')

Aby zamapować kilka wartości, zdefiniuj mapowanie przy użyciu datatable operatora i użyj go lookup do wykonania mapowania. Na przykład niektóre źródła raportują numeryczne kody odpowiedzi DNS i protokół sieciowy, podczas gdy schemat nakazuje reprezentację bardziej typowych etykiet tekstowych dla obu tych typów. W poniższym przykładzie pokazano, jak uzyskać potrzebne wartości przy użyciu datatable wartości i lookup:

   let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

Zwróć uwagę, że wyszukiwanie jest przydatne i wydajne również wtedy, gdy mapowanie ma tylko dwie możliwe wartości.

Gdy warunki mapowania są bardziej złożone, połącz iff, casei lookup. W poniższym przykładzie pokazano, jak połączyć lookup elementy i case. Powyższy lookup przykład zwraca pustą wartość w polu DnsResponseCodeName , jeśli nie znaleziono wartości odnośnika. Poniższy case przykład rozszerza go przy użyciu wyniku lookup operacji, jeśli jest dostępna, i określając dodatkowe warunki w przeciwnym razie.

   | extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

Microsoft Sentinel udostępnia przydatne funkcje dla typowych wartości odnośników. Na przykład DnsResponseCodeName powyższe wyszukiwanie można zaimplementować przy użyciu jednej z następujących funkcji:


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

Pierwsza opcja akceptuje jako parametr wartość do wyszukania i umożliwia wybranie pola wyjściowego, co jest przydatne jako ogólna funkcja wyszukiwania. Druga opcja jest bardziej ukierunkowana na analizatory, przyjmuje jako dane wejściowe nazwę pola źródłowego i aktualizuje wymagane pole ASIM, w tym przypadku DnsResponseCodeName.

Aby uzyskać pełną listę funkcji pomocy usługi ASIM, zapoznaj się z tematem Funkcje ASIM

Pola wzbogacania

Oprócz pól dostępnych w źródle wynikowe zdarzenie ASIM obejmuje pola wzbogacania, które powinien wygenerować analizator. W wielu przypadkach analizatory mogą przypisać stałą wartość do pól, na przykład:

  | extend                  
     EventCount = int(1),
     EventProduct = 'M365 Defender for Endpoint',
     EventVendor = 'Microsoft',
     EventSchemaVersion = '0.1.0',
     EventSchema = 'ProcessEvent'

Innym typem pól wzbogacania, które powinny być ustawione przez analizatory, są pola typu, które wyznaczają typ wartości przechowywanej w powiązanym polu. Na przykład SrcUsernameType pole określa typ wartości przechowywanej w SrcUsername polu. Więcej informacji o polach typów można znaleźć w opisie jednostek.

W większości przypadków typy są również przypisywane do wartości stałej. Jednak w niektórych przypadkach typ musi być określony na podstawie rzeczywistej wartości, na przykład:

   DomainType = iif (array_length(SplitHostname) > 1, 'FQDN', '')

Microsoft Sentinel udostępnia przydatne funkcje do obsługi wzbogacania. Na przykład użyj następującej funkcji, aby automatycznie przypisać pola SrcHostname, SrcDomaini SrcDomainTypeSrcFQDN na podstawie wartości w polu Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Ta funkcja ustawi pola w następujący sposób:

Pole Komputera	Pola wyjściowe
server1	SrcHostname: server1 SrcDomain, SrcDomainType, SrcFQDN wszystkie puste
server1.microsoft.com	SrcHostname: server1 SrcDomain: microsoft.com SrcDomainType: FQDN SrcFQDN:server1.microsoft.com

Funkcje _ASIM_ResolveDstFQDN i _ASIM_ResolveDvcFQDN wykonać podobne zadanie wypełniania powiązanych Dst i Dvc pól. Aby uzyskać pełną listę funkcji pomocy usługi ASIM, zapoznaj się z tematem Funkcje ASIM

Wybieranie pól w zestawie wyników

Analizator może opcjonalnie wybrać pola w zestawie wyników. Usunięcie niepotrzebnych pól może zwiększyć wydajność i zwiększyć przejrzystość, unikając nieporozumień między znormalizowanymi polami i pozostałymi polami źródłowymi.

Następujące operatory KQL służą do wybierania pól w zestawie wyników:

Operator	Opis	Kiedy używać w analizatorze
project-away	Usuwa pola.	Użyj dla `project-away` określonych pól, które chcesz usunąć z zestawu wyników. Zalecamy, aby nie usuwać oryginalnych pól, które nie są znormalizowane z zestawu wyników, chyba że powodują one pomyłek lub są bardzo duże i mogą mieć wpływ na wydajność.
Projektu	Wybiera pola, które istniały wcześniej lub zostały utworzone jako część instrukcji, i usuwa wszystkie inne pola.	Nie zaleca się użycia w analizatorze, ponieważ analizator nie powinien usuwać żadnych innych pól, które nie są znormalizowane. Jeśli musisz usunąć określone pola, takie jak wartości tymczasowe używane podczas analizowania, użyj polecenia `project-away` , aby usunąć je z wyników.

Na przykład podczas analizowania niestandardowej tabeli dzienników użyj następujących elementów, aby usunąć pozostałe oryginalne pola, które nadal mają deskryptor typu:

    | project-away
        *_d, *_s, *_b, *_g

Obsługa wariantów analizowania

Ważna

Różne warianty reprezentują różne typy zdarzeń, często mapowane na różne schematy, opracowywanie oddzielnych analizatorów

W wielu przypadkach zdarzenia w strumieniu zdarzeń obejmują warianty, które wymagają innej logiki analizy. Aby przeanalizować różne warianty w pojedynczym analizatorze, użyj instrukcji warunkowych, takich jak iff i , caselub użyj struktury unii.

Aby obsłużyć union wiele wariantów, utwórz oddzielną funkcję dla każdego wariantu i użyj instrukcji union, aby połączyć wyniki:

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    ...
union parseLogs,  parseLogsWithUrls…

Aby uniknąć zduplikowanych zdarzeń i nadmiernego przetwarzania, upewnij się, że każda funkcja rozpoczyna się od filtrowania przy użyciu pól natywnych, tylko zdarzeń, które mają zostać przeanalizowane. Ponadto, w razie potrzeby, użyj funkcji project-away w każdej gałęzi przed unią.

Wdrażanie analizatorów

Wdróż analizatory ręcznie, kopiując je na stronę dziennika Azure Monitor i zapisując zapytanie jako funkcję. Ta metoda jest przydatna do testowania. Aby uzyskać więcej informacji, zobacz Tworzenie funkcji.

Aby wdrożyć dużą liczbę analizatorów, zalecamy użycie szablonów usługi ARM analizatora w następujący sposób:

Utwórz plik YAML na podstawie odpowiedniego szablonu dla każdego schematu i dołącz do niego zapytanie. Zacznij od szablonu YAML odpowiedniego dla schematu i typu analizatora, filtrowania lub bez parametru.
Konwerter szablonu ASIM YAML to ARM umożliwia konwertowanie pliku YAML na szablon usługi ARM.
W przypadku wdrażania aktualizacji usuń starsze wersje funkcji przy użyciu portalu lub narzędzia programu PowerShell do usuwania funkcji.
Wdróż szablon przy użyciu Azure Portal lub programu PowerShell.

Można również połączyć wiele szablonów z pojedynczym procesem wdrażania przy użyciu połączonych szablonów

Porada

Szablony usługi ARM mogą łączyć różne zasoby, dzięki czemu można wdrażać analizatory obok łączników, reguł analitycznych lub list obserwowanych, aby wymienić kilka przydatnych opcji. Na przykład analizator może odwoływać się do listy obserwowanych wdrożonej obok niej.

Analizatory testów

W tej sekcji opisano, że narzędzia do testowania ASIM umożliwiają testowanie analizatorów. Mimo to analizatory są kodem, czasami złożonymi i standardowymi praktykami zapewniania jakości, takimi jak przeglądy kodu, są zalecane oprócz testowania zautomatyzowanego.

Instalowanie narzędzi testowych ASIM

Aby przetestować usługę ASIM, wdróż narzędzie do testowania ASIM w Microsoft Sentinel obszarze roboczym, w którym:

Analizator został wdrożony.
Tabela źródłowa używana przez analizator jest dostępna.
Tabela źródłowa używana przez analizator jest wypełniana zróżnicowaną kolekcją odpowiednich zdarzeń.

Weryfikowanie schematu wyjściowego

Aby upewnić się, że analizator tworzy prawidłowy schemat, użyj testera schematu ASIM, uruchamiając następujące zapytanie na stronie dzienników Microsoft Sentinel:

<parser name> | getschema | invoke ASimSchemaTester('<schema>')

Obsługa wyników w następujący sposób:

Error	Akcja
Brak pola obowiązkowego [<Pole>]	Dodaj pole do analizatora. W wielu przypadkach byłaby to wartość pochodna lub stała, a nie pole dostępne już ze źródła.
Brakujące pole [<Pole>] jest obowiązkowe, gdy istnieje obowiązkowa kolumna [<Field>]	Dodaj pole do analizatora. W wielu przypadkach to pole oznacza typy istniejącej kolumny, do których się odwołuje.
Brakujące pole [<Pole>] jest obowiązkowe, gdy istnieje kolumna [<Field>]	Dodaj pole do analizatora. W wielu przypadkach to pole oznacza typy istniejącej kolumny, do których się odwołuje.
Brak obowiązkowego aliasu [<Field>] aliasing istniejącej kolumny [<Pole>]	Dodawanie aliasu do analizatora
Brak zalecanego aliasu [<Field>] aliasing istniejącej kolumny [<Pole>]	Dodawanie aliasu do analizatora
Brak opcjonalnego aliasu [<Field>] aliasing istniejącej kolumny [<Pole>]	Dodawanie aliasu do analizatora
Brak obowiązkowego aliasu [<Pole>] — brakujące kolumny [<Pole>]	Ten błąd towarzyszy podobny błąd dla pola aliasu. Popraw błąd pola aliasu i dodaj ten alias do analizatora.
Niezgodność typu dla pola [<Field>]. Jest to obecnie [<typ>] i powinien mieć wartość [<Type>]	Upewnij się, że typ znormalizowanego pola jest poprawny, zwykle przy użyciu funkcji konwersji , takiej jak `tostring`.

Informacji	Akcja
Brak zalecanego pola [<Pole>]	Rozważ dodanie tego pola do analizatora.

Informacji	Akcja
Brak zalecanego aliasu [<Field>] aliasing nieistniejącej kolumny [<Pole>]	Jeśli dodasz pole aliasowane do analizatora, pamiętaj również o dodaniu tego aliasu.
Brak opcjonalnego aliasu [<Field>] aliasing nieistniejącej kolumny [<Pole>]	Jeśli dodasz pole aliasowane do analizatora, pamiętaj również o dodaniu tego aliasu.
Brak pola opcjonalnego [<Pole>]	Chociaż często brakuje opcjonalnych pól, warto przejrzeć listę, aby ustalić, czy dowolne opcjonalne pola mogą być mapowane ze źródła.
Dodatkowe pole nienormalizowane [<Pole>]	Mimo że pola nienormalizowane są prawidłowe, warto przejrzeć listę, aby ustalić, czy któraś z nienormalizowanych wartości może zostać zamapowana na pole opcjonalne.

Uwaga

Błędy uniemożliwią prawidłowe działanie zawartości przy użyciu analizatora. Ostrzeżenia nie uniemożliwią działania zawartości, ale mogą obniżyć jakość wyników.

Weryfikowanie wartości wyjściowych

Aby upewnić się, że analizator generuje prawidłowe wartości, użyj testera danych ASIM, uruchamiając następujące zapytanie na stronie dzienników Microsoft Sentinel:

<parser name> | limit <X> | invoke ASimDataTester ('<schema>')

Określanie schematu jest opcjonalne. Jeśli schemat nie zostanie określony, EventSchema pole zostanie użyte do zidentyfikowania schematu, do którego powinno być stosowane zdarzenie. Jeśli zdarzenie nie zawiera EventSchema pola, zostaną zweryfikowane tylko typowe pola. Jeśli schemat zostanie określony jako parametr, ten schemat zostanie użyty do przetestowania wszystkich rekordów. Jest to przydatne w przypadku starszych analizatorów, które nie ustawiają EventSchema pola.

Uwaga

Nawet jeśli schemat nie zostanie określony, po nazwie funkcji potrzebne są puste nawiasy.

Ten test intensywnie obciąża zasoby i może nie działać w całym zestawie danych. Ustaw wartość X na największą liczbę, dla której zapytanie nie przekroczą limitu czasu, lub ustaw zakres czasu dla zapytania przy użyciu selektora zakresu czasu.

Obsługa wyników w następujący sposób:

Komunikat	Akcja
(0) Błąd: niezgodność typu dla kolumny [<Pole>]. Jest to obecnie [<typ>] i powinien mieć wartość [<Type>]	Upewnij się, że typ znormalizowanego pola jest poprawny, zwykle przy użyciu funkcji konwersji , takiej jak `tostring`.
(0) Błąd: Nieprawidłowe wartości (do 10 wymienionych) dla pola [<Pole>] typu [<Typ> logiczny]	Upewnij się, że analizator mapuje poprawne pole źródłowe na pole wyjściowe. Jeśli zamapowaliśmy poprawnie, zaktualizuj analizator, aby przekształcić wartość źródłową w prawidłowy typ, wartość lub format. Aby uzyskać więcej informacji na temat prawidłowych wartości i formatów dla każdego typu logicznego, zapoznaj się z listą typów logicznych . Należy pamiętać, że narzędzie do testowania wyświetla tylko przykład 10 nieprawidłowych wartości.
(1) Ostrzeżenie: Pusta wartość w polu obowiązkowym [<Pole>]	Pola obowiązkowe powinny być wypełnione, a nie tylko zdefiniowane. Sprawdź, czy pole można wypełnić z innych źródeł dla rekordów, dla których bieżące źródło jest puste.
(2) Informacje: Pusta wartość w zalecanym polu [<Pole>]	Zalecane pola powinny być zwykle wypełniane. Sprawdź, czy pole można wypełnić z innych źródeł dla rekordów, dla których bieżące źródło jest puste.
(2) Informacje: Pusta wartość w polu opcjonalnym [<Pole>]	Sprawdź, czy pole aliasowane jest obowiązkowe, czy zalecane, a jeśli tak, to czy można je wypełnić z innych źródeł.

Wiele komunikatów zgłasza również liczbę rekordów, które wygenerowały komunikat, oraz ich procent całkowitej próbki. Ten procent jest dobrym wskaźnikiem znaczenia problemu. Na przykład w przypadku pola zalecanego:

90% pustych wartości może wskazywać ogólny problem z analizą.
25% pustych wartości może wskazywać wariant zdarzenia, który nie został poprawnie przeanalizowany.
Kilka pustych wartości może być znikomym problemem.

Uwaga

Błędy uniemożliwią prawidłowe działanie zawartości przy użyciu analizatora. Ostrzeżenia nie uniemożliwią działania zawartości, ale mogą obniżyć jakość wyników.

Współtworzenie analizatorów

Może być konieczne współtworzenie analizatora do podstawowej dystrybucji ASIM. Jeśli zostaną zaakceptowane, analizatory będą dostępne dla każdego klienta jako wbudowane analizatory ASIM.

Aby współtworzyć analizatory:

Opracuj analizator filtrowania i analizator bez parametrów.
Utwórz plik YAML dla analizatora zgodnie z opisem w artykule Wdrażanie analizatorów powyżej.
Upewnij się, że analizatory przechodzą wszystkie testy bez błędów. Jeśli jakiekolwiek ostrzeżenia zostaną pozostawione, udokumentowaj je w pliku YAML analizatora.
Utwórz żądanie ściągnięcia dla Microsoft Sentinel repozytorium GitHub, w tym:
- Pliki YAML analizatorów w folderach analizatora ASIM (/Parsers/ASim<schema>/Parsers)
- Reprezentatywne przykładowe dane zgodnie z wytycznymi dotyczącymi przesyłania przykładów.
- Wyniki testu zgodnie z wytycznymi dotyczącymi przesyłania wyników testów.

Dokumentowanie zaakceptowanych ostrzeżeń

Jeśli ostrzeżenia wymienione przez narzędzia do testowania ASIM są uważane za prawidłowe dla analizatora, należy udokumentować akceptowane ostrzeżenia w pliku YAML analizatora przy użyciu sekcji Wyjątki, jak pokazano w poniższym przykładzie.

Exceptions:
- Field: DnsQuery 
  Warning: Invalid value
  Exception: May have values such as "1164-ms-7.1440-9fdc2aab.3b2bd806-978e-11ec-8bb3-aad815b5cd42" which are not valid domains names. Those are related to TKEY RR requests.
- Field: DnsQuery
  Warning: Empty value in mandatory field
  Exception: May be empty for requests for root servers and for requests for RR type DNSKEY

Ostrzeżenie określone w pliku YAML powinno być krótką formą jednoznacznie identyfikującego komunikat ostrzegawczy. Wartość jest używana do dopasowania komunikatów ostrzegawczych podczas przeprowadzania testów automatycznych i ignorowania ich.

Wskazówki dotyczące przesyłania przykładów

Przykładowe dane są potrzebne podczas rozwiązywania problemów z analizatorem i zapewniania zgodności przyszłych aktualizacji analizatora ze starszymi przykładami. Przesłane przykłady powinny zawierać dowolny wariant zdarzenia obsługiwany przez analizator. Upewnij się, że przykładowe zdarzenia obejmują wszystkie możliwe typy zdarzeń, formaty zdarzeń i odmiany, takie jak zdarzenia reprezentujące działanie zakończone powodzeniem i niepowodzeniem. Upewnij się również, że są reprezentowane odmiany w formatach wartości. Jeśli na przykład nazwa hosta może być reprezentowana jako nazwa FQDN lub prosta nazwa hosta, przykładowe zdarzenia powinny zawierać oba formaty.

Aby przesłać przykłady zdarzeń, wykonaj następujące kroki:

Na ekranie Logs uruchom zapytanie, które wyodrębni z tabeli źródłowej tylko zdarzenia wybrane przez analizator. Na przykład w przypadku analizatora DNS infoblox użyj następującego zapytania:

    Syslog
    | where ProcessName == "named"

Wyeksportuj wyniki przy użyciu opcji Eksportuj do pliku CSV do pliku o nazwie <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, Gdzie EventProduct, EventProducti EventSchema są wartościami przypisanymi przez analizator do tych pól.
Na ekranie Logs uruchom zapytanie, które spowoduje wyświetlenie schematu lub tabeli wejściowej analizatora. Na przykład dla tego samego analizatora DNS infoblox zapytanie jest następujące:

    Syslog
    | getschema

Wyeksportuj wyniki przy użyciu opcji Eksportuj do pliku CSV do pliku o nazwie <TableName>_schema.csv, gdzie TableName jest nazwą tabeli źródłowej używanej przez analizator.
Dołącz oba pliki do żądania ściągnięcia w folderze /Sample Data/ASIM. Jeśli plik już istnieje, dodaj dojście usługi GitHub do nazwy, na przykład: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Wytyczne dotyczące przesyłania wyników testów

Wyniki testów są ważne, aby zweryfikować poprawność analizatora i zrozumieć każdy zgłoszony wyjątek.

Aby przesłać wyniki testu, wykonaj następujące kroki:

Uruchom testy analizatora i opisano je w sekcji testów .
i wyeksportuj wyniki testów przy użyciu opcji Eksportuj do pliku CSV odpowiednio do plików o nazwie <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv i <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv .
Dołącz oba pliki do żądania ściągnięcia w folderze /Parsers/ASim<schema>/Tests.

Następne kroki

W tym artykule omówiono tworzenie analizatorów ASIM.

Dowiedz się więcej o analizatorach ASIM:

Dowiedz się więcej na temat karty ASIM w ogóle:

Opinia

Czy ta strona była pomocna?

Last updated on 2026-04-23

Opracowywanie analizatorów zaawansowanego modelu informacji o zabezpieczeniach (ASIM)

Niestandardowy proces programowania analizatora ASIM

Zbieranie przykładowych dzienników

Mapowanie planowania

Tworzenie analizatorów

Filtrowanie

Filtrowanie odpowiednich rekordów

Filtrowanie według typu źródła przy użyciu listy obserwowanych

Filtrowanie na podstawie parametrów analizatora

Optymalizacja filtrowania

Analizowania

Normalizacji

Nazwy pól mapowania

Normalizowanie formatu i typu pól

Pola i wartości pochodne

Pola wzbogacania

Wybieranie pól w zestawie wyników

Obsługa wariantów analizowania

Wdrażanie analizatorów

Analizatory testów

Instalowanie narzędzi testowych ASIM

Weryfikowanie schematu wyjściowego

Weryfikowanie wartości wyjściowych

Współtworzenie analizatorów

Dokumentowanie zaakceptowanych ostrzeżeń

Wskazówki dotyczące przesyłania przykładów

Wytyczne dotyczące przesyłania wyników testów

Następne kroki

Opinia

Dodatkowe zasoby