Migre os alertas de CBN para alertas de regras de deteção YARA-L

Este documento fornece detalhes sobre como pode migrar os alertas de normalização baseada na configuração (CBN) para alertas de deteção YARA-L. Como analista de segurança, com a ajuda deste documento, pode continuar a receber notificações de alertas de sistemas de terceiros através da página Alertas e IOCs.

Migre os alertas de CBN para o motor de deteção YARA-L

Para migrar os alertas de CBN, pode garantir que os alertas de CBN anteriores estão disponíveis como alertas de regras de deteção através das seguintes opções.

Com a opção de pesquisa da UDM, pode ver eventos com o alert_state definido nos analisadores:

security_result.alert_state = "ALERTING"

Nos resultados da pesquisa da UDM, pode explorar os seguintes campos para compreender que origens estão a gerar alertas de CBN no seu ambiente:

  • Metadata > Vendor Name

  • Metadata > Product Name

Transfira alertas de CBN predefinidos através da API Tools e reveja-os manualmente

A abordagem anterior ajuda a encontrar alertas que foram acionados, mas não cobre o cenário de alertas que nunca viu antes. Pode usar o método dos analisadores backstory.googleapis.com/v1/tools/cbn para transferir CBNs predefinidos, selecionados ou todos, e rever manualmente a lógica do analisador aplicada para encontrar alertas baseados em is_alert ou alert_state.

Pode transferir alertas de CBN para alertas de regras do motor de deteção YARA-L que usa ativamente.

Migre os alertas do antivírus Windows Defender que eram apresentados anteriormente nas estatísticas empresariais como alertas de CBN

O exemplo seguinte mostra como pode migrar os alertas do antivírus do Windows Defender que eram apresentados anteriormente nas estatísticas empresariais como alertas de CBN.

  1. Encontre um exemplo de alerta através de uma das abordagens explicadas anteriormente.

  2. Com o visualizador de registos não processados / eventos UDM, copie os campos UDM selecionados que vão fornecer uma deteção fiável. Veja o exemplo seguinte.

    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 motor de deteçã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 de CBN parece usar um campo que não foi analisado no UDM

Pode resolver rapidamente este cenário através da opção de extensões do analisador.

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

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

Uma vez que este valor não é normalizado no UDM por predefinição, pode usar uma extensão do analisador Grok da seguinte forma para adicionar esse valor como um campo do 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, pode usar esta opção numa regra do motor de deteção YARA-L da seguinte forma 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"
    )

Tem de ativar as regras criadas para receber alertas. Para mais informações, consulte o artigo Dados em direto da regra de execução.