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

Artykuł
03/23/2023

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

Usługa 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 pasujące do schematu ASIM, ale analizator specyficzny dla źródła dla urządzenia i odpowiedni schemat nie jest dostępny w usłudze Microsoft Sentinel.
Gdy analizatory specyficzne dla źródła karty 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 sposób nietypowy.
- 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 dowiedzieć się, jak analizatory pasują do architektury ASIM, zapoznaj się z diagramem architektury ASIM.

Ważne

ASIM jest obecnie w wersji zapoznawczej. Dodatkowe postanowienia dotyczące wersji zapoznawczej platformy Azure obejmują dodatkowe postanowienia prawne dotyczące funkcji platformy Azure, które są w wersji beta, wersji zapoznawczej lub nie zostały jeszcze wydane w ogólnej dostępności.

Niestandardowy proces tworzenia analizatora ASIM

Poniższy przepływ pracy opisuje kroki wysokiego poziomu podczas tworzenia niestandardowego analizatora ASIM, specyficznego dla źródła:

Zbierz przykładowe dzienniki.
Zidentyfikuj schematy lub schematy, które są reprezentowane przez zdarzenia wysyłane ze źródła. Aby uzyskać więcej informacji, zobacz Omówienie schematu.
Zamapuj pola zdarzeń źródłowych na zidentyfikowany schemat lub schematy.
Utwórz 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 usługi Microsoft Sentinel.
Zaktualizuj odpowiedni analizator ujednolicania karty ASIM, aby odwołać 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ółautorzy analizatorów mogą być również udostępniane we wszystkich obszarach roboczych jako wbudowane analizatory.

W tym artykule opisano kroki tworzenia, testowania i wdrażania procesu.

Porada

Obejrzyj również seminarium internetowe Deep Dive w usłudze Microsoft Sentinel Normaliizing Parsers i Normalized Content lub przejrzyj powiązany pokaz slajdów. Aby uzyskać więcej informacji, zobacz Następne kroki.

Zbieranie przykładowych dzienników

Aby utworzyć skuteczne analizatory ASIM, potrzebujesz reprezentatywnego zestawu dzienników, który w większości przypadków będzie wymagał skonfigurowania systemu źródłowego i połączenia go z usługą Microsoft Sentinel. Jeśli nie masz dostępnego urządzenia źródłowego, usługi z płatnością zgodnie z rzeczywistym użyciem w chmurze 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 zmniejszyć błędy dzięki zapewnieniu szerokiego zakresu formatów dzienników.

Reprezentatywny zestaw dzienników powinien obejmować:

Zdarzenia z różnymi wynikami zdarzenia.
Zdarzenia z różnymi akcjami odpowiedzi.
Różne formaty nazwy użytkownika, nazwy hosta i identyfikatorów oraz inne pola, 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 opracowaniem analizatora zamapuj informacje dostępne w zdarzeniu źródłowym lub zdarzeniach na zidentyfikowany schemat:

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

Opracowywanie analizatorów

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

Niestandardowy analizator to zapytanie KQL opracowane na stronie Dzienniki usługi Microsoft Sentinel. Zapytanie analizatora ma trzy części:

Filtr>Przeanalizować>Przygotowywanie pól

Filtrowanie

Filtrowanie odpowiednich rekordów

W wielu przypadkach tabela w usłudze 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 mogą pasować do różnych schematów.

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

Filtrowanie w KQL odbywa się przy użyciu where operatora . Na przykład zdarzenie Sysmon 1 zgłasza tworzenie procesu i dlatego jest znormalizowane do schematu ProcessEvent . Zdarzenie Sysmon 1 jest częścią Event tabeli, dlatego należy użyć następującego filtru:

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

Ważne

Analizator nie powinien filtrować według czasu. Zapytanie, które używa 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 zezwalałyby na filtrowanie określonych typów źródłowych.

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

Aby użyć listy obserwatorów 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 to zachować tak jak Computer w przypadku dowolnych analizatorów opartych na dzienniku systemowym.
InfobloxNIOS Zastąp token wybraną wartością analizatora. Poinformuj użytkowników analizatora, że muszą zaktualizować ASimSourceType listę 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 opracowywania 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 wyjścia gwarantuje, że analizator zawiera prawidłowy 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 analizowaniem 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 optymalizacja filtrowania.
Nie filtruj, jeśli parametr nie jest zdefiniowany i nadal ma wartość domyślną.

