Rozwiązywanie problemów z regułami analizy w Microsoft Sentinel

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 ten blog.

W tym artykule wyjaśniono, jak radzić sobie z pewnymi problemami, które mogą wystąpić podczas wykonywania reguł zaplanowanej analizy w Microsoft Sentinel.

Problem: Żadne zdarzenia nie są wyświetlane w wynikach zapytania

Gdy grupowanie zdarzeń jest ustawione na wyzwalanie alertu dla każdego zdarzenia, wyniki zapytania wyświetlane w późniejszym czasie mogą wydawać się brakujące lub inne niż oczekiwano. Na przykład możesz wyświetlić wyniki zapytania w późniejszym czasie podczas badania powiązanego zdarzenia, a w ramach tego badania zdecydujesz się wrócić do wcześniejszych wyników tego zapytania.

Wyniki są automatycznie zapisywane przy użyciu alertów. Jeśli jednak wyniki są zbyt duże, żadne wyniki nie są zapisywane i podczas ponownego wyświetlania wyników zapytania nie są wyświetlane żadne dane.

W przypadkach, gdy występuje opóźnienie pozyskiwania lub zapytanie nie jest deterministyczne z powodu agregacji, wynik alertu może być inny niż wynik pokazany przez ręczne uruchomienie zapytania.

Aby rozwiązać ten problem, gdy reguła ma to ustawienie grupowania zdarzeń, Microsoft Sentinel dodaje pole OriginalQuery do wyników zapytania. Oto porównanie istniejącego pola Zapytanie i nowego pola:

Nazwa pola Zawiera Uruchamianie zapytania w tym polu
wyniki w...
Zapytanie Skompresowany rekord zdarzenia, które wygenerowało to wystąpienie alertu. Zdarzenie, które wygenerowało to wystąpienie alertu;
ograniczone do 10 kilobajtów.
OriginalQuery Oryginalne zapytanie zapisane w regule analizy. Najnowsze zdarzenie w przedziale czasowym, w którym jest uruchamiane zapytanie, które pasuje do parametrów zdefiniowanych przez zapytanie.

Innymi słowy, pole OriginalQuery zachowuje się tak, jakby pole Zapytanie działało w domyślnym ustawieniu grupowania zdarzeń.

Problem: Nie udało się wykonać zaplanowanej reguły lub jej nazwa zawiera dodany dopisek AUTO DISABLED

Rzadko się zdarza, aby reguła zapytania według harmonogramu nie została uruchomiona, ale może się to zdarzyć. Microsoft Sentinel klasyfikuje błędy z góry jako przejściowe lub trwałe na podstawie określonego typu awarii i okoliczności, które do niej doprowadziły.

Błąd przejściowy

Przejściowa awaria występuje z powodu okoliczności, która jest tymczasowa i wkrótce wróci do normy, w którym to momencie wykonanie reguły zakończy się pomyślnie. Oto kilka przykładów awarii, które Microsoft Sentinel klasyfikuje jako przejściowe:

  • Wykonywanie zapytania reguły trwa zbyt długo i przekracza limit czasu.
  • Problemy z łącznością między źródłami danych i usługą Log Analytics lub między usługą Log Analytics i Microsoft Sentinel.
  • Każda inna nowa i nieznana awaria jest uważana za przejściową.

W przypadku wystąpienia błędu przejściowego Microsoft Sentinel nadal próbuje ponownie wykonać regułę w z góry określonych, stopniowo wydłużających się odstępach czasu, ale tylko do pewnego momentu. Następnie reguła zostanie uruchomiona ponownie tylko o następnej zaplanowanej godzinie. Reguła nigdy nie jest automatycznie wyłączana z powodu przejściowej awarii.

Trwała awaria — reguła wyłączona automatycznie

