Elastic Security (DaC, ML, Detection Rules)

Nota da subpasta 02 - Plataformas de Detecção e Resposta, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Elastic Security como plataforma de detecção: repositório público de regras, packages de integração, jobs de machine learning, integrações de threat intelligence e detecção como código.
Dialoga com a nota de DaC do Capítulo 18, com a nota de Wazuh e Splunk da mesma pasta e com o controle AUT.3 de automação de detecção do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

A biblioteca já tratou de detecção como código no Capítulo 18 e de SIEM para hunting no Capítulo 09; esta nota aprofunda o Elastic Security como plataforma em que esse conteúdo se materializa. O produto combina três mundos que costumam exigir ferramentas separadas: motor de regras de detecção com repositório público mantido pela Elastic, machine learning de anomalia integrado ao próprio cluster e integrações de threat intelligence que consomem watchlists e feeds na ingestão. Para o programa de CTI-TH, o resultado é um lugar único para transformar inteligência em regra, regra em alerta e alerta em caso.

A nota segue o movimento do capítulo: primeiro a arquitetura de detecção do produto, depois cada pilar em detalhe, então o fluxo de detecção como código com exemplo completo e, por fim, as limitações honestas que a documentação comercial sublinha com letra pequena. A recomendação de leitura para quem opera outro SIEM é comparar cada seção com a nota de Wazuh e com a de Splunk da mesma pasta, porque os três produtos resolvem o mesmo problema com filosofias diferentes.

2. Arquitetura de Detecção no Elastic Security

A base é o Elasticsearch Cluster com índices de dados ingeridos por Elastic Agent e integrations do Fleet, cada um trazendo pipeline de parse para o formato ECS, o Elastic Common Schema, que é o segredo da reutilização de regras entre fontes. Sobre os índices opera o motor de detecção do Kibana, com regras dos tipos query, threshold, eql sequence, machine learning e new terms, agendadas por janela e intervalo, que geram alerts como documentos consultáveis e podem alimentar casos nativos ou externos. As regras consultam índices por padrão de dados, por exemplo logs-windows.sysmon_operational, e não nomes físicos de índice, o que permite trocar fontes sem reescrever detecções.

O desenho típico de operação separa papéis: o time de plataforma mantém Fleet, integrações e retenção; a engenharia de detecção mantém regras customizadas em repositório; os analistas consomem alerts e casos; e o hunter usa timelines e notas para investigação. A tabela resume os tipos de regra e quando cada um é a escolha certa.

A escolha do tipo de regra é a primeira decisão de engenharia e evita o erro clássico de usar query onde a condição é sequência. Regras de query servem a condições pontuais e a IOC; threshold e new terms cobrem desvio de padrão com custo baixo; EQL sequence modela cadeias com correlação temporal por host; machine learning entra quando o baseline precisa aprender por entidade. Em dúvida, comece por query com campo ECS estável e evolua para sequence quando a cadeia estiver clara na telemetria.

3. Repositório Público de Detection Rules

A Elastic mantém publicamente o repositório detection-rules, que origina as regras pré-construídas distribuídas pelo Kibana e pelo pacote Security detection rules do Fleet. O repositório é a fonte mais útil para a engenharia de detecção por três motivos: as regras chegam com mapeamento ATT&CK, com nota de investigação e com falso positivo conhecido; o histórico de commit documenta quando e por que uma regra mudou; e o formato TOML serve de gabarito para regras próprias. A recomendação operacional é tratar as regras pré-construídas como conteúdo atualizável pelo fornecedor e as regras customizadas como propriedade do time, separadas por tag e por revisão, nunca misturadas.

A atualização do pacote de regras no Fleet segue cadência regular, e o time deve revisar o changelog como revisa uma mudança de assinatura de EDR: regras novas abrem cobertura, regras alteradas podem mudar o volume de alertas. O controle AUT.3 do Capítulo 15 ganha aqui uma rotina concreta: a cada atualização, medir quantas regras novas aplicam-se aos dados que a organização realmente coleta, evitando o fato conhecido de a major parte das regras pré-construídas ficar sem dados por falta de fontes habilitadas.

O repositório também define o padrão de qualidade que o time deve imitar nas regras próprias: metadados de maturidade, nota de investigação com passos de triagem, falso positivo declarado e testes unitários. Adotar o gabarito do repositório para regras internas economiza a discussão de formato e torna a auditoria do Capítulo 18 trivial, porque toda regra carrega os mesmos campos de governança. O time que mantém essa convenção transforma cada pull request em evidência de processo, e não apenas em mudança técnica.

4. Machine Learning e Anomaly Detection

