Zusammengesetzte Erkennungsregeln erstellen

Unterstützt in:

Google SecOps SIEM

Dieses Dokument enthält eine technische Anleitung zum Erstellen einer zusammengesetzten Regel in der Google Security Operations-Plattform. Dabei werden mehrere YARA-L 2.0-Regeln verknüpft, um komplexe Angriffsmuster zu erkennen. Zusammengesetzte Erkennungen sind als Regeln für mehrere Ereignisse strukturiert und haben dieselbe grundlegende Syntax wie Standardregeln für einzelne Ereignisse. Weitere Informationen finden Sie unter Übersicht über zusammengesetzte Erkennungen.

Regelstruktur verstehen

Zusammengesetzte Erkennungsregeln sind immer Regeln für mehrere Ereignisse und folgen derselben Struktur und Syntax wie Regeln für einzelne Ereignisse.

Eine zusammengesetzte Regel besteht aus den folgenden wesentlichen Komponenten:

• Abschnitt events: Hier werden die Eingaben definiert, also die spezifischen Erkennungen oder Ereignisse, die von der Regel analysiert werden.

• match-Abschnitt: Gibt an, wie die Eingaben über ein definiertes Zeitfenster verbunden werden sollen.

• Abschnitt condition: Enthält die endgültige Logik, die bestimmt, ob die zusammengeführten Ereignisse die Kriterien für das Auslösen einer Benachrichtigung erfüllen.

Eingaben im Abschnitt events definieren

Der erste Schritt beim Erstellen einer zusammengesetzten Erkennungsregel besteht darin, die Eingaben der Regel im Abschnitt events zu definieren. Die Eingaben für zusammengesetzte Regeln stammen aus Sammlungen, in denen die von anderen Abfragen generierten Erkennungen gespeichert werden. Google SecOps bietet die folgenden zwei Methoden für den Zugriff auf Daten aus Sammlungen.

Inhalte mit Variablen oder Meta-Labels referenzieren

Wenn Sie auf Daten aus einer Erkennung zugreifen möchten, ohne auf die ursprünglichen UDM-Ereignisse zu verweisen, können Sie outcome-Variablen, match-Variablen oder meta-Labels verwenden. Dieser Ansatz wird empfohlen, da er mehr Flexibilität und eine bessere Kompatibilität mit verschiedenen Regeltypen bietet.

Beispielsweise können mehrere Regeln einen String (z. B. eine URL, einen Dateinamen oder einen Registrierungsschlüssel) in einer gemeinsamen outcome-Variablen speichern, wenn Sie nach diesem String in verschiedenen Kontexten suchen. Wenn Sie über eine zusammengesetzte Regel auf diesen String zugreifen möchten, beginnen Sie mit detection und suchen Sie mit Elementen aus der Collection-Ressource nach den relevanten Informationen.

Beispiel: Angenommen, eine Erkennungsregel liefert die folgenden Informationen:

• Ergebnisvariable: dest_domain = "cymbal.com"

• UDM-Feld: target.hostname = "cymbal.com"

In der zusammengesetzten Regel können Sie über die folgenden Pfade auf diese Daten zugreifen:

• detection.detection.variables["dest_domain"].string_val, um auf die Ergebnisvariable dest_domain zuzugreifen.

• detection.collection_elements.references.event.target.hostname, um auf das UDM-Feld target.hostname zuzugreifen.

• detection.time_window.start_time.seconds, um auf den Startzeitstempel der Erkennung zuzugreifen.

Die Collection API und die SecurityResult API bieten Zugriff auf beide:

• Metadaten und Ergebniswerte für die Erkennung (detection.detection)
• Zugrunde liegende UDM-Ereignisse aus referenzierten Regeln (collection_elements)

Inhalte mit Regel-ID oder -Name für die Referenzerkennung angeben

Sie können auf eine Regel entweder über ihren Namen oder ihre ID verweisen. Wir empfehlen diesen Ansatz, wenn Ihre Erkennungslogik von bestimmten Regeln abhängt und Sie die analysierten Daten auf diese Regelergebnisse beschränken möchten. Wenn Sie anhand des Namens oder der ID auf relevante Regeln verweisen, wird die Leistung verbessert und es werden Zeitüberschreitungen verhindert, da weniger Daten analysiert werden. Sie können beispielsweise Felder wie target.url oder principal.ip direkt aus einer bekannten vorherigen Erkennung abfragen.

