Kontextsensitive Analysen erstellen

Mit Chronicle können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken als einzelne Erkennung in Ihrem Chronicle-Konto sehen. Er bietet 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 versucht wird, sich per Brute-Force-Anmeldung anzumelden.
  • Die Bedeutung von Daten, die von einem Asset gehostet werden, das auch die Quelle ausgehender Netzwerkaktivitäten ist

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

Sicherheitsanalysten und Erkennungstechniker arbeiten in der Regel daran, eine Erkennung anhand eines grundlegenden Musters der Ereignistelemetrie (einer ausgehenden Netzwerkverbindung) zu entwickeln und so zahlreiche Erkennungsmechanismen für die Analyse durch die Analysten zu erstellen. Die Analysefachkräfte versuchen, sich ein Bild davon zusammenzutragen, was passiert ist, um die Warnung auszulösen und wie wichtig die Bedrohung ist.

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

  • Bereitstellung von relevantem Kontext für die heuristische kontextabhängige Risikobewertung von Erkennungsvorgängen bei der Ausführung der Erkennung statt bei der menschlichen Sichtung
  • Reduzierung des Zeitaufwands für die Sortierung 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 eine geringe bzw. keine Gefahr für das Unternehmen 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

Sie können mit Detection Engine-Regeln nach Entitätskontextdaten in Ihrem Chronicle-Konto suchen.

So suchen Sie nach Entitätskontextdaten:

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

    $eventname.[<source>].field1.field2 Für einen Entitätskontext ist <Quelle> '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"

Sie können für Entitätskontexte 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

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

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 UDM und 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 Chronicle, 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. Es wird nach Zeiten gesucht, in denen jemand mit Administratorrechten versucht hat, sich im System anzumelden oder sich abzumelden.

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

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

    $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 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. 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
}

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

Im folgenden Beispiel werden UDM-Ereignisverarbeitungsdaten 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

Beachten Sie, dass es zwei äquivalente Methoden zum Verweisen auf ein UDM-Ereignis gibt:

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

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

Bereich „Ergebnis“

Die Erkennungs-Engine unterstützt den Abschnitt outcome, über den Sie weitere Informationen aus einer Regel ableiten können. Die im Abschnitt outcome definierte Logik wird bei jeder 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 Informationen zur 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. 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 Erkennungsarten mit denselben Werten für die Übereinstimmungsvariablen und das Zeitfenster, aber mit unterschiedlichen Werten für die Ergebnisvariablen gibt, werden diese dedupliziert und Sie sehen nur eine Erkennung. 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, auch wenn die Ergebnisvariable „risk_score“ anders ist.

Nächste Schritte

Informationen dazu, wie Chronicle kontextbezogene Daten aufnimmt und Entitäten anreichert, finden Sie unter So reichert Chronicle Ereignis- und Entitätsdaten an