O Elastic Security integra jobs de anomaly detection pré-configurados, como processos raros por usuário, autenticações improváveis e volumes anômalos por host, que aprendem baseline por entidade e pontuam anomalia contínua. A diferença para regras é fundamental: o job não declara o que é mau, ele declara o que é incomum, e por isso é insumo de hunting antes de ser fonte de alerta. O padrão recomendado em maturidade crescente é rodar os jobs, alimentar caças com as anomalias de maior score e, só depois de validar utilidade, promover o job a condição de regra com limiar ajustado.

O modelo mental para não errar é o da pirâmide de dor do Capítulo 04: a anomalia de ML ocupa camadas altas, comportamento e ferramenta, e raramente vale como detector de IOC. As limitações práticas são o custo de nó de ML dedicado, o período mínimo de aprendizado para o baseline fazer sentido e a proibição implícita de ativar dezenas de jobs sem analista para consumir, que produz um mar de anomalias sem dono.

Os jobs pré-construídos cobrem as famílias de anomalia mais usadas em caça, e a seleção inicial deve seguir a telemetria disponível, não o catálogo completo. A tabela organiza as famílias e o uso de caça associado.

5. Threat Intelligence Integrations

A plataforma consome inteligência por três caminhos que se complementam. O upload de arquivos e a API permitem subir watchlists curtas e atualizadas, por exemplo IOC de um relatório do Capítulo 05. As integrações do Fleet trazem conectores mantidos para fontes de intel, incluindo TAXII e plataformas comerciais, que populam índices de threat intelligence dedicados. A regra do tipo threat match cruza esses índices com a telemetria e gera alerta quando indicador e evento colidem, com enriquecimento embutido do contexto da fonte.

O desenho de referência para CTI-TH coloca o índice de intel como zona de passagem, atualizado pelo conector a partir do OpenCTI ou do MISP da nota 03 da pasta 01 deste capítulo, e a regra threat match como consumidora, com limiar de confiança e TLP respeitados na fonte. O ganho sobre o lookup manual é a densidade: o match vira alerta com contexto e o caso abre com a fonte citada.

Na configuração da regra threat match, alguns parâmetros definem a diferença entre sinal e ruído, e o exemplo abstrato a seguir fixa esse conjunto mínimo.

# Parametros essenciais de uma regra threat match (exemplo abstrato)
tipo: threat_match
indice_telemetria: logs-windows.sysmon_operational-*
indice_intel: logs-ti_technical.intel-*
campos_match: destination.ip, source.ip
agenda: a_cada_5_minutos
enriquecimento: contexto da fonte com confianca e TLP
acao: alerta com nota de triagem e abertura de caso

6. Detecção como Código no Elastic

O fluxo de DaC no Elastic se apoia em três instrumentos: o formato TOML do repositório detection-rules como fonte de regras, a API e a CLI de regras para importação e exportação, e provedores de infraestrutura como Terraform que gerenciam regras em estado. A pipeline típica guarda cada regra em arquivo versionado, valida em CI, aplica em ambiente de teste, mede volume e falso positivo e promove para produção com aprovação. O exemplo a seguir mostra uma regra customizada em TOML no formato do repositório.

[metadata]
creation_date = "2025/11/10"
maturity = "development"
min_stack_version = "8.15.0"
updated_date = "2025/11/20"

[rule]
name = "Tarefa agendada criada por processo ofimatico"
rule_id = "b3f1e2a0-6d1c-4b5a-9e2f-7a8b9c0d1e2f"
type = "eql"
index = ["logs-windows.sysmon_operational-*"]
language = "eql"
query = '''
sequence by host.id with maxspan=1m
  [process where event.action == "start"
     and process.parent.name == "WINWORD.EXE"
     and process.name in ("powershell.exe", "cmd.exe")]
  [process where event.action == "start"
     and process.name == "schtasks.exe" and process.args : ("/create")]
'''
severity = "high"
risk_score = 73
from = "now-6m"
interval = "5m"
tags = ["Execution", "Persistence", "PT-2025-21"]
threat = [
  {framework = "MITRE ATT&CK",
   tactic = {id = "TA0002", name = "Execution"},
   technique = [{id = "T1053.005", name = "Scheduled Task"}]}
]
note = """Cadeia emulada pelo plano PT-2025-21. Falso positivo conhecido:
instaladores legítimos que agendam tarefas pós-instalação via Office."""

A promoção da regra para produção pode usar CLI do repositório, importação por API ou resource de regra no provedor Terraform, e a escolha deve ser única e documentada, porque mecanismos duplicados geram drift. A validação em CI inclui sintaxe do TOML, testes unitários do repositório e simulação em dados históricos, tema já tratado na nota de testes automatizados do Capítulo 18.

