Normalizacja czasu pozyskiwania

Analizowanie czasu zapytania

Podczas dyskusji w omówieniu usługi ASIM Microsoft Sentinel używa zarówno czasu zapytania, jak i normalizacji czasu pozyskiwania, aby skorzystać z zalet każdego z nich.

Aby użyć normalizacji czasu zapytania, użyj analizatorów ujednolicających czas zapytania, na przykład _Im_Dns w zapytaniach. Normalizacja przy użyciu analizowania czasu zapytania ma kilka zalet:

  • Zachowanie oryginalnego formatu: Normalizacja czasu zapytania nie wymaga modyfikacji danych, co zachowuje oryginalny format danych wysyłany przez źródło.
  • Unikanie potencjalnego zduplikowanego magazynu: ponieważ znormalizowane dane są tylko widokiem oryginalnych danych, nie ma potrzeby przechowywania zarówno oryginalnych, jak i znormalizowanych danych.
  • Łatwiejsze opracowywanie: Ponieważ analizatory czasu zapytań przedstawiają widok danych i nie modyfikują danych, można je łatwo opracować. Tworzenie, testowanie i naprawianie analizatora można wykonać na istniejących danych. Ponadto analizatory można rozwiązać, gdy problem zostanie wykryty, a poprawka zostanie zastosowana do istniejących danych.

Analizowanie czasu pozyskiwania

Analizatory czasu zapytań ASIM są zoptymalizowane, ale analizowanie czasu zapytań może spowolnić zapytania, szczególnie w przypadku dużych zestawów danych.

Analizowanie czasu pozyskiwania umożliwia przekształcanie zdarzeń do znormalizowanego schematu, ponieważ są pozyskiwane do Microsoft Sentinel i przechowywanie ich w znormalizowanym formacie. Analizowanie czasu pozyskiwania jest mniej elastyczne, a analizatory są trudniejsze do opracowania, ale ponieważ dane są przechowywane w znormalizowanym formacie, oferuje lepszą wydajność.

Znormalizowane dane mogą być przechowywane w natywnych znormalizowanych tabelach Microsoft Sentinel lub w tabeli niestandardowej używającej schematu ASIM. Tabela niestandardowa, która ma schemat zbliżony, ale nie identyczny, do schematu ASIM, zapewnia również korzyści z wydajności związane z normalizacją czasu pozyskiwania.

Obecnie usługa ASIM obsługuje następujące natywne znormalizowane tabele jako miejsce docelowe do normalizacji czasu pozyskiwania:

Zaletą natywnych tabel znormalizowanych jest to, że są one domyślnie uwzględniane w analizatorach ujednolicania ASIM. Niestandardowe znormalizowane tabele można uwzględnić w analizatorach ujednolicenia, jak opisano w temacie Zarządzanie analizatorami.

Łączenie czasu pozyskiwania i normalizacji czasu zapytania

Zapytania powinny zawsze używać analizatorów ujednolicania czasu zapytania, takich jak _Im_Dns wykorzystanie czasu zapytania i normalizacji czasu pozyskiwania. Natywne znormalizowane tabele są uwzględniane w danych zapytań przy użyciu analizatora wycinka.

Analizator wycinka jest analizatorem czasu zapytania, który używa jako danych wejściowych znormalizowana tabela. Ponieważ znormalizowana tabela nie wymaga analizowania, analizator wycinka jest wydajny.

Analizator wycinka przedstawia widok zapytania wywołującego, które dodaje do tabeli natywnej usługi ASIM:

  • Aliasy — aby nie marnować magazynu na powtarzające się wartości, aliasy nie są przechowywane w tabelach natywnych usługi ASIM i są dodawane w czasie wykonywania zapytań przez analizatory wycinków.
  • Wartości stałe — podobnie jak aliasy i z tego samego powodu tabele znormalizowane przez usługę ASIM również nie przechowują wartości stałych, takich jak EventSchema. Analizator wycinka dodaje te pola. Tabela znormalizowana przez usługę ASIM jest współużytkowana przez wiele źródeł, a analizatory czasu pozyskiwania mogą zmienić swoją wersję wyjściową. W związku z tym pola, takie jak EventProduct, EventVendor i EventSchemaVersion , nie są stałe i nie są dodawane przez analizator wycinka.
  • Filtrowanie — analizator wycinka implementuje również filtrowanie. Chociaż tabele natywne usługi ASIM nie wymagają analizatorów filtrowania, aby osiągnąć lepszą wydajność, filtrowanie jest potrzebne do obsługi dołączania do analizatora ujednolicenia.
  • Aktualizacje i poprawki — użycie analizatora wycinka umożliwia szybsze rozwiązywanie problemów. Jeśli na przykład dane zostały pozyskane niepoprawnie, adres IP mógł nie zostać wyodrębniony z pola komunikatu podczas pozyskiwania. Adres IP może zostać wyodrębniony przez analizator wycinka w czasie wykonywania zapytania.

W przypadku korzystania z niestandardowych znormalizowanych tabel utwórz własny analizator wycinka w celu zaimplementowania tej funkcji i dodaj ją do analizatorów ujednolicających, jak opisano w temacie Zarządzanie analizatorami. Użyj analizatora wycinka dla tabeli natywnej, na przykład analizatora wycinka tabeli natywnej DNS i jego odpowiednika filtrowania, jako punktu początkowego. Jeśli tabela jest częściowo znormalizowana, użyj analizatora wycinka, aby wykonać wymagane dodatkowe analizy i normalizację.

Dowiedz się więcej na temat pisania analizatorów w temacie Tworzenie analizatorów ASIM.

Implementowanie normalizacji czasu pozyskiwania

Aby znormalizować dane podczas pozyskiwania, należy użyć reguły zbierania danych (DCR). Procedura implementowania dcr zależy od metody używanej do pozyskiwania danych. Aby uzyskać więcej informacji, zobacz artykuł Transform or customize data at ingestion time in Microsoft Sentinel (Przekształcanie lub dostosowywanie danych w czasie pozyskiwania w Microsoft Sentinel).

Zapytanie przekształcania KQL jest rdzeniem dcr. Wersja KQL używana w kontrolerach DOMENY jest nieco inna niż wersja używana gdzie indziej w Microsoft Sentinel w celu spełnienia wymagań przetwarzania zdarzeń potoku. W związku z tym należy zmodyfikować dowolny analizator czasu zapytania, aby używać go w funkcji DCR. Aby uzyskać więcej informacji na temat różnic i sposobu konwertowania analizatora czasu zapytania na analizator czasu pozyskiwania, przeczytaj o ograniczeniach KQL dcr.

Następne kroki

Więcej informacji można znaleźć w następujących artykułach:

  • Last updated on