Erstellen und Veröffentlichen von Analyseregeln für Microsoft Sentinel Lösungen

Microsoft Sentinel Analyseregeln sind Kriteriensätze. Sie definieren, wie Daten überwacht werden, was erkannt wird und welche Aktionen ausgeführt werden, wenn bestimmte Bedingungen erfüllt sind. Diese Regeln helfen, verdächtiges Verhalten, Anomalien und potenzielle Sicherheitsbedrohungen zu identifizieren, indem Protokolle und Signale aus verschiedenen Datenquellen analysiert werden.

Microsoft Sentinel Analyseregeln sind leistungsstarke Tools zur Verbesserung des Sicherheitsstatus eines organization, da sie potenzielle Bedrohungen proaktiv erkennen und darauf reagieren. Durch die Verwendung eines strukturierten Ansatzes zum Erstellen und Verwalten dieser Regeln können Organisationen die Funktionen von Microsoft Sentinel nutzen, um ihre digitalen Ressourcen zu schützen und eine stabile Sicherheitsinfrastruktur aufrechtzuerhalten. Weitere Informationen finden Sie unter Bedrohungserkennung in Microsoft Sentinel.

Dieser Artikel führt Sie durch den Prozess zum Erstellen und Veröffentlichen von Analyseregeln für Microsoft Sentinel Lösungen.

Anwendungsfälle für Microsoft Sentinel Analyseregeln

Microsoft Sentinel Analyseregeln können auf eine Vielzahl von Szenarien angewendet werden, um die Sicherheitsüberwachung und Bedrohungserkennung zu verbessern. Zu den gängigen Anwendungsfällen gehören:

  • Angriffserkennung: Identifizieren Sie nicht autorisierte Zugriffsversuche oder verdächtige Anmeldeaktivitäten, die auf eine potenzielle Sicherheitsverletzung hinweisen könnten.
  • Erkennung von Schadsoftware: Überwachen Sie auf bekannte Schadsoftwaresignaturen oder ungewöhnliches Verhalten, das auf das Vorhandensein von Schadsoftware hindeuten könnte.
  • Datenexfiltration: Erkennen Sie große oder ungewöhnliche Datenübertragungen, die darauf hindeuten können, dass Daten aus dem Netzwerk exfiltriert werden.
  • Insider-Bedrohungen: Identifizieren Sie anomales Verhalten interner Benutzer, z. B. den Zugriff auf vertrauliche Daten außerhalb der normalen Zeiten oder Muster.
  • Complianceüberwachung: Stellen Sie die Einhaltung gesetzlicher Anforderungen sicher, indem Sie bestimmte Aktivitäten oder Zugriffsmuster überwachen.
  • Bedrohungssuche: Suchen Sie proaktiv nach Anzeichen für eine Gefährdung oder anderen Anzeichen für schädliche Aktivitäten im Netzwerk.
  • Kompromittierung des Kontos: Erkennen Sie Anzeichen dafür, dass Benutzerkonten kompromittiert sind, z. B. ungewöhnliche geografische Anmeldemuster oder mehrere fehlgeschlagene Anmeldeversuche.
  • Netzwerkanomalien: Identifizieren Sie ungewöhnliche Netzwerkdatenverkehrsmuster, die auf das Vorhandensein einer Bedrohung oder einer Fehlkonfiguration hinweisen können.
  • Rechteausweitung: Überwachen Sie, ob versucht wird, erhöhte Berechtigungen innerhalb des Netzwerks zu erlangen, was ein Vorläufer für weitere schädliche Aktivitäten sein kann.
  • Endpunktsicherheit: Stellen Sie sicher, dass Endpunkte sicher sind, indem Sie Abweichungen vom normalen Verhalten oder das Vorhandensein von nicht autorisierter Software erkennen.

Erstellen und Veröffentlichen von Analyseregeln

Sie erstellen Analyseregeln im YAML-Format . Sie können dieses Beispiel einer Analyseregel als Referenz verwenden, um Ihre eigenen Abfragen zu erstellen: Beispielanalyseregel in GitHub.

Die folgenden Abschnitte enthalten eine ausführliche exemplarische Vorgehensweise für verschiedene Attribute einer Analyseregel.

ID

Das id Attribut besteht aus einer standardmäßigen GUID (Globally Unique Identifier). Generieren Sie sie mithilfe eines beliebigen Entwicklungstools, eines Onlinegenerators oder des neuen PowerShell-Cmdlets New-GUID. Sie muss unter anderen GUIDs eindeutig sein.

