Migrar alertas de CBN para alertas de YARA-L

Este documento fornece detalhes sobre como migrar alertas de normalização com base em configuração (CBN) para alertas de detecção de YARA-L. Como analista de segurança, com a ajuda deste documento, você pode continuar recebendo notificações de alertas de sistemas de terceiros usando a página Alertas e IOCs.

Migrar alertas de CBN para o mecanismo de detecção de YARA-L

Para migrar alertas de CBN, você pode garantir que os alertas anteriores estejam disponíveis como alertas de regra de detecção usando as opções a seguir.

Usando a opção de pesquisa do UDM, é possível conferir eventos com o alert_state definido nos analisadores:

security_result.alert_state = "ALERTING"

Nos resultados da pesquisa do UDM, você pode explorar os seguintes campos para entender quais fontes estão gerando alertas de CBN no seu ambiente:

  • Metadata > Vendor Name

  • Metadata > Product Name

Fazer o download dos alertas de CBN padrão usando a API Tools e revisar manualmente

A abordagem anterior ajuda a encontrar alertas que foram disparados, mas não abrange o cenário de alertas que você nunca viu antes. É possível usar o método de analisadores backstory.googleapis.com/v1/tools/cbn para fazer o download de CBNs padrão, selecionados ou de todos eles e revisar manualmente a lógica do analisador aplicada para encontrar alertas com base em is_alert ou alert_state.

Você pode transferir alertas de CBN para alertas de regra do mecanismo de detecção de YARA-L que usa ativamente.

Migrar alertas de antivírus do Windows Defender que eram exibidos anteriormente no Enterprise Insights como alertas de CBN

O exemplo a seguir mostra como migrar alertas de antivírus do Windows Defender que eram exibidos anteriormente no Enterprise Insights como alertas de CBN.

  1. Encontre um alerta de exemplo usando uma das abordagens explicadas anteriormente.

  2. Usando o visualizador de eventos de registro bruto / UDM, copie os campos de UDM selecionados que vão fornecer uma detecção confiável. Veja o exemplo a seguir:

    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. Crie uma nova regra do mecanismo de detecção de YARA-L.

    rule windows_defender_av_monitored_events {
    meta:
    author = "Chronicle"
    description = "Migration of CBN alerts to Google SecOps 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
}

O alerta de CBN parece usar um campo que não foi analisado no UDM

Usando a opção de extensões do analisador, você pode resolver esse cenário rapidamente.

Por exemplo, o alerta de CBN do Corelight usa o campo notice e alerta condicionalmente apenas se for verdadeiro:

if [notice] == "true" {
  mutate {
    replace => {
      "is_significant" => "true"
      "is_alert"       => "true"
    }
  }
}

Como esse valor não é normalizado no UDM por padrão, você pode usar uma extensão do analisador Grok da seguinte maneira para adicionar esse valor como um campo de UDM do 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"
                }
            }
        }
    }
}

Em seguida, você pode usar isso em uma regra do mecanismo de detecção de YARA-L da seguinte maneira e usando a função 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"
    )

É necessário ativar as regras criadas para alertas. Para mais informações, consulte Executar dados em tempo real da regra.