Obsługa wyników fałszywie dodatnich w Microsoft Sentinel

Ważna

Wykrywanie niestandardowe jest teraz najlepszym sposobem tworzenia nowych reguł w Microsoft Sentinel Microsoft Defender XDR SIEM. Dzięki wykrywaniu niestandardowemu można zmniejszyć koszty pozyskiwania, uzyskać nieograniczoną liczbę wykrywania w czasie rzeczywistym i korzystać z bezproblemowej integracji z Defender XDR danych, funkcji i akcji korygowania z automatycznym mapowaniem jednostek. Aby uzyskać więcej informacji, przeczytaj ten blog.

Microsoft Sentinel reguły analizy 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, zazwyczaj jednostki usługi, pokazują wzorzec, który wydaje się podejrzany.
• 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	Charakterystyczne
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ą implementacji przez inżynierów usługi Security Operations Center (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)

W tej procedurze opisano sposób dodawania reguły automatyzacji w przypadku wyświetlenia zdarzenia fałszywie dodatniego. 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 automatyczne sugestie lub zmodyfikuj je, 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. To wygaśnięcie może być pożądane i zmniejsza prawdopodobieństwo błędów fałszywie ujemnych. 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.

Dodawanie wyjątków przez modyfikowanie reguł analizy

Inną opcją implementowania wyjątków jest zmodyfikowanie zapytania reguły analizy. 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 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 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 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) faktycznie wykonuje filtrowanie, sprawdzając te zdarzenia, które nie pokazują dopasowania.

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.

Używanie listy obserwowanych jest podobne do używania bezpośredniego wyjątku. 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');

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

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

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

Inne zasoby:

• Krótkie informacje o języku KQL
• język zapytań Kusto zasobów szkoleniowych

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:

  • Wywoływanie tagów dla użytkowników, których chcesz wykluczyć z wyzwalania 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ń
• Korzystanie z Microsoft Sentinel list obserwowanych