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

Artykuł
11/06/2024

Użytkownicy zaawansowanego modelu informacji o zabezpieczeniach (ASIM) używają analizatorów ujednolicających 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 ASIM są dostępne dla urządzenia, ale urządzenie wysyła zdarzenia w metodzie lub formacie innym niż oczekiwano przez analizatory ASIM. Na przykład:
- Urządzenie źródłowe może być skonfigurowane do wysyłania zdarzeń w sposób niestandardowy.
- 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 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ą dostępne w wersji beta, wersji zapoznawczej lub w inny sposób nie zostały jeszcze wydane w wersji ogólnodostępnej.

Niestandardowy proces tworzenia analizatora ASIM

Poniższy przepływ pracy zawiera opis kroków wysokiego poziomu podczas 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 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 ujednolicający 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ółautorzy mogą być również udostępniane we wszystkich obszarach roboczych jako analizatory wbudowane.

Ten artykuł przeprowadzi Cię przez kroki tworzenia, testowania i wdrażania procesu.

Napiwek

Obejrzyj również seminarium internetowe deep dive w usłudze Microsoft Sentinel Normaliizing Parsers and Normalized Content (Znormalizowanie zawartości ) 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, potrzebny jest reprezentatywny zestaw 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 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 zmniejszyć błędy dzięki zapewnieniu szerokiego pokrycia formatu dziennika.

Reprezentatywny zestaw dzienników powinien obejmować:

Zdarzenia z różnymi wynikami zdarzenia.
Zdarzenia z różnymi akcjami odpowiedzi.
Różne formaty nazw użytkowników, nazw hostów i identyfikatorów oraz innych pól, które wymagają normalizacji wartości.

Napiwek

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 pola obowiązkowe 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.
Mapuj 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

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

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

Filtrowanie>analizowania>pól przygotowywania

Filtrowanie

Filtrowanie odpowiednich rekordów

W wielu przypadkach tabela w usłudze Microsoft Sentinel zawiera wiele typów zdarzeń. Na 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 języku 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, więc 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 korzystające z analizatora zastosuje zakres czasu.

Filtrowanie według typu źródłowego przy użyciu listy kontrolnej

W niektórych przypadkach samo zdarzenie nie zawiera informacji, które umożliwiają filtrowanie dla określonych typów źródłowych.

Na przykład zdarzenia DNS systemu 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 kontrolnej 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, zgodnie z opisem w artykule referencyjnym dla tego schematu. Użycie istniejącego analizatora jako punktu początkowego 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 przeanalizowanych pól, ma to znaczący wpływ na wydajność.
Używaj operatorów zapewniających zoptymalizowaną wydajność. W szczególności , ==hasi startswith. Używanie 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 słowo client. Jednak termin może być używany w innym miejscu w komunikacie, więc po przeanalizowaniu Log_Type pola analizator sprawdza ponownie, że słowo client było 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 na czas.

Analiza

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 wykonują analizowanie, uporządkowane według ich optymalizacji wydajności. Pierwszy zapewnia najbardziej zoptymalizowaną wydajność, a 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 formularzu klucza/wartości.
Parse	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ść do `parse` tego, jeśli ten ostatni używa wyrażenia regularnego.
ekstrakt	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 z formatu JSON jest potrzebnych tylko kilka wartości, użyj metody `parse`, `extract`lub `extract_all` zapewnia lepszą wydajność.
parse_xml	Przeanalizuj wartości w ciągu sformatowanym jako XML. Jeśli z pliku XML jest potrzebnych tylko kilka wartości, użyj metody `parse`, `extract`lub `extract_all` zapewnia lepszą wydajność.

Normalizacji

Nazwy pól mapowania

Najprostszą formą normalizacji jest zmiana nazwy oryginalnego pola na znormalizowaną nazwę. Użyj operatora project-rename . Użycie zmiany nazwy projektu gwarantuje, że pole jest nadal zarządzane jako pole fizyczne i obsługa pola jest bardziej wydajne. Na przykład:

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

Normalizacja formatu i typu pól

W wielu przypadkach oryginalna wartość wyodrębniona musi być znormalizowana. Na przykład w 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 pracy. 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 usługa ASIM wymaga, aby wartość była ciągiem, aby zapewnić szeroką zgodność ze źródłami danych. W związku z tym podczas przypisywania pola źródłowego project-renameużyj polecenia extend i tostring zamiast :

  | 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 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 polecenia lookup , aby wykonać mapowanie. Na przykład niektóre źródła zgłaszają 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 poleceń 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 iff, 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 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.

Pełną listę funkcji pomocy ASIM można znaleźć w temacie ASIM functions (Funkcje ASIM)

Pola wzbogacania