Dieses Feld ist obligatorisch.

Art

Das kind -Attribut stellt den Typ der Regel dar.

Es gibt zwei akzeptierte Werte: scheduled und NRT (nahezu in Echtzeit). Der scheduled Wert erfordert, dass Sie andere Eigenschaften definieren, einschließlich queryFrequency, queryPeriod, triggerThresholdund triggerOperator.

Dieses Feld ist obligatorisch.

Name

Das name Attribut stellt eine kurze Bezeichnung bereit, die die Erkennung zusammenfasst. Stellen Sie sicher, dass die Bezeichnung klar und prägnant ist, damit Benutzer den Zweck der Regel besser verstehen können. Verwenden Sie alertDetailsOverride , um dynamische Namen zu generieren, damit Analysten die Warnung besser verstehen können. Dieses Attribut:

  • Verwendet großgeschriebene Sätze.
  • Endet nicht mit einem Punkt.
  • Hat eine maximale Länge von 50 Zeichen (wann immer möglich).

Dieses Feld ist obligatorisch.

Beschreibung

Das description -Attribut enthält eine detaillierte Beschreibung der Erkennung. Die Beschreibung enthält Informationen zum erkannten Verhalten, zum potenziellen Effekt und zu allen empfohlenen Aktionen. Dieses Attribut:

  • Verwendet großgeschriebene Sätze.
  • Beginnt mit "Diese Abfrage sucht nach" oder "Identifiziert".
  • Ist anders und aussagekräftiger als das Namensfeld.
  • Hat eine maximale Länge von 255 Zeichen.
  • Ist fünf Sätze oder weniger.
  • Beschreibt nicht die Datenquelle (Connector oder Datentyp).
  • Bietet keine technische Erklärung für die Abfragesprache.

Dieses Feld ist obligatorisch.

Severity

Das severity -Attribut definiert den Schweregrad der Erkennung. Der Schweregrad spiegelt die potenziellen Auswirkungen des erkannten Verhaltens und die Dringlichkeit der Antwort wider.

  • Informativ: Der Vorfall stellt möglicherweise nicht direkt eine Sicherheitsbedrohung dar, ist aber für folgebezogene Untersuchungen oder die Sensibilisierung eines Analysten in Kontext oder Situation von Interesse.
  • Niedrig: Die unmittelbare Auswirkung ist minimal, und ein Bedrohungsakteur muss mehrere Schritte ausführen, bevor er eine Auswirkung auf eine Umgebung erzielt.
  • Mittel: Der Bedrohungsakteur könnte mit dieser Aktivität eine gewisse Auswirkung auf die Umgebung erzielen, aber der Effekt wäre im Umfang begrenzt oder erfordert zusätzliche Aktivitäten.
  • Hoch: Die identifizierte Aktivität bietet dem Bedrohungsakteur weitreichenden Zugriff auf die Durchführung von Aktionen in der Umgebung.

Hinweis

Die Standardwerte des Schweregrads sind keine Garantie für die aktuelle Auswirkungsstufe oder umgebungswirksam. Der Schweregrad gilt nur für Microsoft Sentinel-Analysevorlagen. Andernfalls steuert der Sicherheitsdienst, der die Warnung ausgegeben hat, das severity Attribut in der Tabelle Warnungen. Sie können verwenden alertDetailsOverride , um ein dynamisches severity Attribut bereitzustellen, das vom tatsächlichen Ergebnis der Abfrage abhängt.

Erforderliche Datenconnectors

Das requiredDataConnectors -Attribut stellt die Liste der Datenconnectors dar, die die Regel für die ordnungsgemäße Funktion benötigt, einschließlich der Datenquellen, für die die Regel abfragen wird. Wenn keine aktuelle Datenconnectorzuordnung vorhanden ist, müssen Sie eine geöffnete Klammer verwenden: requiredDataConnectors: [].

Das connectorId -Attribut gibt die ID des Datenconnectors an, die Sie benötigen, damit die Abfrage ordnungsgemäß funktioniert. Wenn Ihre Erkennungsabfrage von den Daten abhängt, die von einem bestimmten Connector abgerufen wurden, müssen Sie hier die Connector-ID angeben. Wenn ihre Analyseregel für instance von den Daten dieses Connectors abhängt, müssen Sie als connectorID1PasswordCCPDefinitionangeben.

