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 dabei, 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 einer Organisation, da sie potenzielle Bedrohungen proaktiv erkennen und darauf reagieren. Durch die strukturierte Vorgehensweise zum Erstellen und Verwalten dieser Regeln können Organisationen die Funktionen von Microsoft Sentinel verwenden, um ihre digitalen Ressourcen zu schützen und eine robuste Sicherheitsinfrastruktur aufrechtzuerhalten. Weitere Informationen finden Sie unter Bedrohungserkennung in Microsoft Sentinel.

Dieser Artikel führt Sie durch den Prozess der Erstellung und Veröffentlichung 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 Verletzung hinweisen könnten.
  • Schadsoftwareerkennung: Überwachen Sie auf bekannte Schadsoftwaresignaturen oder ungewöhnliches Verhalten, das das Vorhandensein bösartiger Software vorschlagen könnte.
  • Datenexfiltration: Erkennen Sie große oder ungewöhnliche Datenübertragungen, die bedeuten könnten, dass Daten aus dem Netzwerk exfiltriert werden.
  • Insider-Bedrohungen: Identifizieren Sie anomales Verhalten interner Benutzer, z. B. den Zugriff auf vertrauliche Daten außerhalb normaler Stunden oder Muster.
  • Konformitätsüberwachung: Sicherstellen der Einhaltung gesetzlicher Anforderungen durch Überwachung bestimmter Aktivitäten oder Zugriffsmuster.
  • Bedrohungssuche: Suchen Sie proaktiv nach Indikatoren für Kompromittierung oder andere Anzeichen von böswilligen Aktivitäten innerhalb des Netzwerks.
  • Kontokompromittierung: Erkennen Sie Anzeichen, dass Benutzerkonten kompromittiert werden, z. B. ungewöhnliche geografische Anmeldemuster oder mehrere fehlgeschlagene Anmeldeversuche.
  • Netzwerkanomalien: Identifizieren Sie ungewöhnliche Netzwerkdatenverkehrsmuster, die auf das Vorhandensein einer Bedrohung oder Fehlkonfiguration hinweisen können.
  • Berechtigungseskalation: Überwachen Sie auf Versuche, erhöhte Berechtigungen innerhalb des Netzwerks zu erhalten, 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 nicht autorisierter Software erkennen.

Erstellen und Veröffentlichen von Analyseregeln

Sie erstellen Analyseregeln im YAML-Format. Verwenden Sie diese Beispiele für Analyseregeln als Verweise, um Eigene zu erstellen:

In den folgenden Abschnitten finden Sie eine detaillierte Erläuterung zu den verschiedenen Merkmalen einer Analyseregel.

Beispielanalyseregel

Im Folgenden finden Sie eine Beispielanalyseregel im YAML-Format.

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

ID

Das id Attribut besteht aus einem standardmäßigen global eindeutigen Bezeichner (GUID). Generieren Sie es mithilfe eines beliebigen Entwicklungstools, eines Online-Generators oder des neuen PowerShell New-GUID-Cmdlets. Sie muss unter anderen GUIDs eindeutig sein.

Dieses Feld ist obligatorisch.

Kind

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. Bei NRT-Regeln lassen Sie queryFrequency, queryPeriod, triggerOperator und triggerThreshold weg.

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äzise ist, damit Benutzer den Zweck der Regel verstehen können. Wird alertDetailsOverride verwendet, um dynamische Namen zu generieren, um Analysten dabei zu helfen, die Warnung zu verstehen. Dieses Attribut:

  • Verwendet Groß-/Kleinschreibung in Satzbuchstaben.
  • Endet nicht mit einem Punkt.
  • Hat eine empfohlene Länge von weniger als 50 Zeichen und eine feste Obergrenze von 100 Zeichen.
  • Vermeidet die Wörter „verdächtig“ und „verdächtigt“. Verwenden Sie stattdessen „Unerwartet“, „Anomal“ oder „Selten“.

Dieses Feld ist obligatorisch.

Description

