Simulação de Alertas com Inputs Controlados

Nota de fechamento da pasta de Pipeline de Detecção do capítulo 18, sobre Detection Engineering e Automação.
Trata a simulação de alertas com injeção controlada de dados sintéticos, a validação ponta a ponta do circuito de detecção e a escolha entre ambiente isolado e produção controlada.
Dialoga com a pirâmide de testes da pasta de DaC, com o Atomic Red Team e o controle SIM do framework CTH, e fecha o ciclo do DaC com a prova de fogo.

1. Contexto e Posicionamento na Biblioteca

As notas da pasta construíram o pipeline completo: a regra escrita em Sigma, convertida para o dialeto nativo, revisada, testada em lógica e publicada por estágio com verificação pós-deploy. Falta a pergunta que fecha o circuito: quando o comportamento real acontece, o alerta chega? Nenhum teste de lógica responde isso sozinho, porque entre o evento e o alerta existem o agente de coleta, o encoder, o parser, a fila de ingestão, a normalização de campos e o motor de detecção, e qualquer elo falho dessa cadeia produz detecção muda. A simulação com inputs controlados injeta o comportamento na cabeça da cadeia e verifica o alerta no fim, provando o circuito inteiro.

A nota é a contrapartida ofensiva do trabalho de engenharia de detecção e dialoga diretamente com o grupo SIM do framework CTH, dedicado à simulação de ataques, com o BAS, Breach and Attack Simulation, apresentado no capítulo 14 da biblioteca e com as práticas purple team do capítulo 12. A diferença de escopo é importante: o BAS avalia a capacidade de detecção como programa, enquanto esta nota trata da verificação operacional e contínua de detecções específicas dentro do pipeline de engenharia.

2. Por que Simular e o que a Simulação Prova

A simulação existe porque detecção falha em silêncio, e a única prova de que a detecção funciona é a observação do alerta diante de um estímulo conhecido. O valor operacional aparece em quatro situações recorrentes do dia a dia: na aceitação de uma regra nova, comprovando o comportamento prometido no desenho; após mudanças de plataforma, como atualização do agente de coleta ou migração de schema, quando regressões de telemetria passam despercebidas; na verificação periódica do catálogo, quando a simulação programada detecta detecções que pararam de disparar sem aviso; e na medição de cobertura real, substituindo a cobertura declarada pelo heatmap por uma cobertura provada por execução.

O ganho de velocidade é o benefício menos citado e o mais sentido no dia a dia do time de engenharia. A detecção nova validada por simulação entra em produção no mesmo dia, porque o engenheiro não precisa esperar um incidente real ou uma campanha purple team para saber se a regra dispara, e o feedback de minutos substitui o ciclo antigo de semanas entre criar a regra e descobrir se ela funciona. Esse encurtamento de ciclo é o que permite à detecção acompanhar a cadência dos relatos de inteligência sem acumular pendências de validação.

A simulação bem desenhada prova três propriedades distintas, e confundi-las é erro comum. A propriedade de emissão, provando que o endpoint ou a fonte de log emite a telemetria esperada quando o comportamento acontece, o que valida a cadeia de coleta. A propriedade de conversão, provando que a regra compila e casa com a telemetria real no dialeto do ambiente, o que valida a conversão da nota anterior. E a propriedade de alerta, provando que o alerta nasce na plataforma com os metadados esperados e chega à fila de triagem, o que valida o circuito de notificação. Cada propriedade isolada pode estar boa e o circuito ainda falhar, porque a integração entre elas é onde o defeito costuma morar.

3. Fontes de Inputs Controlados

O input controlado é o estímulo que dispara a cadeia, e as fontes dividem-se em três famílias com trade-offs claros. A escolha da família depende do objetivo do teste, da criticidade da detecção e do risco tolerado no ambiente.

