Kontextbezogene Analysen

Unterstützt in:

Mit Google Security Operations können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken in Ihrem Google Security Operations-Konto als einzelne Erkennung aufrufen. 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:

  • 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 Priorisierung heuristischer Warnungen, die Triage und die Untersuchung verwenden.

Sicherheitsanalysten und Entwickler von Erkennungssystemen arbeiten in der Regel daran, eine Erkennung anhand eines einfachen 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 Erkennungen. So können Sie die folgenden zusätzlichen Funktionen nutzen:

  • Bereitstellung von relevantem Kontext für heuristische kontextbasierte Risikobewertungen zum Zeitpunkt der Erkennungsausführung und nicht in der menschlichen Triage-Phase
  • Verringerung der Zeit für die Triage und das manuelle Zusammenführen von Informationen aus verschiedenen IT-Sicherheitssystemen (EDR-Konsolen, Firewall-/Proxy-Logs, CMDB- und IAM-Kontext, Ergebnisse von Sicherheitslückenscans)
  • Möglichkeit für Analysten und Erkennungstechniker, ganze Cluster von Bedrohungen herauszufiltern, die erwartet werden 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 kontextbezogene Analysen schreiben

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

So suchen Sie nach Daten zum Entitätskontext:

  1. Geben Sie eine Quelle mit dem udm- oder dem Element an.

    $eventname.[<source>].field1.field2 Für einen Entitätskontext ist <source> „graph“. Bei einem UDM-Ereignis: <Quelle> ist „udm“. Wenn nicht angegeben, wird die <source> ist standardmäßig „udm“.

  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 Entitätskontext-Datensatz hat ein Zeitintervall, entity.metadata.interval, über für den der Entitätskontext gültig ist. Dieses Zeitintervall ist möglicherweise keine Tagesgrenze Die Dauer ist beliebig.

Ein UDM-Ereignis wird nur dann mit einem Entitätskontexteintrag korreliert, wenn das Ereignis Der Zeitstempel des UDM-Ereignisses liegt im Zeitintervall des Entitätskontexts Datensatz. 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 dies 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 Wert des Entitätskontexts ändert, versucht Google Security Operations, alle Entitätskontextwerte abzugleichen und alle gefundenen Übereinstimmungen zurückzugeben.

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 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 schiefes 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 ungültiges gleitendes Fenster

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 eine Anmeldung über den Ergebnisbereich

Im folgenden Beispiel wird der Abschnitt outcome verwendet, um eine Risikobewertung für die Erkennung.

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 den Start eines verdächtigen Prozesses

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 Einschränkungen für den 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

Alle diese Kennzeichner können im Regeltext beliebig kombiniert werden. Sie können für dasselbe Ereignis auch verschiedene Kennzeichner verwenden.

Abschnitt „Ergebnis“

Die Erkennungs-Engine unterstützt einen Abschnitt outcome, mit dem Sie mehr 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.

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

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

Bereich „Ergebnis“ und Deduplizierung/Gruppierung von Erkennungen

Bei Regeln mit einem Abgleichsabschnitt werden die Erkennungen nach den Abgleichsvariablen gruppiert. Dadurch werden Erkennungen dedupliziert, sodass eine Zeile wird für jeden eindeutigen Satz von Übereinstimmungsvariablen und Zeitfenstern zurückgegeben.

Die Ergebnisvariablen werden bei dieser Deduplizierung ignoriert. Wenn also Es gibt zwei verschiedene Erkennungen mit denselben Werten für die Übereinstimmungsvariablen. und Zeitfenster, aber mit unterschiedlichen Werten für Ergebnisvariablen, und Sie sehen nur eine Erkennung. Dies kann passieren, wenn ein z. B. 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 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 diese dedupliziert und Sie sehen nur eine Erkennung, auch wenn sich die Ergebnisvariable „risk_score“ unterscheidet.

Nächste Schritte

Weitere Informationen dazu, wie Google Security Operations kontextbezogene Daten aufnimmt und Entitäten anreichert, siehe So werden Ereignis- und Entitätsdaten durch Google Security Operations angereichert