Kontextbezogene Analysen

Unterstützt in:

In Google SecOps können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken in Ihrem Google SecOps-Konto als einzelne Erkennung aufrufen. Sie bietet eine Kontextualisierung von Entitäten, damit Sie sowohl die Verhaltensmuster in der Telemetrie als auch den Kontext der betroffenen Entitäten aus diesen Mustern ableiten können.

Beispiele:

  • Die Berechtigungen für ein Konto werden angezeigt, für das ein Brute-Force-Anmeldeversuch unternommen wird.
  • Wichtigkeit von Daten, die von einem Asset gehostet werden, das auch die Quelle von ausgehenden Netzwerkaktivitäten ist.

Kunden können diese Kontextualisierung für die Erkennungsfilterung, die heuristische Benachrichtigungspriorisierung, die Triage und die Untersuchung verwenden.

Sicherheitsanalysten und Entwickler für die Erkennung arbeiten in der Regel daran, eine Erkennung anhand eines grundlegenden Musters der Ereignistelemetrie (eine ausgehende Netzwerkverbindung) zu erstellen. So werden zahlreiche Erkennungen erstellt, die von den Analysten priorisiert werden müssen. Die Analysten versuchen, herauszufinden, was passiert ist, um die Warnung auszulösen, und wie schwerwiegend die Bedrohung ist.

Kontextsensitive Analysen bieten erweiterte Funktionen zur Datenanreicherung bereits früher im Workflow zum Erstellen und Ausführen von Erkennungsregeln. So stehen Ihnen folgende zusätzliche Funktionen zur Verfügung:

  • Relevanten Kontext für die heuristisch basierte Bewertung des Kontextrisikos von Erkennungen zum Zeitpunkt der Erkennung und nicht in der manuellen Triagephase verfügbar machen
  • Verringerung der Zeit für die Triage und manuelle Zusammenführung von Informationen aus verschiedenen IT-Sicherheitssystemen (EDR-Konsolen, Firewall- oder Proxy-Protokolle, CMDB- und IAM-Kontext, Ergebnisse von Sicherheitslückenscans)
  • Analysten und Entwicklern von Erkennungssystemen ermöglichen, ganze Cluster von Bedrohungen herauszufiltern, die zu erwarten sind oder für das Unternehmen nur eine geringe oder gar keine Gefahr darstellen (z. B. Malware-Tests in einer Sandbox-Umgebung, Sicherheitslücken und anormale Aktivitäten in einem Entwicklungsnetzwerk ohne sensible Daten oder Zugriff).

Regeln für kontextbezogene Analysen schreiben

Sie können mithilfe von Regeln der Erkennungs-Engine in Ihrem Google SecOps-Konto nach Daten zum Entitätskontext suchen.

So suchen Sie nach Daten zum Entitätskontext:

  1. Geben Sie eine Quelle entweder mithilfe des UDM oder der Entität an.

    $eventname.[<source>].field1.field2 Für einen Entitätskontext ist <source> „graph“. Bei einem UDM-Ereignis ist <source> „udm“. Wenn Sie diesen Parameter weglassen, wird standardmäßig „udm“ verwendet.

  2. Geben Sie die Entitätsdaten an:

    $e1.graph.entity.hostname = "my-hostname"

    $e1.graph.entity.relations.relationship = "OWNS"

  3. UDM-Ereignisdaten angeben Die folgenden Aussagen sind äquivalent.

    $e1.udm.principal.asset_id = "my_asset_id"

    $e1.principal.asset_id = "my_asset_id"

Für Entitätskontexte können Sie viele derselben Arten von Regeln erstellen wie für UDM-Ereignisse, darunter:

  • Mehrere Ereignisregeln

  • Entitätskontexte mit anderen Entitätskontexten vergleichen

  • Entitätskontexte mit UDM-Ereignissen vergleichen

  • Wiederholte Felder in Entitätskontexten

  • Schiebefenster

  • Risikobewertung für Erkennungen berechnen