• Emulação de técnica real com Atomic Red Team: o framework executa testes que reproduzem técnicas ATT&CK documentadas, como o caso T1059.001 de execução de PowerShell com cradle, e a telemetria resultante é o evento real que o adversário produziria. É a fonte de maior fidelidade, com custo operacional maior, pois exige host de execução e procedimento de contenção.
• Injeção de eventos construídos: geradores escrevem eventos diretamente na fonte de dados, por exemplo logando no canal do Sysmon com dados sintéticos ou publicando documentos no índice do SIEM imitando o schema do agente. É rápida e segura, porém não valida o agente de coleta, pois salta a cabeça da cadeia.
• Ferramentas de BAS e plataformas de emulação: soluções comerciais e open source executam campanhas de simulação programadas e medem a cobertura, agregando a execução e o relatório. Reduz o esforço de manutenção do material de simulação, com custo de licença e menor granularidade de controle.

O Atomic Red Team merece destaque prático porque é aberto, tem testes por técnica com comandos documentados e é amplamente usado como padrão de validação, e sua execução via framework de automação como o Invoke-AtomicRedTeam permite encadear testes em sequência e capturar os eventos produzidos para o corpus de testes. Os casos do projeto Caldera, apresentado no controle SIM.2 da biblioteca, cobrem a mesma necessidade em escala de campanha, com adversários completos em vez de técnicas isoladas.

A regra de composição usada por times maduros é usar injeção de eventos para a massa de testes rápidos da pipeline, reservando a emulação real para as detecções críticas e para a cadência periódica de validação de cobertura, porque a emulação consome ambiente e tempo de preparação e não precisa rodar a cada pull request.

Além do estímulo positivo, a bateria completa inclui estímulos negativos, que comprovam que a detecção não dispara diante de comportamento legítimo semelhante. O teste de certutil, por exemplo, roda junto com uma cópia benigna do comando, com download de arquivo interno pelo canal autorizado, e o veredito exige zero alertas para o estímulo negativo e pelo menos um para o positivo. Esse par positivo e negativo é o que mede a seletividade real da regra em vez da capacidade de disparo isolada, e o corpus de estímulos negativos cresce com os falsos positivos descobertos na triagem, fechando o ciclo de aprendizado entre operação e simulação.

4. Validação Ponta a Ponta e Critérios de Passagem

A validação ponta a ponta segue um protocolo fixo que transforma a simulação em teste reproduzível, e não em demonstração ocasional. O protocolo tem cinco passos: preparar o ambiente e o host alvo com telemetria ativa, injetar o estímulo com identificador único, esperar a janela de propagação, consultar a plataforma pelo alerta associado ao identificador e comparar o resultado com o esperado declarado. O identificador único é o detalhe que torna o teste verificável: o estímulo carrega uma marca, um nome de processo, um argumento ou um valor de campo, que permite buscar na plataforma o rastro exato daquela execução e eliminar confusão com tráfego real.

O exemplo abaixo mostra um protocolo completo de validação de uma detecção de download com certutil, usando emulação com comando controlado e verificação automática por script. O teste injeta o comportamento, espera a propagação e consulta o índice de alertas procurando a regra com a marca do teste.

# 1. injetar o estimulo com marca unica do teste no host de laboratorio
MARK="dac-test-$(date +%s)"
Invoke-AtomicTest T1105 -InputArgs @{"remote_file" = "https://lab.local/$MARK.txt"}

# 2. aguardar a janela de propagacao definida no protocolo (ex.: 5 minutos)
sleep 300

# 3. verificar o alerta na plataforma com a marca do teste
python tools/verify_alert.py \
  --rule-id "9d4a1c2e-3b4f-4a5b-8c6d-7e8f9a0b1c2d" \
  --search "certutil AND $MARK" \
  --window-last 15m \
  --expect 1

# esqueleto do verificador: consulta, compara e devolve veredito
import sys, time
from datetime import datetime, timedelta, timezone

RULE_ID = "9d4a1c2e-3b4f-4a5b-8c6d-7e8f9a0b1c2d"