W poniższych przykładach pokazano, jak zaimplementować filtrowanie parametru ciągu, gdzie wartość domyślna to zwykle "*" i parametr 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)

Optymalizacja filtrowania

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

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

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

Przykład można znaleźć w poniższym fragmencie analizatora DNS infoblox . Analizator najpierw sprawdza, czy w polu has SyslogMessage jest wyświetlany wyraz client. Jednak termin może być używany w innym miejscu w komunikacie, więc po przeanalizowaniu Log_Type pola analizator sprawdza ponownie, że wyraz client był rzeczywiście 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. Zwykle analizowanie jest wymagane, jeśli wiele pól zdarzeń jest przekazywanych w jednym polu tekstowym.

Poniżej wymieniono operatory KQL wykonujące analizowanie uporządkowane według ich optymalizacji wydajności. Pierwszy zapewnia najbardziej zoptymalizowaną wydajność, podczas gdy ostatni zapewnia najmniej zoptymalizowaną wydajność.

Operator	Opis
Split	Przeanalizuj ciąg rozdzielonych wartości.
parse_csv	Przeanalizuj ciąg wartości sformatowanych jako wiersz CSV (wartości rozdzielane przecinkami).
parse-kv	Wyodrębnia informacje ustrukturyzowane z wyrażenia ciągu i reprezentuje informacje w postaci klucza/wartości.
Przeanalizować	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żeniu regularnym.
extract_all	Analizowanie pojedynczych wartości z dowolnego ciągu przy użyciu wyrażenia regularnego. `extract_all` ma podobną wydajność, jak `parse` w przypadku użycia wyrażenia regularnego.
Wyodrębnić	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 `extract` w tym samym ciągu źródłowym jest mniej wydajne niż pojedyncze `parse` lub `extract_all` należy unikać.
parse_json	Przeanalizuj wartości w ciągu sformatowanym jako JSON. Jeśli potrzebujesz tylko kilku wartości z formatu JSON, przy użyciu metody `parse`, `extract`lub `extract_all` zapewnia lepszą wydajność.
parse_xml	Przeanalizuj wartości w ciągu sformatowanym jako XML. Jeśli z kodu XML jest potrzebnych tylko kilka wartości, użyj polecenia `parse`, `extract`lub `extract_all` zapewnia lepszą wydajność.

Normalizacji

Nazwy pól mapowania

Najprostszą formą normalizacji jest zmiana nazwy oryginalnego pola na znormalizowaną nazwę. W tym celu użyj operatora project-rename . Użycie 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 oryginalna wyodrębniona wartość musi być znormalizowana. Na przykład w przypadku karty ASIM adres MAC używa dwukropków jako separatora, podczas gdy źródło może wysłać rozdzielany adres MAC łącznika. Podstawowym operatorem przekształcania wartości jest extend, obok szerokiego zestawu funkcji KQL ciągów, liczbowych i dat.

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

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

  | extend EventOriginalUid = tostring(ReportId),

Pola pochodne i wartości

Wartość pola źródłowego, po wyodrębnieniu, może być konieczne zamapowanie 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 instrukcji iff 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 polecenia lookup , aby wykonać mapowanie. Na przykład niektóre źródła raportują numeryczne kody odpowiedzi DNS i protokół sieciowy, podczas gdy schemat nakazuje bardziej typową reprezentację etykiet tekstowych dla obu tych typów. W poniższym przykładzie pokazano, jak uzyskać wymagane wartości przy użyciu metod datatable 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 iffwartości , casei lookup. W poniższym przykładzie pokazano, jak połączyć lookup elementy i case. Powyższy lookup przykład zwraca wartość pustą 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śla dodatkowe warunki w przeciwnym razie.

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

Usługa 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 przyjmuje jako parametr wartość do wyszukania i umożliwia wybranie pola wyjściowego i dlatego jest przydatne jako ogólna funkcja odnośnika. Druga opcja jest bardziej skierowana do analizatorów, 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 ze źródła wynikowe zdarzenie ASIM zawiera pola wzbogacania, które powinny zostać wygenerowane przez analizator. W wielu przypadkach analizatory mogą przypisywać 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 określają typ wartości przechowywanej w powiązanym polu. Na przykład SrcUsernameType pole wyznacza typ wartości przechowywanej SrcUsername w polu. Więcej informacji na temat pól typów można znaleźć w opisie jednostek.

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

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

