Kontextsensitive Analysen erstellen
Mit Chronicle können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken als eine Erkennung in Ihrem Chronicle-Konto ansehen. Sie bietet Entitätskontextualisierung, damit Sie die Verhaltensmuster in der Telemetrie und den Kontext der betroffenen Entitäten anhand dieser Muster verstehen können.
Beispiele:
- Berechtigungen für ein Konto anzeigen, für das ein Brute-Force-Log-in versucht wird.
- Die Bedeutung der von einem Asset gehosteten Daten, die auch die Quelle der ausgehenden Netzwerkaktivitäten sind.
Kunden können mit dieser Kontexterkennung Erkennungsfilterung, heuristische Benachrichtigungen priorisieren, untersuchen und untersuchen.
Sicherheitsanalysten und Erkennungsentwickler arbeiten in der Regel daran, eine Erkennung anhand eines grundlegenden Musters von Ereignistelemetrie (einer ausgehenden Netzwerkverbindung) zu erstellen. Damit können die Analystinnen und Analystinnen und -Analysten dann viele Erkennungsmechanismen identifizieren. Die Analystinnen und Analysten versuchen, herauszufinden, was die Benachrichtigung ausgelöst hat und wie hoch die Bedrohung ist.
Bei der kontextsensitiven Analyse werden erweiterte Anreicherungsfunktionen bereits früher im Workflow für die Erkennungserstellung und -ausführung eingebunden, sodass Sie folgende zusätzliche Funktionen zur Verfügung stellen können:
- Relevante Informationen für heuristisches Kontext-Risikobewertung von Erkennungsmechanismen zur Zeitpunkt der Erkennung und nicht während der manuellen Bewertung bereitstellen
- Weniger Zeitaufwand für die Auswahl und manuelle Zusammenführung von Informationen aus verschiedenen IT-Sicherheitssystemen (EDR-Konsolen, Firewall-/Proxy-Logs, CMDB- und IAM-Kontext, Ergebnisse des Scannens auf Sicherheitslücken)
- Analystinnen und Analysten und Erkennungstechniker haben die Möglichkeit, ganze Cluster schädlicher Bedrohungen herauszufiltern oder nur wenig oder gar keine Gefahr für das Unternehmen zu erkennen (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 schreiben
Mit den Erkennungs-Engine-Regeln können Sie in Ihrem Chronicle-Konto nach Entitätskontextdaten suchen.
So suchen Sie nach Entitätkontextdaten:
Geben Sie eine Quelle an, indem Sie entweder „udm“ oder „entity“ verwenden.
$eventname.[<source>].field1.field2Für einen Entitätskontext ist <source> „graph“. Bei einem UDM-Ereignis ist <source> „udm“. Wenn keine Angabe gemacht wird, wird standardmäßig udm als <source> verwendet.Geben Sie die Entitätsdaten an:
$e1.graph.entity.hostname = "my-hostname"$e1.graph.entity.relations.relationship = "OWNS"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 Erkennung 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 umfassen.
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 auf Erkennung geprüft. 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 angrenzende Buckets mit Tagenswerte gibt, in denen der Entitätskontext seinen Wert ändert, versucht Chronicle, alle Entitätskontextwerte abzugleichen und alle gefundenen Übereinstimmungen zurückzugeben.
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 beim 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 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 fließendes Fenster
Das folgende Beispiel für ein gleitendes Fenster 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 im Bereich für Ergebnisse
Im folgenden Beispiel wird der Abschnitt outcome verwendet, um eine Risikobewertung 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ä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
Zum Erstellen einer Ereignisvariablen mit einem Entitätskontext müssen Sie nach dem Ereignisnamen ein <source> angeben. Die <source> muss graph sein.
Das folgende Muster verweist auf einen Entitätskontext:
$e.graph.entity.hostname
Es gibt zwei gleichwertige 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. Sie können auch verschiedene Qualifizierer für dasselbe Ereignis verwenden.
Ergebnisbereich
Die Erkennungs-Engine unterstützt den Abschnitt outcome, mit dem Sie weitere Informationen aus einer Regel ableiten können. Die im Abschnitt outcome definierte Logik wird anhand jeder Erkennung ausgewertet. Wenn eine Regel N-Erkennungen generiert, kann jede N-Erkennung zu einer anderen Gruppe von Ergebnissen führen.
Eine Beispielregel mit dem Abschnitt outcome finden Sie hier.
Weitere Informationen zur Nutzung und Syntax eines outcome-Abschnitts finden Sie in diesem Abschnitt.
Ergebnisbereich und Erkennungsduplizierung/-erkennungsgruppierung
Für Regeln mit einem Abgleichsbereich müssen die Erkennungsvariablen „gruppiert nach“ sein. 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 unterschiedliche Werte für die 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:
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 Abgleichvariablen und das Zeitfenster für Erkennung 1 und Erkennung 2 identisch sind, werden sie dedupliziert. Sie sehen dann nur eine Erkennung, obwohl die Ergebnisvariable Risk_Score anders ist.
Nächste Schritte
Weitere Informationen dazu, wie Chronicle Kontextdaten aufnimmt und Entitäten anreichert, finden Sie unter Wie Chronicle Ereignis- und Entitätsdaten anreichert.