Das dataTypes Attribut stellt die Datentypen dar, von denen die Analyseregel abhängt, und erwähnt den Namen des Datentyps, auf den dataTypes im Abschnitt des Connectors verwiesen wird. Wenn ihre Huntingabfrage instance von den Daten dieses Connectors abhängt, müssen Sie den Datentyp als OnePasswordEventLogs_CLangeben. Wenn die Huntingabfrage mit einer Kusto-Funktion/einem Parser anstelle der Tabelle (z Syslog. B. , CommonEventFormatoder _CL) dataTypes arbeitet, ist der Name der Kusto-Funktion bzw. der Parsername und nicht der Tabellenname.

Abfragezeitraum

Das queryPeriod Attribut stellt einen angegebenen Zeitraum dar, in dem die Abfrage ausgeführt wird. Beispiel: die letzten 3 Tage. Für dieses Attribut:

  • Verwenden Sie Kusto-Abfragesprache (KQL)TimeSpan-Format (z. B. 3 Tage , 3d2 Stunden ist 2h).
  • Stellen Sie sicher, dass jeder Lern- oder Referenzzeitraum innerhalb dieses Zeitrahmens liegt.
  • Verwenden Sie keinen Wert, der höher als der maximal unterstützte Wert ist 14d, nämlich .

Dieses Feld ist für geplante Analyseregeln obligatorisch.

Abfragehäufigkeit

Das queryFrequency Attribut stellt die Häufigkeit dar, mit der die Abfrage ausgeführt wird. Für dieses Attribut:

  • Verwenden Sie das KQL-Format TimeSpan (z. B. 3 Tage ist 3d, 2 Stunden ist 2h).
  • Verwenden Sie ein queryFrequency , das kleiner als oder gleich ist queryPeriod.
  • Befolgen Sie diese Regel: Wenn größer queryPeriod oder gleich 2 Tage (2d) ist, darf der queryFrequency Wert nicht kleiner als 1 Stunde (1h) sein und wird nur für Erkennungen mit hohem Schweregrad verwendet.

Dieses Feld ist für geplante Analyseregeln obligatorisch.

Triggeroperator

Das triggerOperator -Attribut gibt den Mechanismus an, der die Warnung auslöst. Beispiel: größer als (gt) die im triggerThreshold Attribut festgelegte Zahl (siehe Triggerschwellenwert).

  • gt: Größer als.
  • lt: Kleiner als.
  • eq: Gleich.

Dieses Feld ist für geplante Analyseregeln obligatorisch.

Triggerschwellenwert

Das triggerThreshold -Attribut stellt den Schwellenwert dar, der die Warnung auslöst. Schwellenwert ist der Wert, auf den der triggerOperator verweist. Unterstützte Werte sind beliebige ganze Zahlen zwischen 0 und 10.000.

Wenn triggerOperator z. B. auf gt und auf triggerThreshold festgelegt ist 1, wird die Warnung ausgelöst, wenn ein Wert größer als 1 ist.

Dieses Feld ist für geplante Analyseregeln obligatorisch.

Taktik

Das tactics -Attribut definiert die , auf MITRE ATT&CK tactics die sich die Erkennung bezieht. Wenn Sie die Taktiken definieren, hilft es Benutzern, den Kontext der Erkennung zu verstehen und zu verstehen, wie sie in die gesamte Bedrohungslandschaft passt. Für dieses Attribut:

  • ATT&CK Framework v13 wird unterstützt.
  • Namen dürfen keine Leerzeichen enthalten. Zum Beispiel InitialAccess oder LateralMovement.

Dieses Feld ist obligatorisch.

Relevante Techniken

Das relevantTechniques -Attribut definiert die , auf MITRE ATT&CK techniques die sich die Erkennung bezieht. Wenn Sie die Techniken definieren, hilft es Benutzern, den Kontext der Erkennung zu verstehen und zu verstehen, wie sie in die allgemeine Bedrohungslandschaft passt. Für dieses Attribut:

  • ATT&CK Framework v13 wird unterstützt.
  • Attribut stimmt mit Taktiken überein MITRE .
  • Namen dürfen keine Leerzeichen enthalten. Zum Beispiel T1078 oder T1078.001.

Dieses Feld ist obligatorisch.

Abfrage