Usługa Microsoft Sentinel udostępnia przydatne funkcje do obsługi wzbogacania. Na przykład użyj następującej funkcji, aby automatycznie przypisać pola SrcHostname, SrcDomainSrcDomainType i SrcFQDN 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
serwer1	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 wykonują podobne zadanie wypełniania powiązanych Dst pól i Dvc . 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 mylących między znormalizowanymi polami a pozostałymi polami źródłowymi.

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

Operator	Opis	Kiedy należy używać w analizatorze
od projektu	Usuwa pola.	Użyj `project-away` polecenia dla określonych pól, które mają zostać usunięte z zestawu wyników. Zalecamy, aby nie usuwać oryginalnych pól, które nie są znormalizowane z zestawu wyników, chyba że powodują one zamieszanie 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 w ramach instrukcji, i usuwa wszystkie inne pola.	Nie zaleca się używania 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 typów:

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

Obsługa wariantów analizowania

Ważne

Różne warianty reprezentują różne typy zdarzeń, często mapowane na różne schematy, opracowują oddzielne analizatory

W wielu przypadkach zdarzenia w strumieniu zdarzeń obejmują warianty, które wymagają różnych logiki analizowania. Aby przeanalizować różne warianty w jednym analizatorze, należy użyć instrukcji warunkowych, takich jak iff i , caselub użyć struktury unii.

union Aby obsługiwać 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, używając pól natywnych, tylko zdarzeń, które mają być analizowane. Ponadto w razie potrzeby należy użyć opcji project-away w każdej gałęzi przed związkiem.

Wdrażanie analizatorów

Wdróż analizatory ręcznie, kopiując je na stronę dziennika usługi 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 analizatora ARM w następujący sposób:

Utwórz plik YAML na podstawie odpowiedniego szablonu dla każdego schematu i dołącz zapytanie do niego. Zacznij od szablonu YAML odpowiedniego dla typu schematu i analizatora, filtrowania lub bez parametrów.
Użyj konwertera szablonów ASIM Yaml do usługi ARM, aby przekonwertować plik YAML na szablon usługi ARM.
W przypadku wdrażania aktualizacji usuń starsze wersje funkcji przy użyciu portalu lub narzędzia do usuwania programu PowerShell przez funkcję.
Wdróż szablon przy użyciu Azure Portal lub programu PowerShell.

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

Porada

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

Analizatory testów

W tej sekcji opisano, że narzędzia do testowania ASIM zapewniają możliwość testowania analizatorów. Oznacza to, że analizatory są kodami, czasami złożonymi, a standardowe praktyki zapewniania jakości, takie jak przeglądy kodu, są zalecane oprócz testów automatycznych.

Instalowanie narzędzi do testowania ASIM

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

Analizator został wdrożony.
Dostępna jest tabela źródłowa używana przez analizator.
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 Dzienniki usługi Microsoft Sentinel:

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

Obsłuż wyniki w następujący sposób:

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

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

Info	Akcja
Brak zalecanego aliasu [<Pole>] aliasu nieistniejącej kolumny [<Pole>]	Jeśli do analizatora zostanie dodane pole aliasu, pamiętaj o dodaniu tego aliasu.
Brak opcjonalnego aliasu [<Field>] aliasu nieistniejącej kolumny [<Pole>]	Jeśli do analizatora zostanie dodane pole aliasu, pamiętaj o dodaniu tego aliasu.
Brak pola opcjonalnego [<Pole>]	Chociaż brakuje pól opcjonalnych, warto przejrzeć listę, aby określić, czy można mapować dowolne z pól opcjonalnych ze źródła.
Dodatkowe nienormalizowane pole [<Pole>]	Chociaż nienormalizowane pola są prawidłowe, warto przejrzeć listę, aby określić, czy można zamapować dowolne z nienormalizowanych wartości na opcjonalne pole.

Uwaga

