Tworzenie i publikowanie reguł analizy dla rozwiązań usługi Microsoft Sentinel

Reguły analizy usługi Microsoft Sentinel są zestawami kryteriów. Definiują one sposób monitorowania danych, wykrytych danych i akcji wykonywanych po spełnieniu określonych warunków. Te reguły pomagają identyfikować podejrzane zachowanie, anomalie i potencjalne zagrożenia bezpieczeństwa, analizując dzienniki i sygnały z różnych źródeł danych.

Reguły analizy usługi Microsoft Sentinel to zaawansowane narzędzia zwiększające poziom zabezpieczeń organizacji, ponieważ aktywnie wykrywają potencjalne zagrożenia i reagują na nie. Stosując ustrukturyzowane podejście do tworzenia tych reguł i zarządzania nimi, organizacje mogą korzystać z możliwości usługi Microsoft Sentinel, aby chronić swoje zasoby cyfrowe i utrzymywać niezawodną infrastrukturę zabezpieczeń. Aby uzyskać więcej informacji, zobacz Wykrywanie zagrożeń w usłudze Microsoft Sentinel.

W tym artykule przedstawiono proces tworzenia i publikowania reguł analizy w rozwiązaniach usługi Microsoft Sentinel.

Przypadki użycia reguł analizy usługi Microsoft Sentinel

Reguły analizy usługi Microsoft Sentinel można zastosować do szerokiej gamy scenariuszy w celu zwiększenia monitorowania zabezpieczeń i wykrywania zagrożeń. Typowe przypadki użycia to:

• Wykrywanie włamań: zidentyfikuj nieautoryzowane próby dostępu lub podejrzane działania logowania, które mogą wskazywać na potencjalne naruszenie.
• Wykrywanie złośliwego oprogramowania: monitoruj znane sygnatury złośliwego oprogramowania lub nietypowe zachowanie, które może sugerować obecność złośliwego oprogramowania.
• Eksfiltracja danych: wykrywanie dużych lub nietypowych transferów danych, które mogą oznaczać, że dane są eksfiltrowane z sieci.
• Zagrożenia wewnętrzne: zidentyfikuj nietypowe zachowanie użytkowników wewnętrznych, takie jak uzyskiwanie dostępu do poufnych danych poza normalnymi godzinami lub wzorcami.
• Monitorowanie zgodności: zapewnianie zgodności z wymaganiami prawnymi przez monitorowanie określonych działań lub wzorców dostępu.
• Wyszukiwanie zagrożeń: proaktywnie wyszukuje wskaźniki naruszenia zabezpieczeń lub innych oznak złośliwej aktywności w sieci.
• Naruszenie zabezpieczeń konta: wykrywanie oznak naruszenia zabezpieczeń kont użytkowników, takich jak nietypowe wzorce logowania geograficznego lub wiele nieudanych prób logowania.
• Anomalie sieci: zidentyfikuj nietypowe wzorce ruchu sieciowego, które mogą wskazywać na obecność zagrożenia lub błędnej konfiguracji.
• Eskalacja uprawnień: monitoruj próby uzyskania podwyższonych uprawnień w sieci, co może być prekursorem dalszych złośliwych działań.
• Zabezpieczenia punktu końcowego: Upewnij się, że punkty końcowe są bezpieczne, wykrywając odchylenia od normalnego zachowania lub obecności nieautoryzowanego oprogramowania.

Tworzenie i publikowanie reguł analizy

Reguły analizy są tworzone w formacie YAML . Skorzystaj z poniższych przykładów reguł analizy jako odwołań, aby utworzyć własne:

• Microsoft Entra ID — FailedLogonToAzurePortal.yaml
• CrowdStrike Falcon — CriticalOrHighSeverityDetectionsByUser.yaml
• XBOW — XbowCriticalHighFindings.yaml

W poniższych sekcjach przedstawiono szczegółowy przewodnik po różnych atrybutach reguły analizy.