Oprócz pól dostępnych ze źródła wynikowe zdarzenie ASIM obejmuje pola wzbogacania, które powinien wygenerować 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 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 być określany na podstawie rzeczywistej wartości, 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 . Pełną listę funkcji pomocy ASIM można znaleźć w temacie ASIM functions (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ąc 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
odchodzi od projektu	Usuwa pola.	Użyj `project-away` polecenia dla 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 zamieszanie lub są bardzo duże i mogą mieć wpływ na wydajność.
projekt	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ącego polecenia, aby usunąć pozostałe oryginalne pola, które nadal mają deskryptor typów:

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

Obsługa wariantów analizy

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 wymagające różnych logiki analizowania. Aby przeanalizować różne warianty w jednym analizatorze, użyj instrukcji warunkowych, takich jak iff i case, lub użyj 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 ma przeanalizować. Ponadto w razie potrzeby użyj opcji project-away w każdej gałęzi przed unią.

Wdrażanie analizatorów

Ręczne wdrażanie analizatorów przez skopiowanie ich na stronę dziennika usługi Azure Monitor i zapisanie zapytania jako funkcji. 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 do niego zapytanie. 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 programu PowerShell do usuwania funkcji.
Wdróż szablon przy użyciu witryny Azure Portal lub programu PowerShell.

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

Napiwek

Szablony usługi ARM mogą łączyć różne zasoby, dlatego analizatory mogą być wdrażane wraz z łącznikami, regułami analitycznymi lub listami obserwowanymi, 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, gdzie:

Analizator jest wdrażany.
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 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 istnieje kolumna [<Pole>]	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 [<Pole>] aliasu brakującej kolumny [<Pole>]	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 [<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`.

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

Informacje	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 [<Pole>] aliasu nieistniejącej kolumny [<Pole>]	Jeśli do analizatora zostanie dodane pole aliasu, pamiętaj o dodaniu tego aliasu.
Brak pola opcjonalnego [<Pole>]	Chociaż często brakuje pól opcjonalnych, warto przejrzeć listę, aby określić, czy którekolwiek z opcjonalnych pól można mapować ze źródła.
Dodatkowe pole nieznormalizowane [<Pole>]	Chociaż pola nieznormalizowane są prawidłowe, warto przejrzeć listę, aby określić, czy którekolwiek z nienormalizowanych wartości można zamapować na opcjonalne pole.

Uwaga

Błędy uniemożliwią poprawne 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 jest określony, puste nawiasy są potrzebne po nazwie funkcji.

Ten test intensywnie używa 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 dla zapytania przy użyciu selektora zakresu czasu.

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

Komunikat	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 analizator jest mapowany poprawnie, zaktualizuj analizator, aby przekształcić wartość źródłową na poprawny typ, wartość lub format. Zapoznaj się z listą typów logicznych, aby uzyskać więcej informacji na temat prawidłowych wartości i formatów dla każdego typu logicznego. 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 obowiązkowym polu [<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 lub 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 w przypadku zalecanego pola:

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

Uwaga

Błędy uniemożliwią poprawne 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. Jeśli zostanie zaakceptowana, analizatory będą dostępne dla każdego klienta jako wbudowane analizatory ASIM.

Aby współtworzyć analizatory:

Opracuj zarówno analizator filtrowania, jak i analizator 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 są pozostawione, należy je udokumentować 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 zaakceptowanych ostrzeżeń

Jeśli ostrzeżenia wymienione przez narzędzia do testowania ASIM są uznawane za prawidłowe dla analizatora, należy udokumentować zaakceptowane 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ą unikatowego identyfikowania komunikatu ostrzegawczego. 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, że przyszłe aktualizacje analizatora są zgodne 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 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 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 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 do nazwy uchwyt usługi GitHub, na przykład: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

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

Wyniki testów 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 pliku 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 tworzenie analizatorów ASIM.

Dowiedz się więcej o analizatorach ASIM:

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

Obejrzyj seminarium internetowe szczegółowe na temat analizatorów normalizacji usługi Microsoft Sentinel i znormalizowanej zawartości lub przejrzyj slajdy
Omówienie zaawansowanego modelu informacji o zabezpieczeniach (ASIM)
Schematy zaawansowanego modelu informacji o zabezpieczeniach (ASIM)
Zawartość usługi Advanced Security Information Model (ASIM)

Udostępnij za pośrednictwem

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łowego przy użyciu listy kontrolnej

Filtrowanie na podstawie parametrów analizatora

Optymalizacja filtrowania

Analiza

Normalizacji

Nazwy pól mapowania

Normalizacja formatu i typu pól

Pola pochodne i wartości

Pola wzbogacania

Wybieranie pól w zestawie wyników

Obsługa wariantów analizy

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 zaakceptowanych ostrzeżeń

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

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

Następne kroki

Opinia

Dodatkowe zasoby