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. Analizatory ujednolicające z kolei wykorzystują analizatory specyficzne dla źródła, aby obsłużyć konkretne szczegóły 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 zgodne ze schematem ASIM, ale parser specyficzny dla źródła dla tego urządzenia i odpowiedniego schematu 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. 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:

  1. Zbierz przykładowe logi.

  2. Zidentyfikuj schematy lub schematy, które reprezentują zdarzenia wysyłane ze źródła. Aby uzyskać więcej informacji, zobacz Omówienie schematu.

  3. Zamapuj pola zdarzeń źródłowych na zidentyfikowany schemat lub schematy.

  4. Utwórz co najmniej jeden analizator ASIM dla źródła. Konieczne będzie opracowanie parsera filtrującego oraz parsera bezparametrowego dla każdego schematu powiązanego ze źródłem.

  5. Przetestuj analizator.

  6. Wdrożyć parsery do obszarów roboczych Microsoft Sentinel.

  7. Zaktualizuj odpowiedni parser normalizujący ASIM, aby odwoływał się do nowego parsera niestandardowego. Aby uzyskać więcej informacji, zobacz Zarządzanie analizatorami ASIM.

  8. Możesz również przekazać swoje parsery do głównej dystrybucji ASIM. Dodane analizatory mogą być również udostępnione we wszystkich obszarach roboczych jako wbudowane analizatory.

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

Zbieranie przykładowych dzienników

Aby utworzyć skuteczne analizatory ASIM, potrzebny jest reprezentatywny zestaw dzienników, który w większości przypadków wymaga 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 odnalezienie dokumentacji dostawcy i przykładów dotyczących dzienników może pomóc przyspieszyć tworzenie oraz ograniczyć liczbę błędów dzięki zapewnieniu szerokiej obsługi formatów dzienników.

Reprezentatywny zestaw dzienników powinien obejmować:

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

Wskazówka

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.

Planowanie mapowania

Przed opracowaniem 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 w ramach wybranego schematu, rozważ mapowanie pól dostępnych w innych schematach.
  • Przypisz wartości pól w źródle do znormalizowanych wartości dopuszczonych przez ASIM. Oryginalna wartość jest przechowywana w oddzielnym polu, takim jak EventOriginalResultDetails.

Opracowywanie analizatorów

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

Parser niestandardowy to zapytanie KQL utworzone na stronie Logs w Microsoft Sentinel. Zapytanie analizatora ma trzy części:

Filtrowanie>Parsowanie>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 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 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

Important

Analizator nie powinien filtrować według czasu. Zapytanie korzystające z parsera uwzględni 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 zezwalają na filtrowanie dla określonych typów źródeł.

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ł definiujących odpowiednie zdarzenia. Ta lista jest podtrzymywana na liście obserwacyjnej Sources_by_SourceType.

Aby użyć listy obserwacyjnej ASimSourceType w parserach, użyj funkcji _ASIM_GetSourceBySourceType w sekcji filtrowania parsera. 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 parserze:

  • Zastąp Computer nazwą pola, które zawiera informacje o źródle. Możesz pozostawić to jako Computer dla analizatorów opartych na standardzie Syslog.

  • Zastąp token InfobloxNIOS wartością wybraną przez siebie dla swojego parsera. Poinformuj użytkowników parsera, że muszą zaktualizować ASimSourceType listę obserwowanych przy użyciu wybranej wartości oraz listę źródeł wysyłających tego typu zdarzenia.

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 prawidłowy podpis funkcji. W większości przypadków rzeczywisty kod filtrowania jest również podobny w parserach filtrujących 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 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 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 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 nadal wstępnie filtrować dane za pomocą operatora optymalizującego wydajność na polu wbudowanym, a po sparsowaniu ponownie zastosować filtrowanie przy użyciu dokładniejszych warunków.

Aby zapoznać się z przykładem, zobacz poniższy fragment kodu analizatora DNS infoblox . Analizator najpierw sprawdza, czy pole has SyslogMessage zawiera słowo 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"

Note

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