Das query -Attribut definiert die Erkennungslogik. Es wird empfohlen, die Abfrage in KQL zu schreiben und sicherzustellen, dass sie strukturiert und leicht verständlich ist. Es wird empfohlen, eine effiziente Abfrage zu erstellen, die für die Leistung optimiert ist, um sicherzustellen, dass sie für große Datasets ausgeführt werden kann, ohne die Leistung zu beeinträchtigen. Stellen Sie sicher, dass Ihre Abfrage die folgenden Kriterien erfüllt.

Beschränken Sie die Abfrage auf 10.000 Zeichen. Wenn der Abfrageabschnitt diesen Grenzwert überschreitet, sollten Sie erwägen, die Anzahl der Zeichen zu reduzieren. Eine statische Liste von Elementen, die für den Vergleich innerhalb des Abfragetexts verwendet werden, kann dazu führen, dass Sie den Grenzwert überschreiten. Es wird empfohlen, diese Listen in eine der folgenden Optionen zu verschieben:

Jede Zeile im Abfragetext muss am Anfang mindestens ein Leerzeichen enthalten, aber zwei Leerzeichen sind standard, um die Lesbarkeit zu unterstützen.

Wenn Sie eine Abfrage für einen Datentyp übermitteln, der nicht im Ordner Erkennungen oder Huntingabfragen vorhanden ist, benennen Sie den Unterordner, der die YAML-Dateien enthält, nach der abgefragten Tabelle. Erstellen Sie für instance einen Ordner mit dem Namen AzureDevOpsAuditing, wenn ihre Abfrage sich auf die AzureDevOpsAuditing Tabelle bezieht.

Definieren Sie lesbare Namen für explizite Konstanten:

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

Es wird dringend empfohlen, kommentare zu verwenden, um die Abfrage zu verdeutlichen. Vermeiden Sie das Hinzufügen von Kommentaren am Ende einer Abfrageanweisungszeile. Fügen Sie stattdessen Ihre Kommentare in einer separaten Zeile hinzu. Zum Beispiel:

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

Wenn Sie auf einen Parser anstelle eines Tabellennamens verweisen, sorgen Sie für Klarheit in der Beschreibung, indem Sie einen Kommentar neben dem Parserfunktionsverweis einfügen. Der Parser muss zuerst in den Arbeitsbereich importiert werden. Andernfalls erkennen die Abfragen sie nicht als gültig.

Stellen Sie sicher, dass jedes verfügbare Entitätsfeld zu Zuordnungszwecken zurückgegeben wird. (Weitere Informationen finden Sie im Abschnitt Entitätszuordnungen.) Bereinigen Sie die zurückgegebene Tabelle, sodass sie nur die Eigenschaften bereitstellt, die Sie weiter untersuchen müssen. Sie benötigen TimeGenerated keinen Filter, wenn Sie einen einfachen lookback Befehl für die gesamte Abfrage verwenden. Der queryPeriod Wert in YAML steuert diesen Prozess.

Schließen Sie für baselining oder einen Verlaufsvergleich, z. B. den Vergleich von heute mit den vorherigen sieben Tagen, einen zeitgebundenen Filter wie | where TimeGenerated >= ago(lookback)ein, da die YAML-Vorlage derzeit nicht mehrere queryPeriod Werte unterstützt. Vermeiden Sie die Verwendung von Zeitrahmen, die kürzer als ein Tag sind, es sei denn, es gibt einen bestimmten Grund. Aufgrund potenzieller Leistungsbeeinträchtigungen empfehlen wir keine Zeitrahmen, die länger als 14 Tage sind.

Fassen Sie bei Bedarf eine Zusammenfassung zusammen. Stellen Sie sicher, dass Sie das Zeitfeld (normalerweise TimeGenerated) einschließen, da Sie es im Entitätsfeld benötigen. Schließen Sie sowohl die min()max() Werte als auch wie folgt ein: | summarize StartTime = max(TimeGenerated), EndTime = min(TimeGenerated). Verwenden Sie die Bedingungen StartTime ausschließlich EndTime . Weisen Sie den Feldern nicht die Namen StartTimeUtc oder EndTimeUtczu, da diese Namen mit den Benutzereinstellungen in Konflikt treten können.

Fügen Sie außerdem so viele Felder wie möglich ein, damit der Benutzer den Kontext der Warnung besser verstehen kann. Es wird empfohlen, mindestens eine der primären Entitäten einzubeziehen: Host, Accountoder IP.

Dieses Feld ist obligatorisch.

Ereignisgruppierungseinstellungen

