Kontextsensitive Analysen erstellen

Mit Google Security Operations können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken als einzelne Erkennung in Ihrem Google Security Operations-Konto ansehen. Sie ermöglicht die Kontextisierung von Entitäten, damit Sie sowohl die Verhaltensmuster in der Telemetrie als auch den Kontext der betroffenen Entitäten anhand dieser Muster nachvollziehen können.

Beispiele:

  • Anzeigen der Berechtigungen für ein Konto, in dem eine Brute-Force-Anmeldung versucht wird
  • Bedeutung von Daten, die von einem Asset gehostet werden, das auch die Quelle ausgehender Netzwerkaktivitäten ist

Kunden können diese Kontextisierung für das Filtern von Erkennungsmechanismen, die heuristische Priorisierung von Benachrichtigungen, die Ersteinschätzung und Untersuchung nutzen.

Sicherheitsanalysten und Erkennungstechniker arbeiten in der Regel an einer Erkennung anhand eines grundlegenden Musters von Ereignistelemetrie (eine ausgehende Netzwerkverbindung), sodass ihre Analysten zahlreiche Erkennungsmechanismen einstufen können. Die Analysten versuchen, eine Vorstellung davon zu bekommen, was passiert ist, um die Warnung auszulösen, und wie gravierend die Bedrohung ist.

Kontextsensitive Analysen umfassen erweiterte Anreicherungsfunktionen früher im Erstellungs- und Ausführungsworkflow für Erkennungen, sodass Sie die folgenden zusätzlichen Funktionen bereitstellen können:

  • Bereitstellung von relevantem Kontext für heuristische kontextbasierte Risikobewertungen zum Zeitpunkt der Erkennungsausführung und nicht in der menschlichen Triage-Phase
  • Geringerer Zeitaufwand für die Sichtung und das manuelle Zusammenfügen von Informationen aus unterschiedlichen IT-Sicherheitssystemen (EDR-Konsolen, Firewall-/Proxy-Logs, CMDB- und IAM-Kontext, Ergebnisse des Scans auf Sicherheitslücken)
  • Möglichkeit für Analysten und Erkennungstechniker, ganze Cluster von Bedrohungen herauszufiltern, die möglicherweise zu erwarten sind oder nur wenig oder gar keine Gefahr für das Unternehmen darstellen (Malware-Tests in einer Sandbox-Umgebung, Sicherheitslücken und ungewöhnliche Aktivitäten in einem Entwicklungsnetzwerk ohne sensible Daten oder Zugriffsrechte usw.)

Regeln für kontextsensitive Analysen schreiben

Mit Regeln der Erkennungs-Engine können Sie in Ihrem Google Security Operations-Konto nach Entitätskontextdaten suchen.

Führen Sie die folgenden Schritte aus, um nach Entitätskontextdaten zu suchen:

  1. Geben Sie eine Quelle mithilfe von udm oder Entität 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 <source> auf „udm“ gesetzt.

  2. Geben Sie die Entitätsdaten an:

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

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

  3. Geben Sie UDM-Ereignisdaten an. Die folgenden Anweisungen sind äquivalent.

    $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 wie für UDM-Ereignisse erstellen, darunter:

  • 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ätskontexteintrag hat ein Zeitintervall, entity.metadata.interval, über 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 Entitätskontexteintrag korreliert, wenn der Zeitstempel des UDM-Ereignisses in das Zeitintervall des Entitätskontexteintrags fällt. Wenn diese Bedingung nicht erfüllt ist, werden die UDM und die Entität nicht auf Erkennungszwecke geprüft. Die Erkennungs-Engine erzwingt dies implizit und Sie müssen dies nicht als Bedingung in einer Regel angeben.

  • Beim Vergleich von UDM-Ereignissen mit einem Entitätskontext mit Windowing stellt ein Entitätskontext einen konstanten Wert über ein bestimmtes Fenster dar.
  • Wenn es benachbarte Tages-Buckets gibt, in denen der Entitätskontext seinen Wert ändert, versucht Google Security Operations, alle gefundenen Entitätskontextwerte abzugleichen.

Beispielregeln

Im Administratorkontext nach Entitäten suchen

Mit der folgenden Regel wird nach Entitäten gesucht, die auch Administratorberechtigungen haben. Es wird nach Zeiten gesucht, zu denen eine Person mit Administratorrechten versucht hat, sich im System einzuloggen 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 gleitende 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 ungültiges gleitendes Fenster

Das folgende Beispiel für gleitende Fenster ist ungültig. Der Entitätskontext kann nicht als Drehpunkt 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 eine Anmeldung über den Bereich „Ergebnis“

Im folgenden Beispiel wird der Abschnitt outcome verwendet, um eine Risikobewertung 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.target.user.termination_date.seconds > 0

    $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 einen verdächtigen Prozessstart

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 Qualifier für Entitätskontext

Wenn Sie eine Ereignisvariable erstellen möchten, die einen Entitätskontext verwendet, müssen Sie nach dem Ereignisnamen <source> angeben. <source> muss graph sein.

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 Kennzeichner im Regeltext kombinieren. Sie können für dasselbe Ereignis auch verschiedene Kennzeichner verwenden.

Bereich „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 im Hinblick auf jede Erkennung ausgewertet. Wenn eine Regel N Erkennungen generiert, kann jede der N Erkennungen zu anderen Ergebnissen führen.

Hier finden Sie eine Beispielregel, die den Abschnitt outcome verwendet.

Detaillierte Informationen zur Verwendung und Syntax eines outcome-Abschnitts finden Sie in diesem Abschnitt.

Ergebnisbereich und Erkennungsdeduplizierung / Erkennungsgruppierung

Bei Regeln mit einem Übereinstimmungsbereich sollten Sie daran denken, dass Erkennungen nach den Übereinstimmungsvariablen „gruppiert“ werden. Dadurch werden Erkennungen dedupliziert, sodass für jeden eindeutigen Satz von Übereinstimmungsvariablen und jedes Zeitfenster eine Zeile zurückgegeben wird.

Die Ergebnisvariablen werden bei dieser Deduplizierung ignoriert. Wenn es also zwei verschiedene Erkennungen mit denselben Werten für die Übereinstimmungsvariablen und das gleiche Zeitfenster, aber mit unterschiedlichen Werten für Ergebnisvariablen gibt, werden diese dedupliziert und es wird nur eine Erkennung angezeigt. Dies kann beispielsweise der Fall sein, wenn eine Erkennung aufgrund von spät ankommenden 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 folgenden Übereinstimmungen:

Erkennung 1: Hostname: test-hostname Zeitfenster: [t1, t2] risk_score: 10

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

Da die Übereinstimmungsvariablen und das Zeitfenster für Erkennung 1 und Erkennung 2 identisch sind, werden diese dedupliziert und Sie sehen nur eine Erkennung, obwohl die Ergebnisvariable risk_score unterschiedlich ist.

Nächste Schritte

Informationen dazu, wie Google Security Operations kontextbezogene Daten aufnimmt und Entitäten anreichert, finden Sie unter Ereignis- und Entitätsdaten mit Google Security Operations anreichern.