Das description Attribut enthält eine detaillierte Beschreibung der Erkennung. Die Beschreibung enthält Informationen über das erkannte Verhalten, den potenziellen Effekt und alle empfohlenen Aktionen. Dieses Attribut:

  • Verwendet großgeschriebene Sätze.
  • Beginnt mit „Diese Abfrage sucht nach“ oder „Identifiziert“.
  • Unterscheidet sich von und aussagekräftiger als das Namensfeld.
  • Hat eine maximale Länge von 255 Zeichen.
  • Beträgt fünf Sätze oder weniger.
  • Beschreibt die Datenquelle nicht (Connector oder Datentyp).
  • Stellt keine technische Erläuterung für die Abfragesprache bereit.
  • Verwendet nur ASCII-Zeichen. EM-Bindestriche, typographische Anführungszeichen und andere Nicht-ASCII-Zeichen werden bei der Überprüfung nicht akzeptiert.

Dieses Feld ist obligatorisch.

Severity

Das severity Attribut definiert den Schweregrad der Erkennung. Der Schweregrad spiegelt die potenzielle Auswirkung des erkannten Verhaltens und die Dringlichkeit der Antwort wider.

  • Informational: Der Vorfall stellt möglicherweise nicht direkt eine Sicherheitsbedrohung dar, ist aber für die Nachuntersuchung von Interesse, oder um einem Analysten Kontext oder situationsbezogenes Bewusstsein hinzuzufügen.
  • Niedrig: Die sofortige Wirkung ist minimal, und ein Bedrohungsakteur müsste mehrere Schritte ausführen, bevor eine Auswirkung auf eine Umgebung erreicht wird.
  • Mittel: Der Bedrohungsakteur könnte einige Auswirkungen auf die Umgebung mit dieser Aktivität erzielen, aber der Effekt wäre in Umfang begrenzt oder erfordert zusätzliche Aktivitäten.
  • Hoch: Die identifizierte Aktivität bietet dem Bedrohungsakteur einen umfassenden Zugriff auf Aktionen in der Umgebung.

Note

Die Standardwerte für den Schweregrad sind keine Garantie für den Grad der aktuellen Auswirkungen oder der Auswirkungen auf die Umgebung. 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 alertDetailsOverride verwenden, um ein dynamisches severity-Attribut bereitzustellen, das vom tatsächlichen Ergebnis der Abfrage abhängt.

Status

Das status Attribut gibt die Produktionsbereitschaft der Regel an:

  • Available: Produktionsreife Regeln.
  • InPreview: Regeln für die Betaversion.
  • Deprecated: Regeln, die schrittweise abgeschafft werden.

Erforderliche Datenkonnektoren

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

Das connectorId Attribut gibt die ID des Datenconnectors an, den 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 beispielsweise von den Daten dieses Connectors abhängt, müssen Sie connectorID als 1PasswordCCPDefinition angeben.

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 Suchabfrage beispielsweise von den Daten dieses Connectorsabhängt, müssen Sie den Datentyp als OnePasswordEventLogs_CLangeben. Wenn die Suchabfrage auf einer Kusto-Funktion/einem Parser anstelle der Tabelle (wie Syslog, CommonEventFormatoder _CL) ausgeführt wird, ist dataTypes der Name der Kusto-Funktion bzw. der Parser 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 das Kusto Query Language (KQL) TimeSpan -Format (z. B. 3 Tage ist 3d, 2 Stunden ist 2h).
  • Stellen Sie sicher, dass sich jede Lern- oder Referenzphase innerhalb dieses Zeitraums befindet.
  • Verwenden Sie keinen Wert, der höher als der maximal unterstützte Wert ist 14d.

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 einen queryFrequency Wert, der kleiner oder gleich dem queryPeriodist.
  • Befolgen Sie diese Regel: Wenn der queryPeriod Wert größer oder gleich 2 Tage (2d) ist, kann 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 Auslöserschwellenwert).

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

Dieses Feld ist für geplante Analyseregeln obligatorisch.

Auslöserschwellenwert