• Auf eine Regel anhand der Regel-ID verweisen (empfohlen): Verwenden Sie das Feld detection.detection.rule_id, um anhand der ID auf eine Regel zu verweisen. Die Regel-ID finden Sie in der URL der Regel in Google SecOps. Von Nutzern erstellte Regeln haben IDs im Format ru_UUID, während ausgewählte Erkennungen IDs im Format ur_UUID haben. Beispiel:

  detection.detection.rule_id = "ru_e0d3f371-6832-4d20-b0ad-1f4e234acb2b"

• Auf eine Regel anhand des Namens verweisen:Verwenden Sie das Feld detection.detection.rule_name, um anhand des Namens auf eine Regel zu verweisen. Sie können den genauen Regelnamen angeben oder einen regulären Ausdruck verwenden, um ihn abzugleichen. Beispiel:

  • detection.detection.rule_name = "My Rule Name"
  • detection.detection.rule_name = "/PartOfName/"

Hinweis :Wir empfehlen, auf Regel-IDs zu verweisen, da IDs eindeutig sind und sich nicht ändern. Regelnamen können geändert werden, was möglicherweise Ihre zusammengesetzte Erkennung beeinträchtigt.

Join-Eingaben im Abschnitt match

Wenn Sie zusammengehörige Erkennungen, Ereignisse oder Entitäten in einer zusammengesetzten Regel verknüpfen möchten, definieren Sie den Abschnitt match mit Variablen, die im Abschnitt events definiert sind. Diese Variablen können Regellabels, Ergebnisvariablen, Abgleichsvariablen, Erkennungsfelder oder Sammlungselemente umfassen.

Informationen zur Syntax finden Sie unter Syntax für den Abgleichabschnitt.

Zusammengesetzte Regeln: Zeitintervalle und springende Fenster

Bei zusammengesetzten Regeln werden Erkennungen und Ereignisse mit einem Zeitintervall abgeglichen und nicht mit einem einzelnen Zeitpunkt. Sie stimmen mit einem zusammengesetzten Hop-Fenster überein, wenn sich das Zeitfenster für die Eingabeerkennung mit diesem Hop-Fenster überschneidet (z. B. wenn die Aktivität während dieses Zeitblocks aktiv war).

Eine einzelne Erkennung kann mehrere Benachrichtigungen auslösen, wenn die Erkennung die Grenze zwischen benachbarten springenden Fenstern überschreitet. Aufgrund von Pipelineverzögerungen werden diese historischen Übereinstimmungen später angezeigt. Genauer gesagt wird durch ein springendes Fenster einer zusammengesetzten Regel eine Übereinstimmung ausgelöst, wenn sich das Eingabe-Erkennungszeitfenster (WindowStart bis WindowEnd) mit dem springenden Fenster überschneidet.

Beispiel:

1. Eine zusammengesetzte Regel hat 60-minütige springende Fenster: Hop 1 (18:58–19:58) und Hop 2 (19:58–20:58).
2. Eine Upstream-Producer-Erkennung hat ein Zeitfenster von 19:57:54 bis 20:56:54 (Dauer: 59 Minuten).
3. Da das Producer-Fenster um 19:57:54 Uhr begann (6 Sekunden vor dem Ende von Hop 1) und um 20:56:54 Uhr endete (während Hop 2), überschneidet es sich mit beiden Hop-Fenstern.
4. Dadurch werden zwei zusammengesetzte Erkennungen ausgelöst (eine für Hop 1 und eine für Hop 2), was dazu beiträgt, Falsch-Negativ-Ergebnisse zu vermeiden. Wenn die Erstellerregel nicht mit der Überschneidung übereinstimmt, wird die teilweise überschneidende Erkennung weder für Hop 1 noch für Hop 2 berücksichtigt und die Korrelation zwischen der Erkennung und anderen Ereignissen geht verloren.

Hinweis: Wenn Sie diese Art von Grenzduplizierung verhindern möchten, konfigurieren Sie ein Unterdrückungsfenster (z. B. 12h oder 24h) in der zusammengesetzten Regel, um eine Ratenbegrenzung zu erzwingen (z. B. eine Benachrichtigung pro Kampagne und Tag).

Weitere Informationen und Beispiele zum Angeben von Hop-Fenstern finden Sie unter Hop-Fenster.

