Übersicht über kontextbezogene Analysen

Unterstützt in:

Mit Google SecOps können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken als einzelne Erkennung in Ihrem Google SecOps-Konto ansehen. 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 heraus verstehen können.

Beispiele:

  • Die Berechtigungen für ein Konto werden angezeigt, bei dem ein Brute-Force-Login versucht wird.
  • Bedeutung von Daten, die von einem Asset gehostet werden, das auch die Quelle für ausgehende Netzwerkaktivitäten ist.

Kunden können diese Kontextualisierung zum Filtern von Erkennungen, zur Priorisierung von heuristischen Warnungen, zur Triage und zur Untersuchung verwenden.

Sicherheitsanalysten und Detection Engineers erstellen in der Regel eine Erkennung auf Grundlage eines einfachen Musters von Ereignistelemetrie (einer ausgehenden Netzwerkverbindung), wodurch zahlreiche Erkennungen für ihre Analysten entstehen. Die Analysten versuchen, ein Verständnis dafür zu entwickeln, was den Alarm ausgelöst hat und wie schwerwiegend die Bedrohung ist.

Bei der kontextsensitiven Analyse werden erweiterte Anreicherungsfunktionen früher in den Workflow für die Erstellung und Ausführung von Erkennungen eingebunden. So können Sie die folgenden zusätzlichen Funktionen bereitstellen:

  • Relevanter Kontext für die heuristikbasierte kontextbezogene Risikobewertung von Erkennungen wird zum Zeitpunkt der Erkennung und nicht erst in der Phase der manuellen Triage bereitgestellt.
  • Weniger Zeitaufwand für die Triage und das manuelle Zusammenfügen von Informationen aus unterschiedlichen IT-Sicherheitssystemen (EDR-Konsolen, Firewall- oder Proxy-Logs, CMDB- und IAM-Kontext, Ergebnisse von Sicherheitslücken-Scans)
  • Analysten und Erkennungstechniker können so ganze Cluster von Bedrohungen herausfiltern, die erwartet werden oder nur eine geringe oder gar keine Gefahr für das Unternehmen darstellen (Malware-Tests in einer Sandbox-Umgebung, Sicherheitslücken und anomale Aktivitäten in einem Entwicklungsnetzwerk ohne vertrauliche Daten oder Zugriff usw.).

Regeln für kontextbezogene Analysen schreiben

Mit Detection Engine-Regeln können Sie in Ihrem Google SecOps-Konto nach Kontextdaten für Entitäten suchen.

So suchen Sie nach Kontextdaten für Entitäten:

  1. Geben Sie eine Quelle mit „udm“ oder „entity“ an.

    $eventname.[<source>].field1.field2 Bei einem Entitätskontext ist <source> „graph“. Bei einem UDM-Ereignis ist <source> „udm“. Wenn keine Angabe gemacht wird, 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 Anweisungen sind gleichwertig.

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

    $e1.principal.asset_id = "my_asset_id"

Sie können viele der gleichen Regeltypen für Entitätskontexte erstellen wie für UDM-Ereignisse, einschließlich der folgenden:

  • Mehrere Ereignisregeln

  • Entitätskontexte mit anderen Entitätskontexten vergleichen

  • Entitätskontexte mit UDM-Ereignissen vergleichen

  • Wiederkehrende Felder in Entitätskontexten

  • Schiebefenster

  • Risikobewertung für Erkennungen berechnen

Im Gegensatz zu einem UDM-Ereignis hat ein Entitätskontext keinen bestimmten Zeitstempel. Jeder Entitätskontextdatensatz hat ein Zeitintervall, entity.metadata.interval, für das der Entitätskontext gültig ist. Dieses Zeitintervall darf keine Tagesgrenze sein und kann eine beliebige Dauer haben.

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

  • Beim Vergleich von UDM-Ereignissen mit einem Entitätskontext mit Fensterung stellt ein Entitätskontext einen konstanten Wert über ein bestimmtes Fenster dar.
  • Wenn es angrenzende Tages-Buckets gibt, in denen sich der Wert des Entitätskontexts ändert, versucht Google SecOps, alle Werte des Entitätskontexts 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 versucht hat, im System anzumelden oder abzumelden.

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 gleitendes Fenster

Das folgende Beispiel für ein gleitendes Fenster 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 gleitendes Fenster

Das folgende Beispiel für ein gleitendes Fenster ist ungültig. Der Entitätskontext kann nicht als Pivot für ein gleitendes Fenster 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 verdächtige Prozessstarts

Im folgenden Beispiel werden UDM-Ereignisprozessdaten mit IOC-Kontextdaten verglichen, 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 Qualifizierer für den Entitätskontext

Wenn Sie eine Ereignisvariable erstellen möchten, die einen Entitätskontext verwendet, 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 gleichwertige Methoden, um auf ein UDM-Ereignis zu verweisen:

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

Sie können alle diese Qualifizierer im Regeltext kombinieren. Sie können auch verschiedene Qualifizierer für dasselbe Ereignis verwenden.

Abschnitt „Ergebnis“

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

Ein Beispiel für eine Regel, in der der Abschnitt outcome verwendet wird, finden Sie unter Regel mit Ergebnisauswahl.

Eine detaillierte Beschreibung der Verwendung und Syntax eines outcome-Abschnitts finden Sie im Abschnitt zu Ergebnissen.

Ergebnisbereich und Deduplizierung / Gruppierung von Erkennungen

Bei Regeln mit einem Abschnitt „Übereinstimmung“ werden Erkennungen nach den Übereinstimmungsvariablen gruppiert. Dadurch werden Erkennungen dedupliziert, sodass für jede eindeutige Kombination aus Abgleichsvariablen und Zeitfenster eine Zeile zurückgegeben wird.

Die Ergebnisvariablen werden bei dieser Deduplizierung ignoriert. Wenn es also zwei unterschiedliche Erkennungen mit denselben Werten für die Abgleichsvariablen und den Zeitraum, 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 eingegangenen 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 Zeitfenster: [t1, t2] Risikobewertung: 10

Erkennung 2: Hostname: test-hostname Zeitfenster: [t1, t2] Risikobewertung: 73

Da die Abgleichsvariablen und der Zeitraum für Erkennung 1 und Erkennung 2 identisch sind, werden diese dedupliziert. Sie sehen also nur eine Erkennung, obwohl sich die Ergebnisvariable „risk_score“ unterscheidet.

Nächste Schritte

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

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