Obsługa opóźnień pozyskiwania danych w zaplanowanych regułach analitycznych

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 pozyskiwać dane z różnych źródeł, czas pozyskiwania 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 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:

• Zwiększ okres retrospekcji. Intuicja podpowiada, że wydłużenie okresu wstecznego 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:

  

• Obsługa duplikowania. 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ść TimeGenerated zdarzenia znajduje się w obu okresach wyszukiwania wstecz, zdarzenie uruchamia dwa alerty. Musisz znaleźć sposób na rozwiązanie problemu duplikacji.

• Przypisz zdarzenie do określonego okresu wstecznego. W pierwszym przykładzie pominięto zdarzenia, ponieważ dane nie zostały pozyskane podczas uruchamiania 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ły look-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)

Więcej informacji na temat następujących elementów użytych w poprzednim przykładzie można znaleźć w dokumentacji usługi Kusto:

• let instrukcja
• where operator
• ago() funkcja

Oblicz opóźnienie importu

Domyślnie zaplanowane reguły alertów Microsoft Sentinel są skonfigurowane z 5-minutowym okresem retrospekcji. 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 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:

Następne kroki

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

• Tworzenie niestandardowych reguł analizy w celu wykrywania zagrożeń
• Dostosowywanie szczegółów alertów w Azure Sentinel
• Zarządzanie wersjami szablonów dla reguł zaplanowanej analizy w Azure Sentinel
• Korzystanie ze skoroszytu monitorowania kondycji
• Czas pozyskiwania danych dziennika w usłudze Azure Monitor