Das triggerThreshold Attribut stellt den Schwellenwert dar, der die Warnung auslöst. Der Schwellenwert ist der Wert, auf den sich die triggerOperator bezieht. Unterstützte Werte umfassen eine beliebige ganze Zahl zwischen 0 und 10.000.

Wenn das triggerOperator auf gt gesetzt ist und das triggerThreshold den Wert 1 hat, 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 das MITRE ATT&CK tactics, auf das sich die Erkennung bezieht. Wenn Sie die Taktiken definieren, hilft es Benutzern, den Kontext der Erkennung zu verstehen und wie sie in die gesamte Bedrohungslandschaft passt. Für dieses Attribut:

  • ATT&CK Framework v16 wird unterstützt.
  • Namen verwenden PascalCase und dürfen keine Leerzeichen enthalten. Beispiel: InitialAccess oder LateralMovement.
  • Pro Regel können maximal fünf Taktiken definiert werden.
  • Gültige Werte sind: Reconnaissance, ResourceDevelopment, InitialAccess, Execution, Persistence, PrivilegeEscalation, DefenseEvasion, CredentialAccess, Discovery, LateralMovement, Collection, CommandAndControl, Exfiltration und Impact.

Dieses Feld ist obligatorisch.

Relevante Techniken

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

  • ATT&CK Framework v16 wird unterstützt.
  • Jede Technik muss mindestens einer der aufgeführten tacticsTechniken angehören.
  • Namen können keine Leerzeichen enthalten. Beispiel: T1078 oder T1078.001.
  • Pro Regel können maximal 10 Techniken definiert werden.

Dieses Feld ist obligatorisch.

Query

Das query Attribut definiert die Erkennungslogik. Wir empfehlen, die Abfrage in KQL zu schreiben und sicherzustellen, dass sie strukturiert und leicht verständlich ist. Wir empfehlen, 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 dass sich dies auf die Leistung auswirkt. 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 die Zahl der Zeichen verringern. Eine statische Liste von Elementen, die für den Vergleich innerhalb des Abfragetexts verwendet werden, kann dazu führen, dass Sie den Grenzwert überschreiten. Wir empfehlen, diese Listen in eine der folgenden Optionen zu verschieben:

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

Wenn Sie eine Abfrage für einen Datentyp senden, der im Ordner "Erkennungs- oder Suchabfragen" nicht vorhanden ist, benennen Sie den Unterordner, der die YAML-Dateien enthält, nachdem die Tabelle abgefragt wurde. Wenn ihre Abfrage beispielsweise zur AzureDevOpsAuditing Tabelle gehört, erstellen Sie einen Ordner mit dem Namen AzureDevOpsAuditing.

Definieren Sie menschlich lesbare Namen für explizite Konstanten:

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

Wir empfehlen dringend, Kommentare zu verwenden, um die Abfrage zu klären. Vermeiden Sie das Hinzufügen von Kommentaren am Ende einer Abfrageanweisungszeile. Fügen Sie stattdessen Ihre Kommentare in einer separaten Zeile hinzu. Beispiel:

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

Wenn Sie auf einen Parser anstelle eines Tabellennamens verweisen, sollten Sie Klarheit in der Beschreibung sicherstellen, indem Sie neben dem Parserfunktionsverweis einen Kommentar 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, so dass sie nur die Eigenschaften enthält, die Sie für weitere Untersuchungen benötigen. Sie benötigen keinen TimeGenerated Filter, wenn Sie einen einfachen lookback Befehl für die gesamte Abfrage verwenden. Der queryPeriod Wert in der YAML steuert diesen Prozess.

Für das Baselining oder die Durchführung eines historischen Vergleichs, wie beispielsweise dem Vergleich von heute mit den vorherigen sieben Tagen, fügen Sie einen zeitlich begrenzten Filter, wie beispielsweise | 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 einen Tag sind, es sei denn, es gibt einen bestimmten Grund. Aufgrund potenzieller Leistungseinbußen empfehlen wir keine Zeitrahmen, die länger als 14 Tage sind.

Fassen Sie bei Bedarf zusammen. Stellen Sie sicher, dass Sie das Zeitfeld (in der Regel TimeGenerated) einschließen, da es im Entitätsfeld erforderlich ist. Schließen Sie sowohl die min()- als auch max()-Werte wie folgt ein: | summarize StartTime = max(TimeGenerated), EndTime = min(TimeGenerated). Verwenden Sie die Bedingungen StartTime und EndTime ausschließlich. Weisen Sie den Feldern nicht die Namen StartTimeUtc oder EndTimeUtc zu, da diese Namen mit den Benutzereinstellungen in Konflikt geraten können.

Fügen Sie außerdem so viele Felder wie möglich ein, um dem Benutzer das Verständnis des Kontexts der Warnung zu erleichtern. Wir empfehlen, mindestens eine der primären Entitäten: Host, Account, oder IP einzubeziehen.

Spaltennamen in Ihrer benutzerdefinierten Tabelle müssen in camelCase geschrieben sein (z. B. SrcIpAddr oder UserName).

Dieses Feld ist obligatorisch.

Einstellungen für die Ereignisgruppierung

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

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

    eventGroupingSettings:
aggregationKind: SingleAlert

  • Verwenden Sie Folgendes, um eine separate Warnung für jedes Abfrageergebnis zu erstellen:

    eventGroupingSettings:
aggregationKind: AlertPerResult

Entitätszuordnungen

Das entityMappings Attribut ist integral, wenn Sie geplante Analyseregeln konfigurieren. Dadurch wird die Ausgabe der Abfrage (Warnungen und Vorfälle) um wesentliche Informationen erweitert, die als Bausteine für alle nachfolgenden Untersuchungsprozesse und Korrekturmaßnahmen dienen.

Dies entityType stellt die Standardliste der Entitäten dar, die von Microsoft Sentinel erkannt werden. Zu den unterstützten Typen gehören Account, Host, IP, URL, File, Process, DNS, AzureResource, FileHash, RegistryKey, RegistryValue, SecurityGroup, Mailbox und MailMessage. Siehe zulässige Werte in der Spalte "Entitätstyp" in der Tabelle "Entitätszuordnung".

Dieses Feld ist obligatorisch.

Feldzuordnungen

Das fieldMappings Attribut stellt den Bezeichner des Felds in der Abfrageausgabe dar, der dem Entitätstyp entspricht. Siehe zulässige Werte unter dem Bezeichnerspaltenwert 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 aufweisen (nämlich Bezeichner).

    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 schnelleres Triagieren, Untersuchen und Reagieren zu ermöglichen. Benutzerdefinierte Details sind Schlüssel-Wert-Paare von Eigenschaften- und Spaltennamen. Weitere Informationen finden Sie unter Anzeigen von benutzerdefinierten Ereignisdetails in Warnungen in Microsoft Sentinel. Bis zu 20 benutzerdefinierte Details (d. h. Schlüssel-Wert-Paare) können pro Vorlage definiert werden. Schlüsselnamen müssen 20 Zeichen oder weniger sein.

    customDetails:
      Computers: Computer
      IPs: ComputerIP

Außerkraftsetzung von Warnungsdetails

Das alertDetailsOverride Attribut ist ein dynamisches Feld, mit dem Sie die Warnungsdetails außer Kraft setzen können. 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 Vorfalls zu ermöglichen. Einschränkungen umfassen:

  • Maximal drei Parameter können entweder in name oder descriptionenthalten sein.

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

  • Der Spaltenname in den geschweiften Klammern muss genau mit dem erwarteten Spaltennamen übereinstimmen, ohne dass führende oder nachfolgende Leerzeichen vorhanden sind (zum Beispiel {{columnName}}, nicht {{ columnName }}). Im folgenden Beispiel, columnName1, , columnName2dynamicTacticund dynamicSeverity sind 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

Vorfallkonfiguration

Das incidentConfiguration Attribut steuert die Erstellung von Vorfällen und die Gruppierung von Warnungen in Vorfälle. Verwenden Sie sie, um zu definieren, wie Warnungen, die diese Regel generiert, in Vorfälle aggregiert werden.

Version

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

Dieses Feld ist obligatorisch.

  • Last updated on