A pipeline de CI que valida e promove a regra do exemplo segue o desenho abaixo, com o gate de aprovação exigido pelo Capítulo 18.

name: deteccoes
on: [pull_request, push]
jobs:
  validar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validar TOML e testes unitarios
        run: python -m detection_rules dev build --validate-all
      - name: Simular contra dados historicos
        run: python scripts/simular_regra.py --regra regras/ofimatico-schtasks.toml
      - name: Aplicar em ambiente de teste
        run: terraform -chdir=ambientes/teste apply -auto-approve
      - name: Promover para producao
        if: github.ref == 'refs/heads/main'
        run: terraform -chdir=ambientes/prod apply -auto-approve

7. Limitações Honestas da Plataforma

• O custo de ingestão é o principal limitador real: regra boa sobre índice sem dados é regra morta, e o desenho de fontes precede o desenho de detecções.
• Jobs de ML exigem nós dedicados e período de aprendizado, o que em clusters pequenos empurra a função para os prebuilt jobs e limita customização.
• Regras de sequência EQL com maxspan amplos custam caro em índices de alto volume e devem ter janela calibrada com dados reais.
• A plataforma não entrega orquestração de resposta completa nativa, e a automação de contenção dependerá de integração com SOAR externo, tema da nota de Splunk desta pasta.
• Atualizações do pacote de regras podem alterar comportamento de detecções em produção sem revisão, o que exige rotina de changelog no pipeline.
• Casos e workflows nativos são mais simples que plataformas de incidente dedicadas, e equipes grandes acabam integrando o alerta a ferramenta de ticket e SOAR.
• Consultas com campos ausentes por fonte retornam silêncio em vez de erro, mascarando regras mortas; o teste de cobertura por índice faz parte da revisão.
• O modelo de casos nativo não substitui gestão de incidente formal em operações grandes, e a integração precisa ser desenhada desde o início.

8. Erros Comuns e Pontos de Atenção

• Ativar todas as regras pré-construídas de uma vez, gerando avalanche de alertas sem fonte de dados adequada; habilite por cobertura real de índices e meça sinal sobre ruído com a métrica SNR do Capítulo 18.
• Editar regras direto na interface e perder o versionamento, revertendo o DaC a fenômeno de interface; a interface vira leitura e emergência, o repositório é a verdade.
• Usar threat match sem filtrar confiança e TLP da fonte, alertando sobre IOC comunitário de baixa qualidade; aplique a pontuação de qualidade do Capítulo 03 na porta de entrada.
• Tratar anomalia de ML como veredito, em vez de hipótese; a nota de hipóteses do Capítulo 06 define o papel correto.
• Ignorar o ECS e escrever regras sobre campos crus de cada integração, quebrando tudo a cada troca de fonte; o padrão de dados é o contrato.
• Esquecer a revisão de changelog do pacote de regras, ficando meses atrás de correções relevantes do fornecedor.
• Rodar jobs de ML sem painel de consumo por analista, acumulando anomalias sem dono; anomalia sem dono é ruído caro.

9. Integração com o Restante da Biblioteca

O fluxo de DaC descrito é a implementação concreta da nota de Detection as Code com Elastic Security do Capítulo 18, e as métricas de qualidade de detecção da mesma pasta servem de critério de promoção na pipeline. As integrações de threat intelligence consomem o stack da nota 03 da pasta 01 deste capítulo, e a regra threat match executa a caça baseada em IOC do Capítulo 10 de forma contínua. O comparativo com Wazuh e Splunk desta pasta orienta a decisão de plataforma por orçamento e por maturidade, e o controle AUT.3 do Capítulo 15 recebe aqui a rotina de revisão de pacote de regras.

O fechamento é de decisão: o Elastic Security vale mais quando a organização já roda Elastic para logs, porque o custo marginal de detecção é baixo e o repositório público acelera maturidade. Em ambientes heterogêneos, o padrão vencedor é este produto como um dos motores de detecção, com Sigma como formato neutro de origem e conversão automatizada no pipeline, tema da nota de conversão de Sigma do Capítulo 18.

Para times que migram de outro SIEM, a sequência natural é traduzir as regras críticas primeiro, validar com dados duplos por um ciclo completo e só então desligar as regras antigas, usando Sigma como ponte neutra. Essa transição com sobreposição evita o buraco de cobertura que ninguém nota até o incidente, e a métrica de SNR mede a equivalência entre as duas bases durante a sobreposição. Ao fim do ciclo, o inventário de regras com origem, motivo e resultado de cada uma é o ativo que sustenta a auditoria e a evolução da detecção.