Przykładowa reguła analizy

Poniżej przedstawiono przykładową regułę analizy w formacie YAML.

id: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
name: Anomalous login from unknown IP
description: |
  Identifies login attempts from IP addresses not seen in the past 14 days.
severity: Medium
requiredDataConnectors:
  - connectorId: ContosoMyProduct
    dataTypes:
      - ContosoMyProduct_CL
queryFrequency: 1h
queryPeriod: 14d
triggerOperator: gt
triggerThreshold: 0
tactics:
  - InitialAccess
relevantTechniques:
  - T1078
status: Available
query: |
  ContosoMyProduct_CL
  | where TimeGenerated > ago(1h)
  | where EventType == "Login"
  | summarize count() by SrcIpAddr, UserName
  | extend Name = tostring(split(UserName, '@', 0)[0])
  | extend UPNSuffix = tostring(split(UserName, '@', 1)[0])
entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: Name
        columnName: Name
      - identifier: UPNSuffix
        columnName: UPNSuffix
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: SrcIpAddr
version: 1.0.0
kind: Scheduled

identyfikator

Atrybut id składa się ze standardowego identyfikatora globalnie unikatowego (GUID). Wygeneruj go przy użyciu dowolnego narzędzia programistycznego, generatora online lub nowego polecenia cmdlet new-GUID programu PowerShell. Musi być unikatowy wśród innych identyfikatorów GUID.

To pole jest obowiązkowe.

Rodzaj

Atrybut kind reprezentuje typ reguły.

Istnieją dwie akceptowane wartości: scheduled i NRT (niemal w czasie rzeczywistym). Wartość scheduled wymaga zdefiniowania innych właściwości, w tym queryFrequency, , queryPeriodtriggerThresholdi triggerOperator. W przypadku reguł NRT pomiń queryFrequency, queryPeriod, triggerOperator i triggerThreshold.

To pole jest obowiązkowe.

Name

Atrybut name zawiera krótką etykietę, która podsumowuje wykrywanie. Upewnij się, że etykieta jest jasna i zwięzła, aby ułatwić użytkownikom zrozumienie przeznaczenia reguły. Służy alertDetailsOverride do generowania nazw dynamicznych, aby pomóc analitykom zrozumieć alert. Ten atrybut:

• Używa kapitalizacji na początku zdania.
• Nie kończy się kropką.
• Ma zalecaną długość poniżej 50 znaków i bezwzględne maksimum 100 znaków.
• Unika słów „Suspicious” i „Suspect”. Zamiast tego użyj opcji "Nieoczekiwane", "Anomalous" lub "Rzadkie".

To pole jest obowiązkowe.

Description

Atrybut description zawiera szczegółowy opis wykrywania. Opis zawiera informacje na temat wykrytego zachowania, potencjalnego efektu i wszelkich zalecanych akcji. Ten atrybut:

• Używa kapitalizacji typu zdaniowego.
• Rozpoczyna się zdaniem "To zapytanie wyszukuje" lub "Identyfikuje".
• Jest różne i bardziej opisowe niż pole nazwowe.
• Ma maksymalną długość 255 znaków.
• Ma pięć zdań lub mniej.
• Nie opisuje źródła danych (łącznika lub typu danych).
• Nie zawiera technicznego wyjaśnienia języka zapytań.
• Używa tylko znaków ASCII. Półpauzy, inteligentne cudzysłowy i inne znaki spoza ASCII nie przechodzą walidacji.

To pole jest obowiązkowe.

Severity

Atrybut severity definiuje poziom ważności wykrywania. Ważność odzwierciedla potencjalny wpływ wykrytego zachowania i pilność odpowiedzi.