def fetch_alerts(es, query, window_minutes):
    now = datetime.now(timezone.utc)
    body = {
        "query": {"bool": {"must": [
            {"query_string": {"query": query}},
            {"term": {"rule.id": RULE_ID}},
            {"range": {"@timestamp": {"gte":
              (now - timedelta(minutes=window_minutes)).isoformat()}}}
        ]}}
    }
    return es.search(index=".alerts-security*", body=body)["hits"]["hits"]

def main():
    expected = int(sys.argv[sys.argv.index("--expect") + 1])
    query = sys.argv[sys.argv.index("--search") + 1]
    alerts = fetch_alerts(client(), query, 15)
    verdict = "PASS" if len(alerts) >= expected else "FAIL"
    print(f"veredito={verdict} alertas={len(alerts)} esperado>={expected}")
    sys.exit(0 if verdict == "PASS" else 1)

if __name__ == "__main__":
    main()

Os critérios de passagem precisam declarar mais que o alerta existe: a quantidade mínima de alertas, o horário do alerta dentro da janela do teste, os metadados esperados, como host e usuário do estímulo, e o prazo máximo de latência entre injeção e alerta, que é uma medição de MTTD do circuito. Um alerta que chega duas horas depois da injeção prova detecção e desmente a capacidade operacional, e a latência medida por teste é a métrica que revela esse problema antes de o incidente revelar.

O protocolo completo registra cada execução com contexto suficiente para auditoria: data e hora, versão da regra em teste, versão do agente e do schema no host alvo, identificador da injeção e veredito com as medidas coletadas. Esse registro transforma a simulação em evidência verificável de cobertura, que a medição do controle SIM.5 e as auditorias do programa consultam, e o histórico de vereditos por regra é o dado que sustenta a decisão de confiar ou não em uma detecção para um cenário de ataque específico.

5. Ambiente Isolado contra Produção Controlada

A escolha do ambiente de simulação é um compromisso entre fidelidade e risco, e os dois extremos têm uso legítimo. A tabela abaixo compara as modalidades nos critérios que importam para a decisão.

O laboratório isolado é o padrão para a pipeline de regras novas, porque roda a cada mudança e não pode depender de coordenação com a operação, e a condição de validade é a disciplina de espelhar versões: o build do laboratório que roda versão antiga de agente ou schema valida contra o passado e mente sobre o presente. A produção controlada é o padrão para a validação periódica do catálogo e para as detecções críticas antes do primeiro deploy, com a marcação obrigatória do estímulo e a comunicação prévia à triagem, evitando que o alerta de teste seja tratado como incidente real ou, pior, que incidente real seja descartado como teste.

Uma prática intermediária com boa relação custo e benefício é a instância de pré-produção: um ambiente dedicado dentro da mesma organização e plataforma, alimentado por telemetria espelhada ou por agentes de hosts de teste reais, onde a simulação roda com fidelidade alta sem tocar a fila de triagem de produção. O alerta de teste nasce em pré-produção, é verificado automaticamente e o catálogo vai para produção com a cadeia provada uma camada abaixo do ambiente real.

6. Cadência e Automação da Simulação

A simulação manual envelhece, e o valor da prática aparece quando ela entra em cadência automática. Três cadências cobrem o ciclo: a simulação por pull request, restrita a injeção de eventos no ambiente de teste, rodando a cada mudança de regra; a simulação noturna ou semanal, executando a bateria de testes do catálogo crítico em laboratório com emulação real e publicando o relatório de vereditos; e a simulação trimestral completa, com campanhas de emulação em produção controlada que alimentam a medição de cobertura verificada do controle SIM.5.

A automação gera artefatos que precisam de dono: o relatório de vereditos por regra, com latência medida e metadados conferidos; a fila de falhas, onde cada alerta ausente abre item de investigação com prioridade pela criticidade da regra; e a métrica agregada de taxa de sucesso do catálogo, que é o indicador de saúde do circuito de detecção e alimenta os KPIs do programa. Falha simulada sem item aberto é simulação decorativa, e o elo entre o veredito FAIL e o ticket de correção é o que transforma a bateria de testes em mecanismo de qualidade.

