Kontextsensitive Analysen erstellen

Mit Google Security Operations können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken als zentrale Erkennung in Ihrem Google Security Operations-Konto aufrufen. Sie ermöglicht Entitätskontextisierung, damit Sie sowohl die Verhaltensmuster in der Telemetrie als auch den Kontext der betroffenen Entitäten aus diesen Mustern verstehen können.

Beispiele:

  • Berechtigungen für ein Konto abrufen, für das eine Brute-Force-Anmeldung versucht wird
  • Bedeutung der von einem Asset gehosteten Daten, die auch die Quelle ausgehender Netzwerkaktivitäten sind

Kunden können diese Kontextisierung für die Erkennungsfilterung, die Priorisierung von heuristischen Benachrichtigungen, die Ersteinschätzung und Untersuchung verwenden.

Sicherheitsanalysten und Erkennungstechniker arbeiten in der Regel daran, eine Erkennung anhand eines grundlegenden Musters der Ereignistelemetrie (einer ausgehenden Netzwerkverbindung) zu entwickeln. Dadurch werden zahlreiche Erkennungsmechanismen für die Analysten erstellt. Die Analysten versuchen herauszufinden, was die Auslösung der Warnung ausgelöst hat und wie groß die Bedrohung ist.

Die kontextsensitive Analyse beinhaltet erweiterte Anreicherungsfunktionen früher im Workflow zur Erstellung und Ausführung der Erkennung, sodass Sie die folgenden zusätzlichen Funktionen bereitstellen können:

  • Bereitstellung relevanter Kontexte für die heuristische kontextabhängige Risikobewertung von Erkennungen bei der Ausführung der Erkennung und nicht bei der menschlichen Einstufung
  • Weniger Zeitaufwand für die Sichtung und manuelles Zusammenfügen von Informationen aus unterschiedlichen IT-Sicherheitssystemen (EDR-Konsolen, Firewall-/Proxy-Logs, CMDB- und IAM-Kontext, Ergebnisse des Scannens auf Sicherheitslücken)
  • Analysten und Erkennungstechniker können ganze Cluster von Bedrohungen herausfiltern, die zu erwarten sind oder für das Unternehmen nur geringe oder gar keine Gefahr darstellen (z. B. Malware-Tests in einer Sandbox-Umgebung, Sicherheitslücken und ungewöhnliche Aktivitäten in einem Entwicklungsnetzwerk ohne sensible Daten oder Zugriff).

Regeln für kontextsensitive Analysen erstellen

Mithilfe von Detection Engine-Regeln 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 mit der Udm- oder der Entität an.

    $eventname.[<source>].field1.field2 Im Kontext einer Entität ist <source> 'graph'. Bei einem UDM-Ereignis ist <source> „udm“. Wenn keine Angabe gemacht wird, wird für <source> standardmäßig „udm“ verwendet.

  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"

Für Entitätskontexte können Sie viele der gleichen Regeltypen 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

  • Einen Risikowert 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, in dem der Entitätskontext gültig ist. Dieses Zeitintervall kann keine Tagesgrenze sein und kann eine beliebige Dauer sein.

Ein UDM-Ereignis wird nur dann mit einem Entitätskontextdatensatz 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 zur Erkennung ausgewertet. Die Erkennungs-Engine erzwingt dies implizit und Sie müssen sie 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, bei denen der Entitätskontext seinen Wert ändert, versucht Google Security Operations, einen Abgleich mit allen Entitätskontextwerten durchzuführen und alle gefundenen Übereinstimmungen zurückzugeben.

Beispielregeln

Nach Entitäten mit Administratorkontext suchen

Mit der folgenden Regel wird nach Entitäten gesucht, die auch an Administratorberechtigungen gebunden sind. Das System sucht nach Zeiten, in denen eine Person mit Administratorrechten versucht hat, sich im System an- 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 mit einem gleitenden 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 mit einem gleitenden Fenster ist ungültig. 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 Bereich „Ergebnis“

Im folgenden Beispiel wird anhand des Abschnitts outcome ein Risikowert für die Erkennung berechnet.

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 verdächtige Prozesseinführung

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 eine <source> angeben. <source> muss graph sein.

Das folgende Muster bezieht sich auf einen Entitätskontext:

  • $e.graph.entity.hostname

Es gibt zwei äquivalente Methoden zum Verweisen auf ein UDM-Ereignis:

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

Sie können diese Qualifier im Regeltext beliebig kombinieren. Sie können auch verschiedene Kennzeichner für dasselbe Ereignis verwenden.

Bereich „Ergebnis“

Das Erkennungsmodul unterstützt einen outcome-Abschnitt, in dem Sie weitere Informationen aus einer Regel ableiten können. Die im Abschnitt outcome definierte Logik wird gegen jede Erkennung ausgewertet. Wenn eine Regel n Erkennungen generiert, kann jede der n Erkennungen zu unterschiedlichen Ergebnissen führen.

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

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

Ergebnisbereich und Erkennungsdeduplizierung / Erkennungsgruppierung

Denken Sie bei Regeln mit einem Übereinstimmungsabschnitt daran, dass die Erkennungen nach den Übereinstimmungsvariablen „gruppiert“ werden. Dies führt dazu, dass Erkennungen dedupliziert werden, 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 Erkennungsarten mit denselben Werten für die Übereinstimmungsvariablen und dem 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 eingetroffenen 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 es wird nur eine Erkennung angezeigt, auch wenn die Ergebnisvariable „risk_score“ unterschiedlich ist.

Nächste Schritte

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