• Informacyjny: Zdarzenie może nie reprezentować bezpośrednio zagrożenia bezpieczeństwa, ale może być interesujące dla dalszego dochodzenia lub dodać kontekst albo świadomość sytuacyjną dla analityka.
• Niski: Efekt natychmiastowy jest minimalny, a aktor zagrożenia musiałby wykonać wiele kroków przed osiągnięciem wpływu na środowisko.
• Medium: Aktor zagrożenia może osiągnąć pewien wpływ na środowisko z tym działaniem, ale efekt byłby ograniczony w zakresie lub wymaga dodatkowej aktywności.
• Wysoki: Zidentyfikowane działanie zapewnia aktorowi zagrożeń szeroki dostęp do wykonywania działań w środowisku.

Status

Atrybut status wskazuje gotowość produkcyjną reguły:

• Available: Reguły gotowe do wdrożenia produkcyjnego.
• InPreview: Zasady wersji beta.
• Deprecated: Reguły są wycofywane.

Wymagane łączniki danych

Atrybut reprezentuje listę łączników danych, które reguła requiredDataConnectors musi działać poprawnie, w tym źródła danych, względem których reguła wykonuje zapytania. Jeśli nie ma bieżącego mapowania łącznika danych, należy użyć otwartego nawiasu klamrowego: requiredDataConnectors: [].

Atrybut connectorId określa identyfikator potrzebnego łącznika danych, aby zapytanie działało poprawnie. Jeśli zapytanie wykrywania zależy od danych pobranych z określonego łącznika, musisz określić tutaj identyfikator łącznika. Jeśli na przykład reguła analizy zależy od danych z tego łącznika, musisz określić wartość connectorID jako 1PasswordCCPDefinition.

Atrybut dataTypes reprezentuje typy danych, od których zależy reguła analizy, i wymienia nazwę typu danych, do którego odwołuje się dataTypes sekcja łącznika. Na przykład, jeśli twoje zapytanie łowieckie zależy od danych z tego łącznika, musisz określić typ danych jako OnePasswordEventLogs_CL. Jeśli zapytanie łowieckie działa na funkcji Kusto/analizatorze zamiast tabeli (na przykład Syslog, CommonEventFormat i _CL), dataTypes jest nazwą funkcji Kusto/nazwą analizatora, a nie nazwą tabeli.

Okres zapytania

Atrybut queryPeriod reprezentuje określony okres, w którym jest uruchamiane zapytanie. Na przykład: ostatnie 3 dni. Dla tego atrybutu:

• Użyj formatu język zapytań Kusto (KQL) TimeSpan (na przykład 3 dni to 3d, 2 godziny to 2h).
• Upewnij się, że w tym przedziale czasu znajduje się dowolny okres szkoleniowy lub referencyjny.
• Nie używaj wartości wyższej niż maksymalna obsługiwana wartość, czyli 14d.

To pole jest obowiązkowe dla zaplanowanych reguł analizy.

Częstotliwość zapytań

Atrybut queryFrequency reprezentuje częstotliwość uruchamiania zapytania. Dla tego atrybutu:

• Użyj formatu KQL TimeSpan (na przykład 3 dni to 3d, 2 godziny to 2h).
• Użyj wartości mniejszej queryFrequency niż lub równej queryPeriod.
• Postępuj zgodnie z tą regułą: jeśli queryPeriod wartość jest większa lub równa 2 dni (2d), queryFrequency wartość nie może być mniejsza niż 1 godzina (1h) i jest używana tylko do wykrywania o wysokiej ważności.

To pole jest obowiązkowe dla zaplanowanych reguł analizy.

Operator wyzwalacza

Atrybut triggerOperator wskazuje mechanizm wyzwalający alert. Na przykład: większy niż (gt) liczba ustawiona w atrybucie triggerThreshold (zobacz próg wyzwalania).

• gt: Większe niż.
• lt: Mniej niż.
• eq: równe to.

To pole jest obowiązkowe dla zaplanowanych reguł analizy.

Próg wyzwalacza

