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 alertas do CBN, garanta que os alertas anteriores do CBN sejam 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, é possível 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 de alertas padrão de CBN usando a API Tools e revisar manualmente

A abordagem anterior ajuda você a encontrar alertas que foram disparados, mas não abordam um cenário de alertas que você nunca viu antes. Você pode usar o método de analisadores backstory.googleapis.com/v1/tools/cbn para fazer o download padrão, selecionar ou todos os CBNs e revisar manualmente a lógica do analisador aplicada encontrar alertas baseados 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 nos Insights empresariais como alertas de CBN

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

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

  2. Usando o visualizador de eventos de UDM / Registro bruto, 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 de mecanismo de detecção 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
}

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

Usando a opção de extensões do analisador, você pode 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"
    )

É preciso ativar e ativar as regras criadas para alertas. Para mais informações, consulte Executar dados de regras em tempo real.