A integração com a esteira descrita na nota de testes da pasta de DaC usa o mesmo repositório de workflow, com o job de simulação separado do job de deploy por gatilho e por ambiente. A injeção de eventos roda no pull request, porque é rápida e segura, e a emulação real roda em cadência programada no laboratório, publicando o relatório como artefato da execução e abrindo issues automáticas para falhas novas. O seletor de falhas novas compara o veredito atual com a execução anterior e só cria ticket quando a regra que passava começa a falhar, evitando que falhas conhecidas e acompanhadas abram itens repetidos toda semana.

7. Erros Comuns e Pontos de Atenção

• Simular só na implantação: a regra validada no deploy e nunca mais testada degrada em silêncio com cada mudança de plataforma, e a cadência periódica é o que mantém a garantia ao longo do tempo, não o teste inaugural.
• Estímulo sem marca identificadora: teste sem identificador único se afoga no tráfego real, e o veredito vira opinião. Toda injeção carrega marca única propagada até o alerta, sem exceção.
• Testar no laboratório com build defasado: validação contra versão antiga de agente ou schema produz veredito verde sobre um mundo que não existe mais, e a comparação de versões entre laboratório e produção faz parte do protocolo.
• Confundir telemetria emitida com alerta gerado: conferir que o evento apareceu no índice não é validar a detecção, é validar a coleta. O veredito precisa consultar o objeto de alerta e seus metadados, não o log bruto.
• Simular técnicas destrutivas em produção: comandos de emulação que alteram sistema, derrubam serviço ou geram tráfego pesado contra terceiros exigem avaliação de risco própria, e a escolha do caso de teste considera o dano colateral tanto quanto a fidelidade.
• Ignorar as falhas recorrentes: o mesmo teste falhando semanalmente por falta de telemetria no host alvo vira ruído ignorado, e a falha crônica de simulação é corrigida na fonte, ajustando o ambiente ou marcando a detecção como sem cobertura provada.
• Simulação sem dono do material: casos de emulação criados por um engenheiro em pasta pessoal somem com a rotatividade, e o material de simulação vive no repositório do catálogo, versionado com o mesmo rigor das regras que valida.

8. Integração com o Restante da Biblioteca

Esta nota fecha o arco do capítulo 18: os testes de lógica da pasta de DaC provam a regra, a conversão e o deploy provam a publicação, e a simulação aqui descrita prova o alerta no fim da cadeia, entregando ao programa a cobertura verificada em vez da declarada. O resultado da simulação alimenta o heatmap de cobertura do controle SIM.5 do framework CTH, e a bateria de testes periódica é a implementação prática do controle SIM.4 sobre teste de detecção de IOCs e IOAs.

No restante da biblioteca, o capítulo 14 sobre BAS apresenta o programa de simulação como disciplina de gestão, com a nota de campanha de BAS mostrando como escalar os testes desta nota para campanhas completas, e os exercícios purple team do controle SIM.3 consomem o mesmo material de emulação em formato de treino. A nota de KPIs de threat hunting do capítulo 11 se beneficia da latência medida por simulação como linha de base de MTTD, e o capítulo 16 de exercícios práticos pode executar o protocolo desta nota como roteiro de exercício integrado entre engenharia de detecção, CTI e resposta.

Um exemplo concreto de encadeamento entre as notas ajuda a fixar o fluxo completo estudado no capítulo. A caça do capítulo 8 encontra padrão de movimento lateral, o DDLC da pasta de DaC transforma a descoberta em desenho, a regra Sigma nasce no repositório da nota de Git, a conversão desta pasta produz a consulta nativa, a pipeline de testes valida a lógica, o deploy com Terraform publica o ambiente e a regra, e a simulação desta nota injeta o comportamento com marca única e confirma o alerta em produção controlada. O percurso de dias que antes era imprevisível fica mensurável em cada elo, e essa medição por elo é exatamente o que as próximas fases de maturidade do programa exigem para melhorar.