Das eventGroupingSettings Attribut bezieht sich auf Warnungen. Eine Warnungsregel kann für jedes Abfrageergebnis eine separate Warnung generieren. Für instance könnte eine Regel, die Nicht-Microsoft-Warnungen im Ereignisstream identifiziert, eine Microsoft Sentinel Warnung für jede Quellwarnung erstellen.

  • Um eine einzelne Warnung für alle Abfrageergebnisse (Standardeinstellung) zu erzeugen, verwenden Sie Folgendes:

    eventGroupingSettings:
aggregationKind: SingleAlert

  • Um eine separate Warnung für jedes Abfrageergebnis zu erzeugen, verwenden Sie Folgendes:

    eventGroupingSettings:
aggregationKind: AlertPerResult

Entitätszuordnungen

Das entityMappings Attribut ist integral, wenn Sie geplante Analyseregeln konfigurieren. Es reichert die Ausgabe der Abfrage (Warnungen und Vorfälle) mit wichtigen Informationen an, die als Bausteine für alle folgenden Ermittlungsprozesse und Abhilfemaßnahmen dienen.

stellt entityType die Standardliste von Entitäten dar, die von Microsoft Sentinel erkannt werden. Sehen Sie sich die zulässigen Werte in der Spalte Entitätstyp in der Tabelle Entitätszuordnung an.

Dieses Feld ist obligatorisch.

Feldzuordnungen

Das fieldMappings -Attribut stellt den Bezeichner des Felds in der Abfrageausgabe dar, der dem Entitätstyp entspricht. Die zulässigen Werte finden Sie unter dem Spaltenwert bezeichner in der Entitätszuordnungstabelle. Für dieses Attribut:

  • Jede Vorlage kann bis zu 10 Entitätszuordnungen aufweisen.

  • Jede Entitätszuordnung kann bis zu drei Feldzuordnungen (d. b. Bezeichner) aufweisen.

    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

Benutzerdefinierte Details

Das customDetails Attribut integriert Ereignisdaten in Warnungen und macht sie in Sicherheitsvorfällen sichtbar, um eine schnellere Selektierung, Untersuchung und Reaktion zu ermöglichen. Benutzerdefinierte Details sind Schlüssel-Wert-Paare von Eigenschafts- und Spaltennamen. Weitere Informationen finden Sie unter Details zu benutzerdefinierten Surface-Ereignissen in Warnungen in Microsoft Sentinel. Pro Vorlage können bis zu 20 benutzerdefinierte Details (d. h. Schlüssel-Wert-Paare) definiert werden.

    customDetails:
      Computers: Computer
      IPs: ComputerIP

Außerkraftsetzung von Warnungsdetails

Das alertDetailsOverride Attribut ist ein dynamisches Feld, das Sie verwenden können, um die Warnungsdetails außer Kraft zu setzen. Sie können dieses Attribut verwenden, um dem Analysten mehr Kontext oder Informationen bereitzustellen, wenn die Warnung ausgelöst wird. Wenn Sie dieses Feature verwenden, stellen Sie sicher, dass Analysten relevante Informationen erhalten, einschließlich relevanter Entitätsnamen, um ein schnelleres und genaueres Verständnis des Incidents zu ermöglichen. Zu den Einschränkungen gehören:

  • Maximal drei Parameter können entweder in oder namedescriptioneingeschlossen werden.

  • Der name darf 256 Zeichen nicht überschreiten, während der description auf 5.000 Zeichen beschränkt ist.

  • Der Spaltenname innerhalb der geschweiften Klammern muss genau mit dem erwarteten Spaltennamen übereinstimmen, ohne voran- oder nachgestellte Leerzeichen (z. B {{columnName}}. , nicht {{ columnName }}). Im folgenden Beispiel columnName1sind , columnName2, dynamicTacticund dynamicSeverity Ausgabefelder der geplanten Warnungsabfrage.

        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

Version

Wenn ein Kunde eine neue Huntingabfrage aus der Vorlage erstellt, wird die Vorlage version gespeichert. Wenn eine neue Vorlagenversion veröffentlicht wird, werden Kunden in der Benutzeroberfläche benachrichtigt. Versionen folgen dem Format a, bund c, wobei a die Hauptversion, b die Nebenversion und c der Patch ist. Das Versionsfeld ist die letzte Zeile der Vorlage.

Dieses Feld ist obligatorisch.

  • Last updated on