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

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

Migrar 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.

Com a opção de pesquisa UDM, é possível visualizar 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

Faça o download de alertas padrão do CBN usando a API Tools e revise manualmente

A abordagem anterior ajuda 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.

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

Migre os alertas do antivírus do Windows Defender que apareciam no Enterprise Insights como alertas 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 do Corelight CBN usa o campo notice e envia alertas condicionalmente apenas se for "true":

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

Como esse valor não é normalizado no UDM por padrão, use um analisador extensão Grok da seguinte forma 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"
                }
            }
        }
    }
}

Você pode usar isso em uma regra de mecanismo de detecção de YARA-L, como mostrado a seguir, e com 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"
    )

É preciso ativar e ativar as regras criadas para alertas. Para mais informações, consulte Executar dados ativos da regra.