Parsowanie

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/funkcja() Description
split() , funkcja Przeanalizuj ciąg rozdzielonych wartości.
funkcja parse_csv() Przeanalizuj ciąg wartości sformatowanych jako wiersz CSV (wartości rozdzielane przecinkami).
operator parse-kv Wyodrębnia ustrukturyzowane informacje z wyrażenia tekstowego i przedstawia te informacje w formacie klucz/wartość.
Operator parsowania 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 podobną wydajność do parse, jeśli ten ostatni 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żywanie wielu aktywacji extract dla tego samego ciągu źródłowego jest mniej wydajne niż pojedyncza aktywacja parse lub extract_all i należy tego unikać.
funkcja parse_json() Przeanalizuj wartości w ciągu sformatowanym jako JSON. Jeśli z pliku JSON potrzebnych jest tylko kilka wartości, użycie parse, 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, extractlub extract_all zapewnia lepszą wydajność.

Normalizowanie

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 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,

Normalizacja formatu i typu pól

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

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 daty/godziny. Funkcje takie jak todatetime i tohex są przydatne w tych 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 użyj 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 wymagać przypisania do zestawu 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 pole EventResult na podstawie identyfikatora zdarzenia i kodu odpowiedzi, używając 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 zgłaszają numeryczne kody odpowiedzi DNS i protokół sieciowy, podczas gdy schemat nakazuje bardziej typową reprezentację etykiet tekstowych dla obu tych typów. Poniższy przykład pokazuje, jak wyznaczyć wymagane wartości za pomocą 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 i case. Powyższy przykład lookup zwraca pustą wartość w polu DnsResponseCodeName, jeśli wartość wyszukiwania nie zostanie znaleziona. Poniższy przykład case uzupełnia go, wykorzystując wynik operacji lookup, jeśli jest on dostępny, a w przeciwnym razie określając dodatkowe warunki.

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

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


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

Pierwsza opcja przyjmuje wartość do wyszukania jako parametr, umożliwia wybór pola wyjściowego i jest więc przydatna jako ogólna funkcja wyszukiwania. 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 do wzbogacania

Oprócz pól dostępnych ze źródła, wynikowe zdarzenie ASIM powinno obejmować pola wzbogacające, które powinien generować 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 rodzajem pól wzbogacania, które analizatory powinny ustawiać, są pola typu, które określają typ wartości przechowywanej w powiązanym polu. Na przykład pole SrcUsernameType wyznacza typ wartości przechowywanej w polu SrcUsername. Więcej informacji o polach 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ś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 danych. 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:

Dziedzina komputerów 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łniając powiązane pola Dst 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 poprawić wydajność i zwiększyć jasność poprzez uniknięcie mylenia znormalizowanych pól z pozostałymi polami źródłowymi.

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

Obsługujący Description Kiedy używać tego w analizatorze składniowym
project-away Usuwa pola. Użyj project-away dla konkretnych pól, które chcesz usunąć ze zbioru 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 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ą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 parsowania

Important

Różne warianty reprezentują różne typy zdarzeń, zwykle mapowane na różne schematy; opracuj oddzielne parsery

W wielu przypadkach zdarzenia w strumieniu zdarzeń obejmują warianty, które wymagają innej logiki analizy. 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 przy użyciu pól natywnych, tylko zdarzeń, które mają zostać przeanalizowane. Ponadto, w razie potrzeby, użyj opcji project-away w każdej gałęzi przed połączeniem.

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 analizatorów ARM w następujący sposób:

  1. 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.

  2. Użyj konwertera ASIM YAML na szablon ARM, aby przekonwertować plik YAML na szablon ARM.

  3. W przypadku wdrażania aktualizacji usuń starsze wersje funkcji przy użyciu portalu lub narzędzia programu PowerShell do usuwania funkcji.

  4. Wdróż szablon przy użyciu portalu Azure lub PowerShell.

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

Wskazówka

Szablony ARM mogą łączyć różne zasoby, więc parsery mogą być wdrażane razem z łącznikami, regułami analitycznymi lub listami obserwacyjnymi, to tylko kilka z przydatnych opcji. Na przykład parser może odwoływać się do listy obserwacyjnej wdrożonej razem z nim.

Testowanie parserów