Im Gegensatz zu einem UDM-Ereignis hat ein Entitätskontext keinen bestimmten Zeitstempel. Jeder Datensatz für den Entitätskontext hat ein Zeitintervall (entity.metadata.interval), in dem der Entitätskontext gültig ist. Dieses Zeitintervall muss nicht an einem Tag enden und kann beliebig lang sein.

Ein UDM-Ereignis wird nur dann mit einem Entitätskontextdatensatz in Beziehung gesetzt, wenn der Zeitstempel des UDM-Ereignisses in das Zeitintervall des Entitätskontextdatensatzes fällt. Wenn diese Bedingung nicht erfüllt ist, werden die UDM und die Entität nicht auf Erkennungen geprüft. Die Erkennungs-Engine erzwingt dies implizit und Sie müssen es nicht als Bedingung in einer Regel angeben.

  • Wenn Sie UDM-Ereignisse mit einem Entitätskontext mit Fensterung vergleichen, stellt ein Entitätskontext einen konstanten Wert über einen bestimmten Zeitraum dar.
  • Wenn es benachbarte Tages-Buckets gibt, in denen sich der Entitätskontext ändert, versucht Google SecOps, alle Entitätskontextwerte abzugleichen und alle gefundenen Übereinstimmungen zurückzugeben.

Beispielregeln

Nach Entitäten mit Administratorkontext suchen

Mit der folgenden Regel wird nach Entitäten gesucht, die auch mit Administratorberechtigungen verknüpft sind. Es wird nach Zeiten gesucht, zu denen sich jemand mit Administratorberechtigungen im System angemeldet oder abgemeldet hat.

rule LoginLogout {
  meta:
  events:
    ($log_inout.metadata.event_type = "USER_LOGIN" or  $log_inout.metadata.event_type = "USER_LOGOUT")
    $log_inout.principal.user.user_display_name = $user

    $context.graph.entity.user.user_display_name = $user
    $context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"

  match:
    $user over 2m

  condition:
    $log_inout and $context
}

Beispiel für ein Schiebefenster

Das folgende Beispiel für einen gleitenden Zeitraum ist gültig.

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Using e2 (a UDM event) as a pivot.
    $host over 3h after $e2

  condition:
    $e1 and $e2
}

Beispiel für ein ungültiges Gleitfenster

Das folgende Beispiel für einen gleitenden Zeitraum ist ungültig. Der Entitätskontext kann nicht als Drehpunkt für einen gleitenden Zeitraum verwendet werden.

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Attempting to use $e1 (an entity context) as a pivot. Invalid.
    $host over 3h after $e1

  condition:
    $e1 and $e2
}

Beispiel für die Anmeldung mit dem Abschnitt „Ergebnis“

Im folgenden Beispiel wird der Abschnitt outcome verwendet, um einen Risikowert für die Erkennung zu berechnen.

rule Detection {
  meta:
  events:
    $auth.metadata.event_type = "USER_LOGIN"
    $auth.metadata.vendor_name = "Acme"
    $auth.metadata.product_name = "Acme SSO"
    $auth.target.user.userid = $user
    $auth.metadata.event_timestamp.seconds >
       $context.graph.entity.user.termination_date.seconds

    $context.graph.metadata.vendor_name = "Microsoft"
    $context.graph.metadata.product_name = "Azure Active Directory"
    $context.graph.metadata.entity_type = "USER"
    $context.graph.entity.user.userid = $user
    $context.graph.entity.user.termination_date.seconds > 0

  match:
    $user over 15m

  outcome:
    $risk_score = max(
        if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
        if (
            $context.graph.entity.user.title = "Remote" nocase or
            $context.graph.entity.user.title = "Temp" nocase or
            $context.graph.entity.user.title = "Vendor" nocase, 40) +
        if ( $context.graph.entity.user.title = "Legal" nocase, 10)
    )

  condition:
    $auth and $context
}

