Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ważna
Niestandardowe wykrycia są teraz najlepszym sposobem na tworzenie nowych reguł w usługach Microsoft Sentinel SIEM i Microsoft Defender XDR. Dzięki niestandardowym regułom wykrywania można obniżyć koszty pozyskiwania danych, uzyskać nieograniczoną liczbę wykryć w czasie rzeczywistym oraz korzystać z bezproblemowej integracji z danymi, funkcjami i akcjami korygowania w usłudze Defender XDR dzięki automatycznemu mapowaniu encji. Aby uzyskać więcej informacji, przeczytaj Niestandardowe wykrycia to teraz ujednolicony sposób tworzenia reguł wykrywania w Microsoft Defender XDR.
Chociaż Microsoft Sentinel może pobierać dane z połączonych źródeł, czas pobierania danych dla każdego źródła danych może się różnić w zależności od okoliczności.
W tym artykule opisano, jak opóźnienie pozyskiwania danych może wpływać na zaplanowane reguły analityczne i jak można je dostosować, aby uwzględniały te luki.
Dlaczego opóźnienie jest znaczące
Na przykład możesz napisać niestandardową regułę wykrywania, ustawiając pola Uruchamiaj zapytanie co i Przeszukuj dane z ostatnich tak, aby reguła była uruchamiana co pięć minut i przeszukiwała dane z tych ostatnich pięciu minut:
Dane wyszukiwania z ostatniego pola określają ustawienie znane jako okres wsteczny. Najlepiej, gdy nie ma opóźnienia, to wykrywanie nie pomija żadnych zdarzeń, jak pokazano na poniższym diagramie:
Zdarzenie pojawia się w miarę jego generowania i jest uwzględniane w okresie wyszukiwania wstecznego .
Teraz załóżmy, że istnieje pewne opóźnienie dla źródła danych. W tym przykładzie załóżmy, że zdarzenie zostało pozyskane dwie minuty po jego wygenerowaniu. Opóźnienie wynosi dwie minuty:
Zdarzenie jest generowane w pierwszym analizowanym okresie wstecznym, ale podczas pierwszego uruchomienia nie zostaje zaimportowane do obszaru roboczego Microsoft Sentinel. Następnym razem, gdy zaplanowane zapytanie zostanie uruchomione, pobiera zdarzenie, ale filtr oparty na czasie wygenerowania usuwa je, ponieważ wystąpiło ponad pięć minut temu. W takim przypadku reguła nie uruchamia alertu.
Jak obsługiwać opóźnienie
Użyj następującego podejścia, aby uwzględnić opóźnienie wczytywania danych w zaplanowanych regułach analitycznych.
Uwaga
Problem można rozwiązać przy użyciu opisanego poniżej procesu lub zaimplementować reguły wykrywania w czasie niemal rzeczywistym (NRT) Microsoft Sentinel. Aby uzyskać więcej informacji, zobacz Szybkie wykrywanie zagrożeń przy użyciu reguł analizy niemal w czasie rzeczywistym (NRT) w 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.
Dla własnych danych możesz określić opóźnienie przy użyciu funkcji Kusto ingestion_time() i obliczyć różnicę między TimeGenerated a czasem pozyskania. Aby uzyskać więcej informacji, zobacz Obliczanie opóźnienia pozyskiwania.
Po określeniu opóźnienia możesz rozwiązać ten problem w następujący sposób:
Wydłuż okres retrospektywy: Podstawowa intuicja podpowiada, że zwiększenie rozmiaru okresu retrospektywy pomoże. Ponieważ okres wyszukiwania wstecz wynosi pięć minut, a opóźnienie wynosi dwie minuty, ustawienie okresu wyszukiwania wstecz na siedem minut pomoże rozwiązać ten problem. Na przykład w ustawieniach reguły:
Na poniższym diagramie pokazano, jak okres pakietu look-pack zawiera teraz pominięte zdarzenie:
* Zajmij się duplikacją: Tylko wydłużenie okresu retrospekcji może powodować duplikaty, ponieważ okna retrospekcji nakładają się teraz na siebie. Na przykład inne zdarzenie może wyglądać tak, jak pokazano na poniższym diagramie:
Ponieważ wartość zdarzenia TimeGenerated pojawia się w obu okresach wstecznego, zdarzenie wywołuje dwa alerty. Musisz znaleźć sposób na rozwiązanie problemu duplikacji.
Powiązaj zdarzenie z określonym okresem wstecznego: W pierwszym przykładzie przegapiłeś zdarzenia, ponieważ Twoje dane nie zostały pobrane podczas zaplanowanego zapytania. Rozszerzyłeś okres wsteczny tak, aby uwzględnić zdarzenie, ale spowodowało to duplikację. Musisz przypisać zdarzenie do okna, które rozszerzono, aby je zawierało.
Zrób to, ustawiając
ingestion_time() > ago(5m)zamiast oryginalnej regułylook-back = 5m. To ustawienie przypisuje zdarzenie do pierwszego okna wstecznego. Przykład:
Ograniczenie czasu przyjmowania danych usuwa teraz dodatkowe dwie minuty dodane do okresu wstecznego przeszukiwania. A w pierwszym przykładzie okres wsteczny drugiego przebiegu teraz wychwytuje zdarzenie:
Poniższe przykładowe zapytanie podsumowuje rozwiązanie problemów z opóźnieniami pozyskiwania danych:
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)
Zobacz więcej informacji o następujących elementach użytych w poprzednim przykładzie w dokumentacji Kusto:
Oblicz opóźnienie importu
Domyślnie reguły zaplanowanych alertów Microsoft Sentinel są skonfigurowane tak, aby miały pięciominutowy okres wstecznego. Jednak każde źródło danych może mieć własne, indywidualne opóźnienie pobierania. Podczas łączenia wielu typów danych należy zrozumieć różne opóźnienia dla każdego typu danych, aby poprawnie skonfigurować okres wyszukiwania wstecz.
Raport użycia obszaru roboczego, dostępny domyślnie w usłudze Microsoft Sentinel, zawiera pulpit, który pokazuje latencję i opóźnienia dla różnych typów danych napływających do Twojego obszaru roboczego.
Przykład:
