Obsługa wyników fałszywie dodatnich 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 Niestandardowe wykrycia to teraz ujednolicony sposób tworzenia reguł wykrywania w Microsoft Defender XDR.

Reguły analizy w Microsoft Sentinel powiadamiają Cię, gdy w sieci wystąpi coś podejrzanego. Żadna reguła analizy nie jest idealna i musisz uzyskać wyniki fałszywie dodatnie, które wymagają obsługi. W tym artykule opisano sposób obsługi wyników fałszywie dodatnich przy użyciu automatyzacji lub przez modyfikowanie reguł zaplanowanej analizy.

Fałszywie dodatnie przyczyny i zapobieganie

Nawet w poprawnie skompilowanej regule analizy wyniki fałszywie dodatnie często wynikają z określonych jednostek, takich jak użytkownicy lub adresy IP, które powinny zostać wykluczone z reguły.

Typowe scenariusze obejmują:

• Normalne działania niektórych użytkowników, zwykle głównych użytkowników (automatycznych tożsamości wykorzystywanych przez aplikacje i usługi), wykazują podejrzany wzorzec.
• Celowe działanie skanowania zabezpieczeń pochodzące ze znanych adresów IP jest wykrywane jako złośliwe.
• Reguła wykluczania prywatnych adresów IP powinna również wykluczać niektóre wewnętrzne adresy IP, które nie są prywatne.

W tym artykule opisano dwie metody unikania wyników fałszywie dodatnich:

• Reguły automatyzacji tworzą wyjątki bez modyfikowania reguł analizy.
• Modyfikacje reguł zaplanowanej analizy umożliwiają bardziej szczegółowe i trwałe wyjątki.

W poniższej tabeli opisano charakterystyki każdej metody:

Metoda	Charakterystyka
Reguły automatyzacji	Może mieć zastosowanie do kilku reguł analizy. Zachowaj dziennik inspekcji. Wyjątki natychmiast i automatycznie zamykają utworzone zdarzenia, rejestrując przyczynę zamknięcia i komentarze. Są często generowane przez analityków. Zezwalaj na stosowanie wyjątków przez ograniczony czas. Na przykład prace konserwacyjne mogą powodować fałszywie dodatnie wyniki, które poza okresem konserwacji byłyby prawdziwymi zdarzeniami.
Modyfikacje reguł analizy	Zezwalaj na zaawansowane wyrażenia logiczne i wyjątki oparte na podsieci. Umożliwia scentralizowanie zarządzania wyjątkami przy użyciu list kontrolnych. Zwykle wymagają wdrożenia przez inżynierów centrum operacji bezpieczeństwa (SOC). Są najbardziej elastycznym i kompletnym rozwiązaniem fałszywie dodatnim, ale są bardziej złożone.

Dodawanie wyjątków z regułami automatyzacji (tylko Azure Portal)

Poniższa procedura opisuje, jak dodać regułę automatyzacji , gdy zauważysz fałszywie pozytywny incydent. Ta procedura jest obsługiwana tylko w Azure Portal.

Jeśli Microsoft Sentinel jest dołączony do portalu usługi Defender, utwórz reguły automatyzacji od podstaw na podstawie szczegółów zdarzenia. Aby uzyskać więcej informacji, zobacz Automatyzowanie reagowania na zagrożenia w Microsoft Sentinel z regułami automatyzacji.

Aby dodać regułę automatyzacji do obsługi wyniku fałszywie dodatniego:

1. W Microsoft Sentinel w obszarze Zdarzenia wybierz zdarzenie, dla które chcesz utworzyć wyjątek.

2. W okienku szczegółów zdarzenia z boku wybierz pozycję Akcje > Utwórz regułę automatyzacji.

3. Na pasku bocznym Tworzenie nowej reguły automatyzacji opcjonalnie zmodyfikuj nową nazwę reguły, aby zidentyfikować wyjątek, a nie tylko nazwę reguły alertu.

4. W obszarze Warunki opcjonalnie dodaj więcej nazw reguł analizy, do których ma zostać zastosowany wyjątek. Wybierz pole rozwijane zawierające nazwę reguły analizy i wybierz z listy więcej reguł analizy.

5. Pasek boczny przedstawia określone jednostki w bieżącym zdarzeniu, które mogły spowodować wynik fałszywie dodatni. Zachowaj sugestie automatyczne lub zmodyfikuj sugerowane warunki, aby dostosować wyjątek. Na przykład można zmienić warunek adresu IP, który ma zostać zastosowany do całej podsieci.

   

6. Po spełnieniu warunków przewiń w dół w okienku bocznym, aby kontynuować definiowanie działania reguły:

   

   • Reguła jest już skonfigurowana do zamykania zdarzenia spełniającego kryteria wyjątku.
   • Możesz zachować określoną przyczynę zamknięcia w następujący sposób, jak jest, lub możesz ją zmienić, jeśli inny powód jest bardziej odpowiedni.
   • Możesz dodać komentarz do automatycznie zamkniętego incydentu, który wyjaśnia wyjątek. Można na przykład określić, że zdarzenie pochodzi ze znanego działania administracyjnego.
   • Domyślnie reguła wygasa automatycznie po 24 godzinach. Taki termin wygaśnięcia może być tym, czego potrzebujesz, i zmniejsza prawdopodobieństwo błędów fałszywie negatywnych. Jeśli chcesz mieć dłuższy wyjątek, ustaw opcję Wygaśnięcie reguły na później.

7. Jeśli chcesz, możesz dodać więcej akcji. Możesz na przykład dodać tag do zdarzenia lub uruchomić podręcznik w celu wysłania wiadomości e-mail lub powiadomienia lub synchronizacji z systemem zewnętrznym.

8. Wybierz pozycję Zastosuj , aby aktywować wyjątek.

Dodaj wyjątki poprzez modyfikację zapytań reguł analitycznych

Możesz także zaimplementować wyjątki, modyfikując zapytanie reguły analityki. Wyjątki można uwzględnić bezpośrednio w regule lub, jeśli to możliwe, użyć odwołania do listy obserwowanych. Następnie możesz zarządzać listą wyjątków na liście obserwowanych.

Modyfikowanie zapytania

Aby uzyskać szczegółowe instrukcje dotyczące tworzenia i edytowania reguł analizy za pomocą Kreatora reguł analizy , zobacz Tworzenie niestandardowych reguł analizy w celu wykrywania zagrożeń.

Aby edytować istniejące reguły analizy, wybierz pozycję Automatyzacja z menu nawigacji po lewej Microsoft Sentinel. Wybierz regułę, którą chcesz edytować, a następnie wybierz pozycję Edytuj w prawym dolnym rogu, aby otworzyć Kreatora reguł analizy.

Aby zaimplementować wyjątek w typowej preambuły reguły, można dodać warunek, taki jak where IPAddress !in ('<ip addresses>') na początku zapytania reguły. Ten wiersz wyklucza określone adresy IP z reguły.

let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in ('10.0.0.8', '192.168.12.1')
...

Ten typ wyjątku nie jest ograniczony do adresów IP. Możesz wykluczyć określonych użytkowników przy użyciu UserPrincipalName pola lub wykluczyć określone aplikacje przy użyciu polecenia AppDisplayName.

Można również wykluczyć wiele atrybutów. Aby na przykład wykluczyć alerty z adresu 10.0.0.8 IP lub użytkownika user@microsoft.com, użyj:

| where IPAddress !in ('10.0.0.8')
| where UserPrincipalName != 'user@microsoft.com'

Aby zaimplementować bardziej szczegółowy wyjątek, jeśli ma to zastosowanie, i zmniejszyć prawdopodobieństwo wystąpienia fałszywych negatywów, możesz połączyć atrybuty. Następujący wyjątek ma zastosowanie tylko wtedy, gdy obie wartości są wyświetlane w tym samym alercie:

| where IPAddress != '10.0.0.8' and UserPrincipalName != 'user@microsoft.com'

Wykluczanie podsieci

