Cómo migrar alertas de CBN a alertas de reglas de detección de YARA-L
En este documento, se proporciona información para migrar la normalización basada en la configuración (CBN) para las alertas de detección de YARA-L. Como analista de seguridad, con la ayuda de puedes seguir recibiendo notificaciones de alertas de sistemas externos a través del IOC y alertas.
Migra las alertas de CBN al motor de detección YARA-L
Para migrar las alertas del CBN, asegúrate de que tus alertas anteriores disponibles como alertas de reglas de detección con las siguientes opciones.
Usar la búsqueda de UDM
Mediante la opción de búsqueda de UDM, puedes ver eventos con el alert_state
configurado en los analizadores:
security_result.alert_state = "ALERTING"
En los resultados de la búsqueda de la AUA, puedes explorar los siguientes campos para comprender cuáles fuentes generan alertas de CBN en tu entorno:
Metadata
>Vendor Name
Metadata
>Product Name
Descarga alertas de CBN predeterminadas con la API de Tools y revísalas manualmente
El enfoque anterior te ayuda a encontrar las alertas que se activaron, pero no
te explicaré la situación de alertas
que no viste antes.
Puedes usar el método de analizadores backstory.googleapis.com/v1/tools/cbn
para descargar
de forma predeterminada, seleccionarlos o todos los CBN, y revisar manualmente la lógica del analizador que se aplicó
buscar alertas basadas en is_alert
o alert_state
.
Puedes transferir alertas de CBN a alertas de reglas del motor de detección YARA-L que usar.
Migra las alertas de antivirus de Windows Defender que se mostraron anteriormente en Enterprise Insights como alertas de CBN
En el siguiente ejemplo, se muestra cómo puedes migrar las alertas del antivirus Windows Defender que antes se mostraban en Enterprise Insights como alertas de CBN.
Busca una alerta de ejemplo con cualquiera de los enfoques que se explicaron anteriormente.
Con el visualizador de registros sin procesar / eventos de UDM, copia los campos de UDM seleccionados que proporcionarán una detección confiable. Consulta el siguiente ejemplo.
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"
Crea una nueva regla del motor de detección de YARA-L.
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 }
La alerta de CBN parece usar un campo que no se analizó en UDM
Con la opción de extensiones del analizador, puedes resolver esta situación rápidamente.
Por ejemplo, la alerta de CBN de Corelight usa el campo notice
y genera alertas condicionales solo si es verdadero:
if [notice] == "true" {
mutate {
replace => {
"is_significant" => "true"
"is_alert" => "true"
}
}
}
Debido a que este valor no está normalizado en UDM de forma predeterminada, puedes usar un analizador
extensión Grok de la siguiente manera para agregar ese valor como un campo UDM de tipo Additional
:
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"
}
}
}
}
}
Luego, puedes utilizarlo en una regla de motor de detección YARA-L de la siguiente manera, y con la función Maps:
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"
)
Debes habilitar y activar las reglas creadas para las alertas. Para obtener más información, consulta Ejecuta datos activos de la regla.