Atrybut triggerThreshold reprezentuje próg, który wyzwala alert. Wartość progowa to wartość, na którą triggerOperator się odwołuje. Obsługiwane wartości obejmują dowolną liczbę całkowitą z zakresu od 0 do 10 000.

Jeśli na przykład triggerOperator jest ustawiony na gt i triggerThreshold ma 1, alert jest wyzwalany, gdy wartość jest większa niż 1.

To pole jest obowiązkowe dla zaplanowanych reguł analizy.

Tactics

Atrybut tactics definiuje element MITRE ATT&CK tactics, do którego odnosi się wykrywanie. Podczas definiowania taktyki pomaga użytkownikom zrozumieć kontekst wykrywania i dopasować go do ogólnego poziomu zagrożeń. Dla tego atrybutu:

• ATT&CK Framework v16 jest obsługiwany.
• Nazwy używają pascalcase i nie mogą zawierać spacji. Na przykład: InitialAccess lub LateralMovement.
• Maksymalnie pięć taktyk można zdefiniować na regułę.
• Prawidłowe wartości to: Reconnaissance, ResourceDevelopment, InitialAccess, Execution, Persistence, PrivilegeEscalation, DefenseEvasion, CredentialAccess, Discovery, LateralMovement, Collection, CommandAndControl, Exfiltration i Impact.

To pole jest obowiązkowe.

Odpowiednie techniki

Atrybut relevantTechniques definiuje element MITRE ATT&CK techniques, do którego odnosi się wykrywanie. Podczas definiowania technik pomaga ona użytkownikom zrozumieć kontekst wykrywania i jak pasuje do ogólnego poziomu zagrożeń. Dla tego atrybutu:

• ATT&CK Framework v16 jest obsługiwany.
• Każda technika musi należeć do co najmniej jednego z wymienionych tactics.
• Nazwy nie mogą zawierać spacji. Na przykład: T1078 lub T1078.001.
• Maksymalnie 10 technik można zdefiniować na regułę.

To pole jest obowiązkowe.

Query

Atrybut query definiuje logikę wykrywania. Zalecamy napisanie zapytania w języku KQL i upewnienie się, że jest ono ustrukturyzowane i łatwe do zrozumienia. Zalecamy utworzenie wydajnego zapytania zoptymalizowanego pod kątem wydajności, aby upewnić się, że można je uruchamiać względem dużych zestawów danych bez wpływu na wydajność. Upewnij się, że zapytanie spełnia następujące kryteria.

Ogranicz zapytanie do 10 000 znaków. Jeśli sekcja zapytania przekroczy ten limit, rozważ zmniejszenie liczby znaków. Statyczna lista elementów używanych do porównania w treści zapytania może spowodować przekroczenie limitu. Zalecamy przeniesienie tych list do jednej z następujących opcji:

• Funkcja listy obserwowanych
• Niestandardowy plik JSON/CSV
• Funkcja niestandardowa

Każdy wiersz w treści zapytania musi mieć co najmniej jedną spację na początku, ale dwie spacje są standardowe, aby obsługiwać czytelność.

Po przesłaniu zapytania dotyczącego typu danych, który nie znajduje się w folderze Detections or Hunting Query, nazwij podfolder zawierający pliki YAML po zapytaniu do tabeli. Jeśli na przykład zapytanie dotyczy AzureDevOpsAuditing tabeli, utwórz folder o nazwie AzureDevOpsAuditing.

Zdefiniuj nazwy czytelne dla jawnych stałych:

• let FailedLoginEventID = 4625;
• let countThreshold = 6;

Zdecydowanie zalecamy używanie komentarzy w celu wyjaśnienia zapytania. Unikaj dodawania komentarzy na końcu wiersza instrukcji zapytania. Zamiast tego dodaj komentarze w osobnym wierszu. Przykład:

  // Removing noisy processes for an environment, adjust as needed