Beispiel für den Start eines verdächtigen Prozesses

Im folgenden Beispiel werden UDM-Ereignisverarbeitungsdaten anhand von IOC-Kontextdaten bewertet, die als Entitätskontext gespeichert sind.

rule ProcessLaunch {
  meta:
  events:
    $ioc.graph.metadata.vendor_name = "ACME"
    $ioc.graph.metadata.product_name = "IOCs"
    $ioc.graph.metadata.entity_type = "FILE"
    $ioc.graph.entity.file.sha256 = $hash

    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.principal.hostname = $hostname
    (
        not $process.target.process.file.sha256 = "" and
        $process.target.process.file.sha256 = $hash
    )

  match:
    $hash over 15m

  condition:
    $ioc and $process
}

Zusätzliche Einschränkungen für den Entitätskontext

Wenn Sie eine Ereignisvariable mit einem Entitätskontext erstellen möchten, müssen Sie nach dem Ereignisnamen ein <source> angeben. Der <source> muss graph lauten.

Das folgende Muster bezieht sich auf einen Entitätskontext:

  • $e.graph.entity.hostname

Es gibt zwei äquivalente Methoden, um auf ein UDM-Ereignis zu verweisen:

  • $u.udm.principal.asset_id
  • $u.principal.asset_id

Sie können alle diese Modifikatoren im Regeltext kombinieren. Sie können auch verschiedene Einschränkungen für dasselbe Ereignis verwenden.

Abschnitt „Ergebnis“

Die Erkennungs-Engine unterstützt einen outcome-Abschnitt, mit dem Sie weitere Informationen aus einer Regel ableiten können. Die im Abschnitt outcome definierte Logik wird anhand jeder Erkennung ausgewertet. Wenn eine Regel N Erkannungen generiert, kann jede der N Erkannungen zu unterschiedlichen Ergebnissen führen.

Eine Beispielregel mit dem Abschnitt outcome finden Sie unter Regel mit Auswahl des Ergebnisses.

Ausführliche Informationen zur Verwendung und Syntax eines outcome-Abschnitts finden Sie im Abschnitt zu Ergebnissen.

Abschnitt „Ergebnis“ und Deduplizierung / Gruppierung von Erkennungen

Bei Regeln mit einem Abgleichsabschnitt werden die Erkennungen nach den Abgleichsvariablen gruppiert. Dadurch werden Erkennungen dedupliziert, sodass für jede eindeutige Kombination von Abgleichsvariablen und Zeitfenstern eine Zeile zurückgegeben wird.

Die Ergebnisvariablen werden bei dieser Deduplizierung ignoriert. Wenn es also zwei verschiedene Erkennungen mit denselben Werten für die Abgleichsvariablen und den Zeitfenster, aber mit unterschiedlichen Werten für die Ergebnisvariablen gibt, werden diese dedupliziert und Sie sehen nur eine Erkennung. Das kann beispielsweise passieren, wenn eine Erkennung aufgrund von verspätet eintreffenden Daten erstellt wurde. Hier ist ein Beispiel, das diesen Fall veranschaulicht.

rule ExampleOutcomeRule {
  ...
  match:
    $hostname over <some window>
  outcome:
    $risk_score = <some logic here>
  ...
}

Diese Regel führt zu den folgenden Übereinstimmungen:

Erkennung 1: hostname: test-hostname time window: [t1, t2] risk_score: 10

Erkennung 2: hostname: test-hostname time window: [t1, t2] risk_score: 73

Da die Abgleichsvariablen und das Zeitfenster für „Erkennung 1“ und „Erkennung 2“ identisch sind, werden sie dedupliziert und Sie sehen nur eine Erkennung, auch wenn sich die Ergebnisvariable „risk_score“ unterscheidet.

Nächste Schritte

Informationen dazu, wie Google SecOps Kontextdaten aufnimmt und Entitäten anreichert, finden Sie unter So werden Ereignis- und Entitätsdaten in Google SecOps angereichert.