Übersicht über kontextsensitive Analysen
Mit Google Security Operations können Sie Telemetrie, Entitätskontext, Beziehungen und Sicherheitslücken als einzelne Erkennung in Ihrem Google Security Operations-Konto ansehen. 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:
- Anzeigen der Berechtigungen für ein Konto, in dem eine Brute-Force-Anmeldung durchgeführt wird.
- Bedeutung von Daten, die von einem Asset gehostet werden, das auch die Quelle ausgehender Netzwerkaktivitäten ist
Kunden können diese Kontextisierung für das Filtern von Erkennungsmechanismen, die heuristische Priorisierung von Benachrichtigungen, die Ersteinschätzung und Untersuchung nutzen.
Sicherheitsanalysten und Erkennungstechniker arbeiten in der Regel an einer Erkennung anhand eines grundlegenden Musters von Ereignistelemetrie (eine ausgehende Netzwerkverbindung), sodass ihre Analysten zahlreiche Erkennungsmechanismen einstufen können. Die Analysten versuchen, eine Vorstellung davon zu bekommen, was passiert ist, um die Warnung auszulösen, und wie gravierend die Bedrohung ist.
Kontextsensitive Analysen umfassen erweiterte Anreicherungsfunktionen früher im Erstellungs- und Ausführungsworkflow für Erkennungen, sodass Sie die folgenden zusätzlichen Funktionen bereitstellen können:
- Bereitstellung von relevantem Kontext für heuristische kontextbasierte Risikobewertungen bei Erkennungsausführungen und nicht in der menschlichen Triage-Phase
- Geringerer Zeitaufwand für die Sichtung und das manuelle Zusammenfügen 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 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 kontextsensitive Analysen schreiben
Mit Regeln der Erkennungs-Engine können Sie in Ihrem Google Security Operations-Konto nach Entitätskontextdaten suchen.
Führen Sie die folgenden Schritte aus, um nach Entitätskontextdaten zu suchen:
Geben Sie eine Quelle mit dem udm- oder dem Element an.
$eventname.[<source>].field1.field2
Bei einem Entitätskontext <Quelle> ist „graph“. Bei einem UDM-Ereignis: <Quelle> ist „udm“. Wenn nicht angegeben, wird die <source> ist standardmäßig „udm“.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 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 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, ü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 ausgewertet. Erkennung. Die Erkennungs-Engine erzwingt dies implizit. Sie müssen dies nicht um sie als Bedingung in einer Regel festzulegen.
- 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, in denen der Entitätskontext seinen Wert ändert, versucht Google Security Operations, alle gefundenen Entitätskontextwerte abzugleichen.
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 eine Person mit Administratorrechten versucht hat, sich im System einzuloggen oder abzumelden.
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 gleitende Fenster
Das folgende Beispiel für gleitende 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 gleitende Fenster ist ungültig. Der Entitätskontext kann nicht als Drehpunkt 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
}
Beispiel für eine Anmeldung über den Bereich „Ergebnis“
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 einen verdächtigen Prozessstart
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 Qualifier für 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
Sie können alle diese Kennzeichner im Regeltext kombinieren. Sie können für dasselbe Ereignis auch verschiedene Kennzeichner verwenden.
Bereich „Ergebnis“
Das Erkennungsmodul unterstützt einen outcome
-Abschnitt, mit dem Sie weitere
Informationen aus einer Regel. Die im Abschnitt outcome
definierte Logik wird ausgewertet
gegen jede Erkennung. Wenn eine Regel N Erkennungen generiert, kann jede der N Erkennungen
die zu anderen 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
Bei Regeln mit einem Übereinstimmungsbereich werden Erkennungen „gruppiert nach“ angezeigt. die Übereinstimmungsvariablen auswählen. 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 ein Beispiel: das diesen Fall verdeutlicht.
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 2 – diese werden dedupliziert. nur eine Erkennung sehen, obwohl die Ergebnisvariable risk_score unterscheiden.
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