Błędy uniemożliwiają prawidłowe działanie zawartości przy użyciu analizatora. Ostrzeżenia nie uniemożliwiają działania zawartości, ale mogą zmniejszyć 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 Dzienniki usługi Microsoft Sentinel:

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

Określanie schematu jest opcjonalne. Jeśli schemat nie zostanie określony, EventSchema pole jest używane do identyfikowania schematu, do którego powinno być zgodne zdarzenie. Ig zdarzenia nie zawiera EventSchema pola, tylko wspólne pola zostaną zweryfikowane. Jeśli schemat zostanie określony jako parametr, ten schemat będzie używany do testowania 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, wymagane są puste nawiasy po nazwie funkcji.

Ten test jest intensywnie korzystający z zasobów i może nie działać w całym zestawie danych. Ustaw wartość X na największą liczbę, dla której zapytanie nie upłynął limit czasu, lub ustaw zakres czasu zapytania przy użyciu selektora zakresu czasu.

Obsłuż wyniki w następujący sposób:

Message	Akcja
(0) Błąd: niezgodność typów dla kolumny [<Pole>]. Jest on obecnie [<Type>] 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 mapowane poprawnie, zaktualizuj analizator, aby przekształcić wartość źródłową na poprawny typ, wartość lub format. Aby uzyskać więcej informacji na temat poprawnych 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 próbkę 10 nieprawidłowych wartości.
(1) Ostrzeżenie: Pusta wartość w polu obowiązkowym [<Pole>]	Obowiązkowe pola powinny być wypełniane, 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 aliasu jest obowiązkowe, czy zalecane, a jeśli tak, 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 i ich procent całkowitej próbki. Ta wartość procentowa jest dobrym wskaźnikiem znaczenia problemu. Na przykład dla zalecanego pola:

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

Uwaga

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

Współtworzenie analizatorów

Możesz współtworzyć analizator do podstawowej dystrybucji ASIM. W przypadku zaakceptowania analizatory będą dostępne dla każdego klienta jako wbudowane analizatory ASIM.

Aby współtworzyć analizatory:

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

Dokumentowanie akceptowanych ostrzeżeń

Jeśli ostrzeżenia wymienione przez narzędzia do testowania karty ASIM są uznawane za prawidłowe dla analizatora, należy udokumentować zaakceptowane ostrzeżenia w pliku parser YAML 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ą komunikatu ostrzegawczego jednoznacznie identyfikującego. Wartość jest używana do dopasowywania komunikatów ostrzegawczych podczas przeprowadzania testów automatycznych i ich ignorowania.

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

Przykładowe dane są potrzebne podczas rozwiązywania problemów z analizatorem i zapewnienia przyszłych aktualizacji analizatora zgodnego ze starszymi przykładami. Przesyłane przykłady powinny zawierać dowolny wariant zdarzenia, który obsługuje analizator. Upewnij się, że przykładowe zdarzenia zawierają 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 różnice 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ębnia z tabeli źródłowej tylko zdarzenia wybrane przez analizator. Na przykład w przypadku analizatora DNS systemu Infoblox użyj następującego zapytania:

    Syslog
    | where ProcessName == "named"

Wyeksportuj wyniki przy użyciu opcji Eksportuj do woluminu 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 wyświetli schemat lub tabelę wejściową analizatora. Na przykład w przypadku tego samego analizatora DNS systemu Infoblox zapytanie to:

    Syslog
    | getschema

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

Wskazówki dotyczące przesyłania wyników testów

Wyniki testu są ważne, aby zweryfikować poprawność analizatora i zrozumieć wszelkie zgłoszone wyjątki.

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

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

Następne kroki

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

Dowiedz się więcej o analizatorach ASIM:

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

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

Niestandardowy proces tworzenia analizatora ASIM

Zbieranie przykładowych dzienników

Mapowanie planowania

Opracowywanie 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 pochodne i wartości

Pola wzbogacania

Wybieranie pól w zestawie wyników

Obsługa wariantów analizowania

Wdrażanie analizatorów

Analizatory testów

Instalowanie narzędzi do testowania ASIM

Weryfikowanie schematu wyjściowego

Weryfikowanie wartości wyjściowych

Współtworzenie analizatorów

Dokumentowanie akceptowanych ostrzeżeń

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

Wskazówki dotyczące przesyłania wyników testów

Następne kroki

Dodatkowe zasoby