Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Kontextsensitive Analysen erstellen

Mit Chronicle können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken als eine Erkennung in Ihrem Chronicle-Konto ansehen. Damit lässt sich sowohl die Verhaltensmuster der Telemetrie als auch der Kontext der betroffenen Entitäten anhand dieser Muster verstehen.

Beispiele:

  • Berechtigungen für ein Konto anzeigen, für das Brute-Force-Anmeldungen versucht werden.
  • Die Bedeutung der von einem Asset gehosteten Daten, die auch die Quelle der ausgehenden Netzwerkaktivitäten sind.

Kunden können diesen Kontext verwenden, um Filter zu erkennen, eine heuristische Benachrichtigung zu priorisieren, zu prüfen und zu untersuchen.

Sicherheitsanalysten und Erkennungsentwickler arbeiten in der Regel daran, eine Erkennung auf Basis eines grundlegenden Musters von Ereignistelemetrie (einer ausgehenden Netzwerkverbindung) zu erstellen, wodurch zahlreiche Erkennungsmechanismen für ihre Analysten erstellt werden. Die Analysten versuchen herauszufinden, was genau zur Benachrichtigung geführt hat und wie groß die Gefahr ist.

Kontextsensitive Analysen umfassen erweiterte Anreicherungsfunktionen zu Beginn des Workflows für die Erstellung und Ausführung der Erkennung. Dadurch können Sie die folgenden zusätzlichen Funktionen bereitstellen:

  • Bereitstellung relevanter Informationen für eine heuristische, kontextuelle Risikobewertung von Erkennungen zum Zeitpunkt der Erkennung und nicht bei der manuellen Einschätzung
  • Weniger Zeit für die Auswertung und manuelle Zusammenführung 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 Analystinnen und Analysten sowie Erkennungs-Engineer, ganze Cluster von Bedrohungen herauszufiltern, die möglicherweise erwartet werden oder nur eine geringe oder 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 Zugriffe)

Regeln für kontextsensitive Analysen erstellen

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

So suchen Sie nach Kontextdaten von Entitäten:

  1. Geben Sie eine Quelle mit der UUD oder der Entität an.

    $eventname.[<source>].field1.field2 Für einen Entitätskontext ist <source> 'graph'. Bei einem UDM-Ereignis ist <source> 'udm'. Wird kein Wert angegeben, wird 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 Aussagen 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 kann 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 auf Erkennung geprüft. Die Erkennungs-Engine erzwingt dies implizit und Sie müssen es 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 Tages-Buckets gibt, in denen der Entitätskontext seinen Wert ändert, versucht Chronicle, alle Entitätskontextwerte abzugleichen, und gibt alle gefundenen Übereinstimmungen zurück.

Beispielregeln

Entitäten mit Administratorkontext suchen

Mit der folgenden Regel wird nach Entitäten gesucht, die auch an Administratorberechtigungen gebunden sind. Es wird gesucht, wenn jemand mit Administratorberechtigung versucht hat, sich im System an- oder 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 fließendes Fenster

Das folgende Beispiel für das 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 das Schiebefenster ist ungültig: Der Entitätskontext kann nicht als Pivot 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 die Anmeldung mit dem Ergebnisbereich

Im folgenden Beispiel wird im Abschnitt outcome eine Risikobewertung 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-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 Kennzeichner für den Entitätskontext

Zum Erstellen einer Ereignisvariablen, die einen Entitätskontext verwendet, müssen Sie nach dem Ereignisnamen ein <source> angeben. Die <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 Kennzeichner im Regeltext beliebig kombinieren. Für dasselbe Ereignis können Sie auch verschiedene Kennzeichner verwenden.

Ergebnisbereich

Die Erkennungs-Engine unterstützt den Abschnitt 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 unterschiedlichen Ergebnissen führen.

Eine Beispielregel mit dem Abschnitt outcome findest du hier.

Ausführliche Informationen zur Nutzung und Syntax eines outcome-Abschnitts finden Sie in diesem Abschnitt.

Ergebnisabschnitt und Erkennungsgruppierung von Deduplizierung / Erkennung

Bei Regeln mit einem Abgleichsbereich werden die Erkennungen durch die Übereinstimmungsvariablen „gruppiert“. Dadurch werden Erkennungen dedupliziert, sodass für jeden eindeutigen Satz von Übereinstimmungsvariablen und das Zeitfenster eine Zeile zurückgegeben wird.

Die Ergebnisvariablen werden bei dieser Deduplizierung ignoriert. Wenn also zwei verschiedene Erkennungen mit denselben Werten für die Übereinstimmungsvariablen und das Zeitfenster vorhanden sind, aber mit unterschiedlichen Werten für Ergebnisvariablen, werden diese dedupliziert und Sie sehen nur eine Erkennung. Das kann passieren, wenn beispielsweise eine Erkennung aufgrund von spät ankommenden 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 time window: [t1, t2] risk_score: 10

Erkennung 2: hostname: test-hostname time window: [t1, t2] risk_score: 73

Da die Übereinstimmungsvariablen und das Zeitfenster für Erkennung 1 und Erkennung 2 identisch sind, werden sie dedupliziert und Sie sehen nur eine Erkennung, obwohl sich die Ergebnisvariable Risk_Score unterscheidet.

So geht es weiter: Chronicle reichert Ereignis- und Entitätsdaten an

Informationen dazu, wie Chronicle Kontextdaten aufnimmt und Entitäten angereichert, finden Sie unter So reichert Chronicle Ereignis- und Entitätsdaten an