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

Este documento fornece detalhes sobre como migrar alertas de normalização baseada em configuração (CBN, na sigla em inglês) para alertas de detecção do 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 Alerts and IOCs.

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

Para migrar os alertas de CBN, você pode garantir que os alertas de CBN 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"

Com os resultados da pesquisa da UDM, é possível analisar 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 de alertas padrão de CBN usando a API Tools e revisar manualmente

A abordagem anterior ajuda a encontrar alertas que foram acionados, mas não abrange o cenário de alertas que você não 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 todos e revisar manualmente a lógica do analisador aplicada para encontrar alertas com base em is_alert ou alert_state.

É possível transferir os alertas do CBN para os alertas de regras do mecanismo de detecção YARA-L que você usa ativamente.

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

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

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

  2. Usando o visualizador de eventos de registro bruto / UDM, copie os campos selecionados da UDM 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 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
}

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

Usando a opção de extensões do analisador, é possível resolver rapidamente esse cenário.

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, use uma extensão de analisador Grok da seguinte maneira para adicionar esse valor como um campo 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, use isso em uma regra do mecanismo de detecção YARA-L da seguinte maneira e usando a função do 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 receber alertas. Para mais informações, consulte Executar dados de regras em tempo real.