Migra las 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.

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 UDM, puedes explorar los siguientes campos para comprender qué 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 alertas que se activaron, pero no abarca el caso de las 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 migrar las alertas del antivirus de Windows Defender que antes se mostraban en Enterprise Insights como alertas de CBN.

  1. Encuentra una alerta de ejemplo con cualquiera de los enfoques explicados anteriormente.

  2. 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"

  3. 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 Corelight CBN usa el campo notice y alerta condicionalmente 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.