Trwałe niepowodzenie występuje z powodu zmiany warunków, które zezwalają na uruchomienie reguły, która bez interwencji człowieka nie może powrócić do poprzedniego stanu. Poniżej przedstawiono kilka przykładów błędów sklasyfikowanych jako trwałe:

  • Docelowy obszar roboczy (na którym działało zapytanie reguły) został usunięty.
  • Tabela docelowa (na której działało zapytanie reguły) została usunięta.
  • Microsoft Sentinel został usunięty z docelowego obszaru roboczego.
  • Funkcja używana w zapytaniu reguły nie jest już prawidłowa; została zmodyfikowana lub usunięta.
  • Uprawnienia do jednego ze źródeł danych zapytania reguły zostały zmienione (zobacz przykład).
  • Jedno ze źródeł danych zapytania reguły zostało usunięte.

W przypadku wstępnie określonej liczby kolejnych trwałych błędów tego samego typu i tej samej reguły Microsoft Sentinel przestaje próbować wykonać regułę, a także wykonuje następujące kroki:

  1. Wyłącza regułę.
  2. Dodaje wyrazy "AUTO DISABLED" na początku nazwy reguły.
  3. Dodaje przyczynę niepowodzenia (oraz wyłączenia) do opisu reguły.

Możesz łatwo sprawdzić, czy występują reguły automatycznie wyłączone, sortując listę reguł według nazwy. Reguły automatycznie wyłączone znajdują się na górze listy lub w jej pobliżu.

Menedżerowie SOC powinni regularnie sprawdzać listę reguł pod kątem obecności reguł automatycznie wyłączonych.

Trwałe niepowodzenie z powodu opróżniania zasobów

Inny rodzaj trwałego błędu występuje z powodu nieprawidłowo utworzonego zapytania , które powoduje, że reguła zużywa nadmierne zasoby obliczeniowe i grozi wyczerpaniem wydajności w systemach. Gdy Microsoft Sentinel identyfikuje taką regułę, wykonuje te same trzy kroki wymienione w przypadku innych typów trwałych błędów — wyłącza regułę, poprzedza "AUTO DISABLED" do nazwy reguły i dodaje przyczynę niepowodzenia do opisu.

Aby ponownie włączyć regułę, należy rozwiązać problemy w zapytaniu, które powodują użycie zbyt wielu zasobów. Więcej informacji można znaleźć w następujących artykułach:

Trwałe niepowodzenie z powodu utraty dostępu w subskrypcjach/dzierżawach

Jeden z konkretnych przykładów wystąpienia trwałego błędu z powodu zmiany uprawnień w źródle danych (zobacz listę) dotyczy przypadku dostawcy rozwiązań zabezpieczeń firmy Microsoft (MSSP) lub dowolnego innego scenariusza, w którym reguły analizy wysyłają zapytania dotyczące subskrypcji lub dzierżaw.

Podczas tworzenia reguły analizy token uprawnień dostępu jest stosowany do reguły i zapisywany wraz z nią. Ten token gwarantuje, że reguła może uzyskiwać dostęp do obszaru roboczego zawierającego tabele, do których odwołuje się zapytanie reguły, oraz że ten dostęp jest utrzymywany nawet wtedy, gdy twórca reguły utraci dostęp do tego obszaru roboczego.

Jest jednak jeden wyjątek: gdy zostanie utworzona reguła umożliwiająca dostęp do obszarów roboczych w innych subskrypcjach lub dzierżawach, na przykład w przypadku dostawcy mssp, Microsoft Sentinel podejmuje dodatkowe środki bezpieczeństwa, aby zapobiec nieautoryzowanemu dostępowi do danych klientów. Tego rodzaju reguły używają poświadczeń użytkownika, który je utworzył, a nie niezależnego tokenu dostępu. Gdy użytkownik nie ma już dostępu do innego dzierżawcy, reguła przestaje działać.

Jeśli korzystasz z usługi Microsoft Sentinel w scenariuszu obejmującym wiele subskrypcji lub wiele dzierżaw, a jeden z Twoich analityków lub inżynierów utraci dostęp do określonego obszaru roboczego, wszelkie reguły utworzone przez tego użytkownika przestaną działać. Otrzymasz komunikat monitorowania kondycji o „niewystarczającym dostępie do zasobu”, a reguła zostanie automatycznie wyłączona zgodnie z opisaną wcześniej procedurą.

Następne kroki

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

Dowiedz się również na przykładzie użycia niestandardowych reguł analitycznych podczas monitorowania Zoom za pomocą łącznika niestandardowego.