Jeśli odwołujesz się do analizatora zamiast nazwy tabeli, upewnij się, że opis jest czytelny, dołączając komentarz obok odwołania funkcji analizatora. Analizator należy najpierw zaimportować do obszaru roboczego. W przeciwnym razie zapytania nie rozpoznają ich jako prawidłowe.

Upewnij się, że każde dostępne pole jednostki jest zwracane do celów mapowania. (Zapoznaj się z sekcją Mapowania jednostek). Zdezynfikuj zwróconą tabelę tak, aby udostępniała tylko właściwości, które należy dokładniej zbadać. Nie potrzebujesz filtru TimeGenerated , gdy używasz prostego lookback polecenia w całym zapytaniu. Wartość queryPeriod w yaML kontroluje ten proces.

W przypadku ustalania bazowej linii odniesienia lub przeprowadzania porównania historycznego, takiego jak porównanie dzisiejszego dnia z poprzednimi siedmioma dniami, dołącz filtr z ograniczeniem czasowym, taki jak | where TimeGenerated >= ago(lookback), ponieważ szablon YAML nie obsługuje obecnie wielu wartości queryPeriod. Unikaj używania przedziałów czasowych krótszych niż jeden dzień, chyba że istnieje konkretny powód. Nie zalecamy ram czasowych dłuższych niż 14 dni ze względu na potencjalny wpływ na wydajność.

Podsumuj w razie potrzeby. Upewnij się, że pole czasu (zwykle TimeGenerated) jest uwzględniane, ponieważ jest ono potrzebne w polu jednostki. Uwzględnij wartości min() oraz max() w następujący sposób: | summarize StartTime = max(TimeGenerated), EndTime = min(TimeGenerated). Użyj warunków StartTime i EndTime wyłącznie. Nie przypisuj polom nazw StartTimeUtc ani EndTimeUtc, ponieważ te nazwy mogą powodować konflikt z preferencjami doświadczenia użytkownika.

Ponadto uwzględnij jak najwięcej pól, aby ułatwić użytkownikowi zrozumienie kontekstu alertu. Zalecamy uwzględnienie co najmniej jednej z podstawowych jednostek: Host, lub AccountIP.

Nazwy kolumn w niestandardowej tabeli muszą być zapisane w notacji camelCase (na przykład SrcIpAddr lub UserName).

To pole jest obowiązkowe.

Ustawienia grupowania zdarzeń

Atrybut eventGroupingSettings odnosi się do alertów. Reguła alertu może wygenerować oddzielny alert dla każdego wyniku zapytania. Na przykład reguła identyfikująca alerty firmy innej niż Microsoft w strumieniu zdarzeń może utworzyć alert usługi Microsoft Sentinel dla każdego alertu źródłowego.

• Aby utworzyć pojedynczy alert dla wszystkich wyników zapytania (wartość domyślna), użyj:

  eventGroupingSettings:
  aggregationKind: SingleAlert
  

• Aby utworzyć oddzielny alert dla każdego wyniku zapytania, użyj:

  eventGroupingSettings:
  aggregationKind: AlertPerResult
  

Mapowania jednostek

Atrybut entityMappings jest integralny podczas konfigurowania zaplanowanych reguł analizy. Wzbogaca on dane wyjściowe zapytania (alerty i zdarzenia) o podstawowe informacje, które służą jako bloki konstrukcyjne wszelkich procesów śledczych i działań naprawczych, które następują.

Obiekt entityType reprezentuje standardową listę jednostek rozpoznawanych przez usługę Microsoft Sentinel. Obsługiwane typy obejmują Account, HostIPURLFileProcessDNSAzureResourceFileHashRegistryKeyRegistryValueSecurityGroupMailboxi .MailMessage Zobacz dozwolone wartości w kolumnie Typ jednostki w tabeli mapowania jednostek.

To pole jest obowiązkowe.

Mapowania pól

Atrybut fieldMappings reprezentuje identyfikator pola w danych wyjściowych zapytania, które odpowiada typowi jednostki. Zobacz dozwolone wartości pod kolumną identyfikatorów w tabeli mapowania jednostek. Dla tego atrybutu:

• Każdy szablon może mieć maksymalnie 10 mapowań jednostek.

• Każde mapowanie jednostek może mieć maksymalnie trzy mapowania pól (czyli identyfikatory).

  entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: FullName
        columnName: AccountCustomEntity
  - entityType: Host
    fieldMappings:
      - identifier: FullName
        columnName: HostCustomEntity
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: ClientIP
  - entityType: DNS
    fieldMappings:
      - identifier: DomainName
        columnName: Name
  
  

Szczegóły niestandardowe

Atrybut customDetails integruje dane zdarzeń z alertami, dzięki czemu jest widoczny w zdarzeniach zabezpieczeń w celu szybszego klasyfikowania, badania i reagowania. Szczegóły dostosowane to pary klucz/wartość, które odnoszą się do nazw właściwości i kolumn. Aby uzyskać więcej informacji, zobacz Szczegóły zdarzeń niestandardowych w alertach usługi Microsoft Sentinel. Można zdefiniować maksymalnie 20 niestandardowych szczegółów (czyli par klucz/wartość) dla szablonu. Nazwy kluczy muszą zawierać maksymalnie 20 znaków.

    customDetails:
      Computers: Computer
      IPs: ComputerIP

Przesłonięcia szczegółów alertu

Atrybut alertDetailsOverride jest polem dynamicznym, którego można użyć do zastąpienia szczegółów alertu. Możesz użyć tego atrybutu, aby podać więcej kontekstu lub informacji analitykowi po wyzwoleniu alertu. W przypadku korzystania z tej funkcji upewnij się, że analitycy otrzymują odpowiednie informacje, w tym odpowiednie nazwy jednostek, aby ułatwić szybsze i dokładniejsze zrozumienie zdarzenia. Ograniczenia obejmują:

• Maksymalnie trzy parametry można uwzględnić w elemecie name lub description.

• Długość name nie może przekraczać 256 znaków, a długość znaków description jest ograniczona do 5000 znaków.

• Nazwa kolumny w nawiasach klamrowych musi dokładnie odpowiadać oczekiwanej nazwie kolumny bez żadnego wiodącego lub końcowego odstępu (na przykład {{columnName}}, a nie {{ columnName }}). W poniższym przykładzie pola columnName1, columnName2, dynamicTactici dynamicSeverity są polami wyjściowymi zaplanowanego zapytania alertu.

      alertDetailsOverride:
        alertDisplayNameFormat: free text with field names embedded using the format {{columnName}} # Up to 256 chars and 3 placeholders
        alertDescriptionFormat: free text with field names embedded using the format  {{columnName}} # Up to 5000 chars and 3 placeholders
        alertTacticsColumnName: dynamicTacticColumnName
        alertSeverityColumnName: dynamicSeverityColumnName
  
  

      alertDetailsOverride:
        alertDisplayNameFormat: rule {{columnName1}} display name
        alertDescriptionFormat: rule {{columnName2}} display name
        alertTacticsColumnName: dynamicTactic
        alertSeverityColumnName: dynamicSeverity
  

Konfiguracja zdarzenia

Atrybut incidentConfiguration steruje tworzeniem zdarzeń i grupowaniem alertów w zdarzenia. Służy do definiowania sposobu agregowania alertów generowanych przez tę regułę w zdarzeniach.

wersja

Gdy klient utworzy nowe zapytanie wyszukiwania zagrożeń na podstawie szablonu, szablon version zostanie zapisany. Jeśli zostanie opublikowana nowa wersja szablonu, klienci będą powiadamiani w środowisku użytkownika. Wersje są zgodne z formatem a, bi c, w którym a jest wersja główna, b jest wersją pomocniczą i c jest poprawką. Pole wersji jest ostatnim wierszem szablonu.

To pole jest obowiązkowe.