W tej sekcji opisano, że narzędzia do testowania ASIM zapewniają możliwość testowania analizatorów. To powiedziawszy, parsery to kod, czasem złożony, dlatego oprócz automatycznych testów zaleca się również stosowanie standardowych praktyk zapewniania jakości, takich jak przeglądy kodu.

Instalowanie narzędzi testowych ASIM

Aby przetestować kartę ASIM, wdróż narzędzie do testowania karty ASIM do obszaru roboczego Microsoft Sentinel, w którym:

  • Twój 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 Microsoft Sentinel Logs.

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

Z wynikami należy postępować w następujący sposób:

Błąd Action
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 wymaganego aliasu [<Field>] będącego aliasem istniejącej kolumny [<Field>] Dodaj alias do parsera
Brak zalecanego aliasu [<Field>] dla istniejącej kolumny [<Field>] Dodaj alias do parsera
Brak opcjonalnego aliasu [<Field>] aliasującego istniejącą kolumnę [<Field>] Dodaj alias do parsera
Brak obowiązkowego aliasu [<Pole>] nadającego alias brakującej kolumnie [<Pole>] Temu błędowi towarzyszy podobny błąd dotyczący pola z aliasem. Popraw błąd pola z aliasem i dodaj ten alias do parsera.
Niezgodność typów dla pola [<pole>]. Jest obecnie w postaci [<Type>] i powinien być w postaci [<Type>] Upewnij się, że typ znormalizowanego pola jest poprawny, zwykle przy użyciu funkcji konwersji , takiej jak tostring.
Informacje Action
Brak zalecanego pola [<Pole>] Rozważ dodanie tego pola do analizatora.
Informacje Action
Brak zalecanego aliasu [<Pole>] aliasowanie nieistniejącej kolumny [<Pole>] Jeśli dodasz pole aliasowane do analizatora, pamiętaj również o dodaniu tego aliasu.
Brak opcjonalnego aliasu [<Pole>] wskazującego na nieistniejącą kolumnę [<Pole>] Jeśli dodasz pole aliasowane do analizatora, pamiętaj również 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>] 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.

Note

Błędy uniemożliwią poprawne 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 jest używane do identyfikowania schematu, do którego powinno być zgodne 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.

Note

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 przekroczy limitu czasu, lub ustaw zakres czasu zapytania przy użyciu selektora zakresu czasu.

Z wynikami należy postępować w następujący sposób:

Message Action
(0) Błąd: niezgodność typu dla kolumny [<Pole>]. Jest obecnie w postaci [<Type>] i powinien być w postaci [<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 właściwie zmapowano, zaktualizuj analizator, aby przekształcić wartość źródłową na poprawny 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 próbkę 10 nieprawidłowych wartości.
(1) Ostrzeżenie: Pusta wartość w obowiązkowym polu [<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) Informacja: Pusta wartość w zalecanym polu [<Pole>] Zalecane pola zazwyczaj powinny być wypełnione. 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, oraz 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ć wariant zdarzenia, który nie został poprawnie przeanalizowany.
  • Kilka pustych wartości może być znikomym problemem.

Note

Błędy uniemożliwią poprawne 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ółtwórz parsery

Możesz chcieć wnieść analizator składni do głównej dystrybucji ASIM. Jeśli zostaną zaakceptowane, analizatory będą dostępne dla każdego klienta jako wbudowane w ASIM analizatory.

Aby dodać swoje parsery:

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ą komunikatu ostrzegawczego, jednoznacznie go identyfikującą. 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 zapewniania zgodności przyszłych aktualizacji analizatora ze starszymi przykładami. Przesyłane przykłady powinny zawierać dowolny wariant zdarzenia, który obsługuje 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 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 spowoduje wyświetlenie schematu lub tabeli wejściowej 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 PR w folderze /Sample Data/ASIM. Jeśli plik już istnieje, dodaj swoją nazwę użytkownika GitHub do nazwy, 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 parsera opisane w sekcji testings.

  • 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 PR w folderze /Parsers/ASim<schema>/Tests.

Treści powiązane

Dowiedz się więcej o analizatorach ASIM:

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

  • Last updated on