Kontextsensitive Analysen erstellen

Mit Chronicle können Sie Telemetrie-, Entitätskontext, Beziehungen und Sicherheitslücken als eine Erkennung in Ihrem Chronicle-Konto aufrufen. Sie bietet Kontextkontexte, mit denen Sie die Verhaltensmuster der Telemetrie und den Kontext dieser betroffenen Entitäten aus diesen Mustern verstehen können.

Beispiele:

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

Kunden können diesen Kontext zum Erkennen von Filtern, Heuristik, Priorisierung und Prüfung verwenden.

Sicherheitsanalysten und Erkennungsentwickler arbeiten in der Regel daran, eine Erkennung anhand eines grundlegenden Musters von Ereignistelemetrie (einer ausgehenden Netzwerkverbindung) zu erstellen. Dadurch werden zahlreiche Erkennungsfunktionen für die Analysten erstellt. Die Analysten versuchen, die Benachrichtigungen zu analysieren und herauszufinden, wie hoch die Bedrohung ist.

Die kontextsensitive Analyse umfasst erweiterte Analysefunktionen zu einem früheren Zeitpunkt im Workflow für die Erkennung und Ausführung. So können Sie die folgenden zusätzlichen Funktionen nutzen:

  • Relevanter Kontext für die heuristische Analyse des Kontextrisikos bei der Erkennung bei der Erkennung, nicht bei der menschlichen Einschätzung
  • Reduzieren der Zeit für die Sichtung und Zusammenführung von Informationen aus unterschiedlichen IT-Sicherheitssystemen (EDR-Konsolen, Firewall-/Proxyprotokolle, CMDB- und IAM-Kontext, Ergebnisse des Scannens auf Sicherheitslücken)
  • Ermöglicht Analysten und Erkennungsentwicklern, ganze Cluster von Bedrohungen herauszufiltern, die zu erwarten sind oder für das Unternehmen nur eine geringe oder keine Gefahr darstellen (Malware-Tests in einer Sandbox-Umgebung, Sicherheitslücken und ungewöhnliche Aktivitäten in einem Entwicklungsnetzwerk ohne sensible Daten oder Zugriffe usw.)

Regeln für kontextsensitive Analysen schreiben

Mit Erkennungsregeln können Sie in Ihrem Chronicle-Konto nach Entitätskontextdaten suchen.

So suchen Sie nach Kontextdaten von Entitäten:

  1. Geben Sie entweder mit udm oder entity eine Quelle an.

    $eventname.[<source>].field1.field2 Für einen Entitätskontext ist <source> &&339;graph'. Für ein UDM-Ereignis ist <source> 'udm'. Wenn diese Richtlinie nicht angegeben ist, wird &ud;source> standardmäßig auf udm eingestellt.

  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 ä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 erstellen wie bei UDM-Ereignissen, darunter:

  • Mehrere Ereignisregeln

  • Entitätskontexte mit anderen Entitätskontexten vergleichen

  • Entitätskontexte mit UDM-Ereignissen vergleichen

  • Wiederkehrende Felder in Entitätskontexten

  • Schiebefenster

  • Risikowert für Erkennungsvorgänge berechnen

Im Gegensatz zu einem UDM-Ereignis hat ein Entitätskontext keinen bestimmten Zeitstempel. Jeder Entitätskontext hat einen Zeitraum, über den die Verknüpfung gültig ist. Der Zeitraum muss nicht an einer Tagesgrenze beginnen und kann eine beliebige Dauer haben.

  • 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 nebeneinanderliegende Tages-Buckets gibt, bei denen sich der Entitätskontext des Werts ändert, versucht Chronicle, alle Entitätskontext-Werte abzugleichen und gibt alle gefundenen Übereinstimmungen zurück.

Beispielregeln

Nach Entitäten mit Administratorkontext suchen

Mit der folgenden Regel wird nach Entitäten gesucht, die auch an Administratorberechtigungen gebunden sind. Es wird erfasst, wann jemand mit Administratorberechtigung versucht hat, sich im System anzumelden oder abzumelden.

rule LoginLogout {
  meta:
  events:
    $log_in.metadata.event_type = "USER_LOGIN"
    $log_in.principal.user.user_display_name = $user
    $log_in.principal.user.userid = "alice"

    $log_out.metadata.event_type = "USER_LOGOUT"
    $log_out.principal.user.user_display_name = $user
    $log_out.principal.user.userid = "alice"

    $log_in.metadata.event_timestamp.seconds <=
     $log_out.metadata.event_timestamp.seconds

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

  match:
    $user over 2m

  condition:
    $log_in and $log_out and $context
}

Beispiel für Schiebefenster

Das folgende Beispiel für den Schiebefenster 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 Schiebefenster

Das folgende Beispiel für den Schiebefenster ist ungültig. Der Entitätskontext kann nicht als Pivot-Element für ein Schiebefenster 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 den Log-in mit Ergebnisbereich

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.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ätkontext 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 Kennzeichner für Entitätskontext

Zum Erstellen einer Ereignisvariablen, die einen Entitätskontext verwendet, muss nach dem Ereignisnamen ein <source> angegeben werden. <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. Für dasselbe Ereignis können Sie außerdem verschiedene Kennzeichner verwenden.

Ergebnisbereich

Die Erkennungs-Engine unterstützt den Bereich outcome, mit dem Sie weitere Informationen von einer Regel ableiten können. Die im Abschnitt outcome definierte Logik wird anhand jeder Erkennung ausgewertet. Wenn eine Regel N-Erkennungen generiert, kann jede der N-Erkennungen zu einem anderen Ergebnis führen.

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

Weitere Informationen zur Nutzung und Syntax eines outcome-Abschnitts finden Sie in diesem Abschnitt.

Erkennung und Deduplizierung von Ergebnisabschnitten und Erkennungsgruppierung

Für Regeln mit einem Abgleichsbereich müssen die Erkennungen durch die Übereinstimmungsvariablen „gruppiert“ sein. Dadurch werden Erkennungen dedupliziert, sodass für jede eindeutige Gruppe von Übereinstimmungsvariablen und Zeitfenster ein Zeilenwert zurückgegeben wird.

Die Ergebnisvariablen werden bei dieser Deduplizierung ignoriert. Wenn es beispielsweise zwei verschiedene Erkennungen mit denselben Werten für die Abgleichsvariablen und das Zeitfenster gibt, aber unterschiedliche Werte für Ergebnisvariablen, werden diese dedupliziert und Sie sehen nur eine Erkennung. Dies kann passieren, wenn beispielsweise eine Erkennung aufgrund von spät eingehenden Daten erstellt wurde. Hier ein Beispiel für diesen Fall.

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] Risiko_Score: 10

Erkennung 2: hostname: test-hostname Zeitfenster: [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, obwohl die Ergebnisvariable „risk_score“ anders ist.