Wykluczenie zakresów adresów IP używanych przez organizację wymaga wykluczenia podsieci. W poniższym przykładzie pokazano, jak wykluczyć podsieci.

Operator ipv4_lookup jest operatorem wzbogacania, a nie operatorem filtrowania. Wiersz where isempty(network) rzeczywiście wykonuje filtrowanie, pozostawiając tylko zdarzenia, których adres IP nie pasuje do żadnego wpisu podsieci.

let subnets = datatable(network:string) [ "111.68.128.0/17", "5.8.0.0/19", ...];
let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| evaluate ipv4_lookup(subnets, IPAddress, network, return_unmatched = true)
| where isempty(network)
...

Zarządzanie wyjątkami przy użyciu list obserwowanych

Listę obserwowanych można użyć do zarządzania listą wyjątków spoza samej reguły. Jeśli ma to zastosowanie, to rozwiązanie ma następujące zalety:

• Analityk może dodawać wyjątki bez edytowania reguły, co lepiej jest zgodne z najlepszymi rozwiązaniami SOC.
• Ta sama lista kontrolna może mieć zastosowanie do kilku reguł, włączając centralne zarządzanie wyjątkami.

Korzystanie z listy obserwacyjnej jest podobne do korzystania z wyjątku bezpośredniego. Użyj polecenia _GetWatchlist('<watchlist name>') , aby wywołać listę obserwowanych:

let timeFrame = 1d;
let logonDiff = 10m;
let allowlist = (_GetWatchlist('ipallowlist') | project IPAddress);
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in (allowlist)
...

Filtrowanie podsieci można również wykonać przy użyciu listy obserwowanych. Na przykład w poprzednim kodzie wykluczeń podsieci można zastąpić definicję podsieci datatable listą obserwowanych:

let subnets = _GetWatchlist('subnetallowlist');

Aby uzyskać więcej informacji o operatorach i funkcjach Kusto używanych w przykładach zapytań wyjątków, zobacz dokumentację Kusto:

• let instrukcja
• where operator
• operator projektu
• operator datatable
• ocena operatora wtyczki
• ago() funkcja
• isempty() , funkcja
• ipv4_lookup wtyczka

Aby uzyskać więcej informacji na temat języka KQL, zobacz omówienie języka zapytań Kusto (KQL).

Inne zasoby:

• Krótkie informacje o języku KQL
• Materiały szkoleniowe dotyczące języka zapytań Kusto

Przykład: Zarządzanie wyjątkami dla rozwiązania Microsoft Sentinel dla aplikacji SAP®

Rozwiązanie Microsoft Sentinel dla aplikacji SAP® udostępnia funkcje, których można użyć do wykluczania użytkowników lub systemów z wyzwalania alertów.

• Wyklucz użytkowników. Użyj funkcji SAPUsersGetVIP , aby:

  • Tagi połączeń dla użytkowników, których chcesz wykluczyć z uruchamiania alertów. Otaguj użytkowników na liście obserwowanych SAP_User_Config , używając gwiazdki (*) jako symboli wieloznacznych, aby oznaczyć wszystkich użytkowników za pomocą określonej składni nazewnictwa.
  • Wyświetl listę określonych ról i/lub profilów SAP, które chcesz wykluczyć z wyzwalania alertów.

• Wyklucz systemy. Użyj funkcji, które obsługują parametr SelectedSystemRoles , aby określić, że tylko określone typy systemów wyzwalają alerty, w tym tylko systemy produkcyjne , tylko systemy UAT lub oba.

Aby uzyskać więcej informacji, zobacz Microsoft Sentinel rozwiązanie do dokumentacji danych aplikacji SAP®.

Zawartość pokrewna

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

• Analizowanie wyników fałszywie dodatnich przy użyciu danych UEBA
• Automatyzowanie obsługi zdarzeń w Microsoft Sentinel przy użyciu reguł automatyzacji
• Tworzenie niestandardowych reguł analizy w celu wykrywania zagrożeń
• Używanie list obserwowanych w usłudze Microsoft Sentinel