Abschnitt „condition“ definieren

Definieren Sie den Abschnitt condition, um die Ergebnisse des Abschnitts match auszuwerten. Wenn die Bedingung true ist, wird eine Benachrichtigung generiert. Informationen zur Syntax finden Sie unter Syntax des Bedingungsabschnitts.

Erweiterte Techniken auf zusammengesetzte Regeln anwenden

In diesem Abschnitt wird beschrieben, wie Sie beim Erstellen zusammengesetzter Regeln erweiterte Techniken anwenden.

Ereignisse und Erkennungen kombinieren

In zusammengesetzten Regeln können mehrere Datenquellen kombiniert werden, darunter UDM-Ereignisse, Daten aus dem Entity-Diagramm und Erkennungsfelder. Hierfür gelten folgende Richtlinien:

• Unterschiedliche Variablen pro Quelle verwenden: Weisen Sie jeder Datenquelle eindeutige Ereignisvariablen zu (z. B. $e für Ereignisse, $d für Erkennungen), wobei die Datenquelle Ereignisse, Entitäten und Erkennungen umfasst.

• Quellen anhand von gemeinsamem Kontext verknüpfen: Verbinden Sie Datenquellen mithilfe von gemeinsamen Werten wie Nutzer-IDs, IP-Adressen oder Domainnamen in den Bedingungen Ihrer Regel.

• Zeitfenster für den Abgleich definieren: Fügen Sie immer eine match-Klausel mit einem Zeitfenster von höchstens 48 Stunden ein.

Beispiel: Ereignisse und Erkennungen kombinieren

rule CheckCuratedDetection_with_EDR_and_EG {
  meta:
    author = "[e-mail]"
  events:
    $d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
    $d.detection.collection_elements.references.event.network.dns.questions.name = $domain
    $d.detection.collection_elements.references.event.principal.asset.hostname = $hostname

    $e.metadata.log_type = "LIMACHARLIE_EDR"
    $e.metadata.product_event_type = "NETWORK_CONNECTIONS"
    $domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
    $hostname = re.capture($e.principal.hostname, "([^.]*)")

    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 5
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0

  match:
    $hostname over 1h

  outcome:
    $risk_score = 80
    $CL_target = array($domain)

  condition:
    $e and $d and $prevalence
}

Sequenzielle zusammengesetzte Erkennungen erstellen

Bei sequenziellen zusammengesetzten Erkennungen werden Muster von zusammenhängenden Ereignissen erkannt, bei denen die Reihenfolge der Erkennungen wichtig ist, z. B. eine Erkennung eines Brute-Force-Anmeldeversuchs, gefolgt von einer erfolgreichen Anmeldung. Diese Muster können mehrere Basis-Erkennungen, UDM-Rohereignisse oder beides kombinieren.

Wenn Sie eine sequenzielle zusammengesetzte Erkennung erstellen möchten, müssen Sie diese Reihenfolge in Ihrer Regel erzwingen. Verwenden Sie eine der folgenden Methoden, um die erwartete Reihenfolge zu erzwingen:

• Gleitende Fenster:Definieren Sie die Reihenfolge der Erkennungen mit gleitenden Fenstern in Ihren match-Bedingungen.

• Zeitstempelvergleiche:Vergleichen Sie die Zeitstempel von Erkennungen in Ihrer Regel-Logik, um zu prüfen, ob sie in der ausgewählten Reihenfolge erfolgen.

Beispiel: Sequenzielle zusammengesetzte Erkennungen

events:
    $d1.detection.detection.rule_name = "fileEvent_rule"
    $userid = $d1.detection.detection.variables["user"].string_val
    $hostname = $d1.detection.detection.variables["hostname"].string_val

    $d2.detection.detection.rule_name = "processExecution_rule"
    $userid = $d2.detection.detection.variables["user"].string_val
    $hostname = $d2.detection.detection.variables["hostname"].string_val

    $d3.detection.detection.rule_name = "networkEvent_rule"
    $userid = $d3.detection.detection.variables["user"].string_val
    $hostname = $d3.detection.detection.variables["hostname"].string_val

$d3.detection.collection_elements.references.event.metadata.event_timestamp.seconds > $d2.detection.collection_elements.references.event.metadata.event_timestamp.seconds

  match:
    $userid over 24h after $d1

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten