CBN-Benachrichtigungen zu Benachrichtigungen für YARA-L-Erkennungsregeln migrieren
In diesem Dokument erfahren Sie, wie Sie Benachrichtigungen zur konfigurationsbasierten Normalisierung (Configuration Based Normalization, CBN) zu YARA-L-Erkennungsbenachrichtigungen migrieren. Als Sicherheitsanalyst können Sie mithilfe dieses Dokuments weiterhin Benachrichtigungen zu Warnungen von Drittanbietersystemen über die Seite Warnungen und IOCs erhalten.
CBN-Benachrichtigungen zur YARA-L-Erkennungs-Engine migrieren
Wenn Sie CBN-Benachrichtigungen migrieren möchten, können Sie mit den folgenden Optionen dafür sorgen, dass Ihre bisherigen CBN-Benachrichtigungen als Benachrichtigungen für Erkennungsregeln verfügbar sind.
UDM-Suche verwenden
Mit der UDM-Suchoption können Sie sich Ereignisse mit der in den Parsern festgelegten alert_state
ansehen:
security_result.alert_state = "ALERTING"
In den UDM-Suchergebnissen können Sie die folgenden Felder untersuchen, um zu ermitteln, welche Quellen CBN-Benachrichtigungen in Ihrer Umgebung generieren:
Metadata
>Vendor Name
Metadata
>Product Name
Standard-CBN-Benachrichtigungen mit der Tools API herunterladen und manuell prüfen
Mit dem vorherigen Ansatz können Sie Benachrichtigungen finden, die ausgelöst wurden. Er deckt jedoch nicht den Fall von Benachrichtigungen ab, die Sie noch nie gesehen haben.
Mit der backstory.googleapis.com/v1/tools/cbn
-Parsermethode können Sie standardmäßige, ausgewählte oder alle CBNs herunterladen und die angewendete Parserlogik manuell prüfen, um is_alert
- oder alert_state
-basierte Benachrichtigungen zu finden.
Sie können CBN-Benachrichtigungen in Benachrichtigungen für YARA-L-Erkennungsregeln umwandeln, die Sie aktiv verwenden.
Windows Defender-Antiviruswarnungen migrieren, die zuvor in Enterprise Insights als CBN-Warnungen angezeigt wurden
Im folgenden Beispiel wird gezeigt, wie Sie Windows Defender-Antiviruswarnungen migrieren, die zuvor in Enterprise Insights als CBN-Warnungen angezeigt wurden.
Mit einer der zuvor beschriebenen Methoden können Sie sich ein Beispiel für eine Benachrichtigung ansehen.
Kopieren Sie mit der Raw Log / UDM Event Viewer ausgewählte UDM-Felder, die eine zuverlässige Erkennung ermöglichen. Sehen Sie sich folgendes Beispiel an.
metadata.vendor_name = "Microsoft" metadata.product_name = "Windows Defender AV" metadata.product_event_type = "MALWAREPROTECTION_STATE_MALWARE_DETECTED" principal.asset.hostname = "client02.example.local" security_result.action = "BLOCK" security_result.severity = "MEDIUM"
Erstellen Sie eine neue Regel für die YARA-L-Erkennungs-Engine.
rule windows_defender_av_monitored_events { meta: author = "Chronicle" description = "Migration of CBN alerts to Google Security Operations YARA-L detection engine rule alert." // Severity is set at the Outcome level via security_result.severity severity = "INFORMATIONAL" priority = "INFORMATIONAL" events: $windows_defender_av.metadata.vendor_name = "Microsoft" $windows_defender_av.metadata.product_name = "Windows Defender AV" $windows_defender_av.metadata.product_event_type = "MALWAREPROTECTION_STATE_MALWARE_DETECTED" $windows_defender_av.principal.asset.hostname = $host // optionally tune to only detection on ALLOW, i.e., failure to BLOCK //$windows_defender_av.security_result.action = "ALLOW" // optionally tune on severity of detection //$windows_defender_av.security_result.severity != "LOW" outcome: $risk_score = max( if ($windows_defender_av.security_result.severity = "UNKNOWN_SEVERITY", 0) + if ($windows_defender_av.security_result.severity = "LOW", 25) + if ($windows_defender_av.security_result.severity = "MEDIUM", 50) + if ($windows_defender_av.security_result.severity = "HIGH", 75) + if ($windows_defender_av.security_result.severity = "CRITICAL", 100) ) $severity = array_distinct($windows_defender_av.security_result.severity) condition: $windows_defender_av }
Für die CBN-Benachrichtigung wird anscheinend ein Feld verwendet, das nicht in UDM geparst wurde
Mit der Option „Parsererweiterungen“ können Sie dieses Problem schnell beheben.
Bei der Corelight-CBN-Benachrichtigung wird beispielsweise das Feld notice
verwendet und es wird nur dann eine bedingte Benachrichtigung gesendet, wenn der Wert wahr ist:
if [notice] == "true" {
mutate {
replace => {
"is_significant" => "true"
"is_alert" => "true"
}
}
}
Da dieser Wert standardmäßig nicht in UDM normalisiert wird, können Sie mit einer Parsererweiterung von Grok wie unten beschrieben vorgehen, um diesen Wert als UDM-Feld vom Typ Additional
hinzuzufügen:
filter {
mutate {
replace => {
"notice" => ""
}
}
grok {
match => { "message" => [ "(?P<message>\{.*\})$" ] }
on_error => "_grok_not_syslog"
overwrite => [ "message" ]
}
json {
on_error => "not_json"
source => "message"
array_function => "split_columns"
}
if ![not_json] {
if [notice] != "" {
mutate {
convert => {
"notice" => "string"
}
}
mutate {
replace => {
"additional_notice.key" => "notice"
"additional_notice.value.string_value" => "%{notice}"
}
}
mutate {
merge => {
"event1.idm.read_only_udm.additional.fields" => "additional_notice"
}
}
mutate {
merge => {
"@output" => "event1"
}
}
}
}
}
Sie können diese dann in einer YARA-L-Erkennungsregel wie unten beschrieben und mithilfe der Maps-Funktion verwenden:
events:
// Corelight : Weird Log
(
$corelight.metadata.vendor_name = "Corelight" and
$corelight.metadata.product_name = "Zeek" and
// this requires a custom parser extension to extract notice
$corelight.metadata.product_event_type = "weird" and
$corelight.additional.fields["notice"] = "true"
)
Sie müssen die erstellten Regeln für Benachrichtigungen aktivieren. Weitere Informationen finden Sie unter Live-Daten für Regeln ausführen.