Migra las alertas de CBN a alertas de reglas de detección de YARA-L
En este documento, se proporcionan detalles sobre cómo migrar las alertas de normalización basada en la configuración (CBN) a las alertas de detección de YARA-L. Como analista de seguridad, con la ayuda de este documento, puedes seguir recibiendo notificaciones de alertas de sistemas de terceros a través de la página Alertas y IOC.
Cómo migrar alertas de CBN al motor de detección YARA-L
Para migrar las alertas de CBN, puedes asegurarte de que las alertas de CBN anteriores estén disponibles como alertas de reglas de detección con las siguientes opciones.
Cómo usar la búsqueda de UDM
Con la opción de búsqueda de la AUA, puedes ver los eventos con el alert_state establecido 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 NameMetadata>Product Name
Descarga las alertas predeterminadas de CBN con la API de Tools y revísalas manualmente
El enfoque anterior te ayuda a encontrar alertas que se activaron, pero no cubre el caso de alertas que no habías visto antes.
Puedes usar el método de analizadores backstory.googleapis.com/v1/tools/cbn para descargar los CBN predeterminados, seleccionados o todos, y revisar manualmente la lógica del analizador que se aplica para encontrar alertas basadas en is_alert o alert_state.
Puedes transferir las alertas de CBN a las alertas de reglas del motor de detección YARA-L que usas de forma activa.
Migra las alertas del antivirus de Windows Defender que antes se mostraban 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 visor de eventos de registro sin procesar o de la AUA, copia los campos de la AUA 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 la UDM.
Con la opción de extensiones del analizador, puedes abordar 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"
}
}
}
Como este valor no se normaliza en la UDM de forma predeterminada, puedes usar una extensión de analizador Grok de la siguiente manera para agregar ese valor como un campo de 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 usar esto en una regla del 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 Cómo ejecutar datos en vivo de reglas.