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

W tym artykule wyjaśniono, jak rozwiązywać pewne problemy, które mogą wystąpić podczas wykonywania zaplanowanych reguł analizy w usłudze Microsoft Sentinel.

Problem: Brak zdarzeń wyświetlanych w wynikach zapytania

Gdy ustawienie grupowania zdarzeń powoduje wyzwolenie 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 wyniki zapytania można wyświetlić w późniejszym czasie podczas badania powiązanego zdarzenia, a w ramach tego badania zdecydujesz się wrócić do wcześniejszych wyników zapytania.

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

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

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

Nazwa pola	Contains	Uruchamianie zapytania w tym polu wyniki...
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 napisane w regule analizy.	Ostatnie zdarzenie w przedziale czasowym, w którym jest uruchamiane zapytanie, pasujące do parametrów zdefiniowanych przez zapytanie.

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

Problem: Nie można uruchomić reguły planowania lub jest wyświetlana z dodanym elementem AUTO DISABLED do nazwy

Rzadko zdarza się, że nie można uruchomić zaplanowanej reguły zapytania, ale może się zdarzyć. Usługa 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 doprowadziły do niego.

Błąd przejściowy

Przejściowy błąd występuje z powodu okoliczności, które są tymczasowe i wkrótce wracają do normalnego, w którym momencie wykonanie reguły powiedzie się. Oto kilka przykładów błędów klasyfikujących usługę Microsoft Sentinel jako przejściowych:

• Zapytanie reguły trwa zbyt długo, aby uruchomić i upłynął limit czasu.
• Problemy z łącznością między źródłami danych a usługą Log Analytics lub między usługą Log Analytics i usługą Microsoft Sentinel.
• Wszelkie inne nowe i nieznane błędy są uznawane za przejściowe.

W przypadku awarii przejściowej usługa Microsoft Sentinel nadal próbuje wykonać regułę ponownie po wstępnie określonych i stale rosnących interwałach do punktu. Następnie reguła zostanie uruchomiona ponownie tylko w następnym zaplanowanym czasie. Reguła nigdy nie jest automatycznie dystrybuowana z powodu błędu przejściowego.

Trwałe niepowodzenie — reguła autodisabled

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

• Docelowy obszar roboczy (na którym działa zapytanie reguły) został usunięty.
• Tabela docelowa (na której działa zapytanie reguły) została usunięta.
• Usługa Microsoft Sentinel została usunięta z docelowego obszaru roboczego.
• Funkcja używana przez zapytanie reguły nie jest już prawidłowa; został zmodyfikowany lub usunięty.
• Zmieniono uprawnienia do jednego ze źródeł danych zapytania reguły (zobacz przykład).
• Usunięto jedno ze źródeł danych zapytania reguły.

W przypadku wstępnie określonej liczby kolejnych trwałych niepowodzeń tego samego typu i w tej samej regule usługa Microsoft Sentinel przestaje próbować wykonać regułę, a także wykonuje następujące czynności:

1. Wyłącza regułę.
2. Dodaje wyrazy "AUTO DISABLED" na początku nazwy reguły.
3. Dodaje przyczynę błędu (i wyłączenie) do opisu reguły.

Możesz łatwo określić obecność dowolnych reguł autodisabled, sortując listę reguł według nazwy. Reguły autodisabled znajdują się w górnej części listy lub w górnej części listy.

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

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

Inny rodzaj trwałej awarii występuje z powodu nieprawidłowo utworzonego zapytania , które powoduje, że reguła zużywa nadmierne zasoby obliczeniowe i stanowi drenaż wydajności w systemach. Gdy usługa Microsoft Sentinel zidentyfikuje taką regułę, wykonuje te same trzy kroki wymienione dla innych typów trwałych awarii — wyłącza regułę, poprzedza "AUTO DISABLED" nazwą reguły i dodaje przyczynę niepowodzenia opisu.

Aby ponownie włączyć regułę, należy rozwiązać problemy w zapytaniu, które powodują użycie zbyt wielu zasobów. Zapoznaj się z następującymi artykułami, aby uzyskać najlepsze rozwiązania dotyczące optymalizowania zapytań Kusto:

• Najlepsze rozwiązania dotyczące zapytań — Azure Data Explorer
• Optymalizowanie zapytań dziennika w usłudze Azure Monitor

Aby uzyskać dalszą pomoc, zobacz Przydatne zasoby do pracy z język zapytań Kusto w usłudze Microsoft Sentinel.

Trwałe niepowodzenie z powodu utraty dostępu między subskrypcjami/dzierżawami

Jeden z konkretnych przykładów, gdy może wystąpić trwałe niepowodzenie 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 zapewnia, że reguła może uzyskać 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 jeśli twórca reguły utraci dostęp do tego obszaru roboczego.

Istnieje jednak jeden wyjątek: gdy reguła jest tworzona w celu uzyskiwania dostępu do obszarów roboczych w innych subskrypcjach lub dzierżawach, takich jak to, co się dzieje w przypadku programu MSSP, usługa Microsoft Sentinel podejmuje dodatkowe środki zabezpieczeń, aby zapobiec nieautoryzowanemu dostępowi do danych klienta. Tego rodzaju reguły mają poświadczenia użytkownika, który utworzył dla nich regułę, zamiast niezależnego tokenu dostępu. Gdy użytkownik nie ma już dostępu do innego dzierżawy, reguła przestanie działać.

Jeśli korzystasz z usługi Microsoft Sentinel w scenariuszu między subskrypcjami lub między dzierżawami, a jeśli jeden z analityków lub inżynierów utraci dostęp do określonego obszaru roboczego, wszystkie reguły utworzone przez tego użytkownika przestaną działać. Otrzymasz komunikat monitorowania kondycji dotyczący "niewystarczającego dostępu do zasobu", a reguła zostanie automatycznie usunięta zgodnie z procedurą opisaną wcześniej.

Następne kroki

Aby uzyskać więcej informacji, zobacz:

• Samouczek: badanie zdarzeń za pomocą usługi Microsoft Sentinel
• Nawigowanie po zdarzeniach i badanie ich w usłudze Microsoft Sentinel — wersja zapoznawcza
• Klasyfikowanie i analizowanie danych przy użyciu jednostek w usłudze Microsoft Sentinel
• Samouczek: używanie podręczników z regułami automatyzacji w usłudze Microsoft Sentinel

Zapoznaj się również z przykładem używania niestandardowych reguł analizy podczas monitorowania funkcji Zoom przy użyciu łącznika niestandardowego.