Udostępnij za pośrednictwem


Obsługa opóźnienia pozyskiwania w zaplanowanych regułach analizy

Chociaż usługa Microsoft Sentinel może pozyskiwać dane z różnych źródeł, czas pozyskiwania danych dla każdego źródła danych może się różnić w różnych okolicznościach.

W tym artykule opisano, jak opóźnienie pozyskiwania może mieć wpływ na reguły zaplanowanej analizy i jak można je naprawić, aby pokryć te luki.

Dlaczego opóźnienie jest znaczące

Możesz na przykład napisać niestandardową regułę wykrywania, ustawiając zapytanie Uruchom co i Wyszukaj dane z ostatnich pól, aby reguła działała co pięć minut, wyszukując dane z tych ostatnich pięciu minut:

Zrzut ekranu przedstawiający Kreatora reguł analizy — okno Tworzenie nowej reguły.

Dane odnośnika z ostatniego pola definiują ustawienie znane jako okres wyszukiwania . Najlepiej, gdy nie ma opóźnienia, to wykrywanie nie przegapi żadnych zdarzeń, jak pokazano na poniższym diagramie:

Diagram przedstawiający pięciominutowe okno odnośnika.

Zdarzenie pojawia się w miarę jego generowania i jest uwzględniane w okresie wyszukiwania.

Teraz załóżmy, że źródło danych ma pewne opóźnienie. W tym przykładzie załóżmy, że zdarzenie zostało pozyskane dwie minuty po jego wygenerowaniu. Opóźnienie wynosi dwie minuty:

Diagram przedstawiający pięciominutowe okna z opóźnieniem dwóch minut.

Zdarzenie jest generowane w pierwszym okresie wyszukiwania, ale nie jest pozyskiwane w obszarze roboczym usługi Microsoft Sentinel w pierwszym uruchomieniu. Przy następnym uruchomieniu zaplanowanego zapytania pozyskuje zdarzenie, ale filtr wygenerowany czas usuwa zdarzenie, ponieważ stało się to ponad pięć minut temu. W takim przypadku reguła nie uruchamia alertu.

Jak obsługiwać opóźnienie

Uwaga

Problem można rozwiązać przy użyciu opisanego poniżej procesu lub zaimplementować reguły wykrywania niemal w czasie rzeczywistym (NRT) usługi Microsoft Sentinel. Aby uzyskać więcej informacji, zobacz Wykrywanie zagrożeń szybko za pomocą reguł analizy niemal w czasie rzeczywistym (NRT) w usłudze Microsoft Sentinel.

Aby rozwiązać ten problem, musisz znać opóźnienie dla typu danych. W tym przykładzie wiesz już, że opóźnienie wynosi dwie minuty.

W przypadku własnych danych możesz zrozumieć opóźnienie przy użyciu funkcji Kusto ingestion_time() i obliczyć różnicę między timeGenerated i czasem pozyskiwania. Aby uzyskać więcej informacji, zobacz Obliczanie opóźnienia pozyskiwania.

Po określeniu opóźnienia możesz rozwiązać problem w następujący sposób:

  • Zwiększ okres wyszukiwania. Podstawowa intuicja mówi, że zwiększenie rozmiaru okresu spojrzenia pomoże. Ponieważ okres wyszukiwania wstecz wynosi pięć minut, a opóźnienie wynosi dwie minuty, ustawienie okresu wyszukiwania na siedem minut pomoże rozwiązać ten problem. Na przykład w ustawieniach reguły:

    Zrzut ekranu przedstawiający ustawienie okna odnośnika na siedem minut.

    Na poniższym diagramie pokazano, jak okres look-pack zawiera teraz pominięte zdarzenie:

    Diagram przedstawiający siedmiominutowe okna z opóźnieniem dwóch minut.

  • Obsługa duplikacji. Tylko zwiększenie okresu wyszukiwania może spowodować duplikowanie, ponieważ okna odnośników teraz nakładają się na siebie. Na przykład inne zdarzenie może wyglądać tak, jak pokazano na poniższym diagramie:

    Diagram pokazujący, jak nakładające się okna odnośników tworzą duplikowanie.

    Ponieważ wartość TimeGenerated zdarzenia znajduje się w obu okresach wyszukiwania, zdarzenie uruchamia dwa alerty. Należy znaleźć sposób rozwiązywania duplikacji.

  • Skojarz zdarzenie z określonym okresem wyszukiwania. W pierwszym przykładzie pominięto zdarzenia, ponieważ dane nie zostały pozyskane podczas uruchamiania zaplanowanego zapytania. Rozszerzono spojrzenie wstecz, aby uwzględnić zdarzenie, ale spowodowało to duplikowanie. Musisz skojarzyć zdarzenie z oknem rozszerzonym, aby je zawierać.

    Zrób to, ustawiając ingestion_time() > ago(5m)wartość zamiast oryginalnej reguły look-back = 5m. To ustawienie kojarzy zdarzenie z pierwszym oknem odnośnika. Na przykład:

    Diagram przedstawiający sposób ustawiania ograniczeń ago unika duplikowania.

    Ograniczenie czasu pozyskiwania przycina teraz dodatkowe dwie minuty dodane do okresu wyszukiwania. W pierwszym przykładzie drugi okres wyszukiwania przebiegu przechwytuje teraz zdarzenie:

    Diagram pokazujący, jak ustawienie ograniczenia ago przechwytuje zdarzenie.

Następujące przykładowe zapytanie podsumowuje rozwiązanie do rozwiązywania problemów z opóźnieniami pozyskiwania:

let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)

Obliczanie opóźnienia pozyskiwania

Domyślnie zaplanowane reguły alertów usługi Microsoft Sentinel są skonfigurowane tak, aby miały 5-minutowy okres wyszukiwania. Jednak każde źródło danych może mieć własne, indywidualne opóźnienie pozyskiwania. Podczas łączenia wielu typów danych należy zrozumieć różne opóźnienia dla każdego typu danych, aby prawidłowo skonfigurować okres wyszukiwania.

Raport użycia obszaru roboczego, udostępniony w usłudze Microsoft Sentinel, zawiera pulpit nawigacyjny, który pokazuje opóźnienia i opóźnienia dla różnych typów danych przepływających do obszaru roboczego.

Na przykład:

Zrzut ekranu przedstawiający raport użycia obszaru roboczego przedstawiający opóźnienie końcowe według tabeli

Następne kroki

Aby uzyskać więcej informacji, zobacz: