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

Neste documento, explicamos como migrar alertas de normalização com base em configuração (CBN) 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 Alertas e IOCs.

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

Para migrar alertas de CBN, use as opções a seguir e garanta que os alertas anteriores estejam disponíveis como alertas de regra de detecção.

Com a opção de pesquisa da UDM, é possível ver eventos com o alert_state definido nos analisadores:

security_result.alert_state = "ALERTING"

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

  • Metadata > Vendor Name

  • Metadata > Product Name

Baixar alertas padrão da CBN usando a API Tools e revisar manualmente

A abordagem anterior ajuda a encontrar alertas que foram disparados, mas não cobre o cenário de alertas que você nunca viu antes. Você pode usar o método backstory.googleapis.com/v1/tools/cbn parsers para baixar todas as CBNs, as padrão ou as selecionadas e analisar manualmente a lógica do analisador aplicada para encontrar alertas com base em is_alert ou alert_state.

É possível migrar alertas da CBN para alertas de regras do mecanismo de detecção YARA-L que você 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 do antivírus Windows Defender que eram exibidos no Enterprise Insights como alertas da CBN.

  1. Encontre um exemplo de alerta 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. Confira 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 regra de mecanismo de detecção 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 da 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 envia um alerta condicional apenas se for verdadeiro:

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

Como esse valor não é normalizado para 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"
                }
            }
        }
    }
}

Você pode usar isso em uma regra do mecanismo de detecção 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 e ligar as regras criadas para alertas. Para mais informações, consulte Executar dados dinâmicos de regras.