Continuous Purple Teaming (Validação Contínua com IA)

Nota do Capítulo 17, pasta de Purple Teaming Autônomo com IA.
Define o continuous purple teaming como a prática de validar detecções continuamente, com novas regras testadas automaticamente contra emulações e regressão de cobertura monitorada.
Dialoga com as notas de AutoPT e de Skyhawk Security da mesma pasta e com os controles SIM.3, SIM.5 e AUT.3 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O capítulo 15 descreveu o exercício purple team como um evento: equipes se reúnem, técnicas são executadas, detecções são ajustadas e o ciclo termina com um relatório. Esta nota descreve o passo seguinte dessa evolução, o continuous purple teaming, no qual a validação deixa de ser evento e passa a ser um serviço contínuo da esteira de engenharia de detecção. A mudança é possível porque dois insumos amadureceram: bibliotecas de emulação prontas, como Atomic Red Team, e pipelines de CI que tratam detecções como código. A IA acelera ainda mais o ciclo, gerando variações de emulação e julgando resultados, mas o conceito vale mesmo sem IA, e é essa estrutura que a nota documenta.

Na biblioteca, a nota ocupa a posição de ponte entre a pasta de purple teaming autônomo e os controles SIM e AUT do capítulo 15. O leitor deve entender que continuous purple teaming não é um produto, e sim uma propriedade da esteira de detecção: toda regra nova, toda regra alterada e toda mudança de log source passa por um pipeline que a testa contra emulação antes de chegar em produção e a monitora contra regressão depois. Essa propriedade é o que permite sustentar milhares de regras sem que a cobertura vire uma promessa sem evidência.

A palavra contínuo merece definição operacional para evitar expectativa errada. Contínuo aqui significa que o gatilho de validação é a mudança e não o calendário, e que existe uma rotina periódica de regressão cobrindo o catálogo inteiro. Não significa que toda técnica é testada a cada minuto, e a cadência real depende do custo de execução das emulações e da criticidade das técnicas, como qualquer orçamento de engenharia.

2. Do Exercício Pontual à Validação Contínua

O exercício pontual produz aprendizado intenso, porém raro, e a detecção decai entre eventos por causas previsíveis. Regras são desligadas por falsos positivos durante um incidente e nunca reativadas. Log sources mudam de esquema em atualizações de plataforma e regras silenciosamente param de casar. Times trocam de ferramenta ou de normalização e o dicionário de campos se desloca. Nada disso aparece no relatório do último exercício, porque o relatório fotografa o passado. A validação contínua existe para transformar essas degradações silenciosas em falhas visíveis no pipeline, no momento em que acontecem.

A comparação não elimina o exercício pontual, que continua útil para cenários complexos, multi-etapa e criativos que nenhum catálogo cobre. A proposta é dividir o trabalho: o contínuo cuida da base, garantindo que cada técnica emulável tenha detecção viva, e o pontual explora o topo, testando cadeias e evasões que exigem criatividade humana. Times que tentam manter tudo manual perdem a base; times que dependem só do automatizado não enxergam o adversário que varia além do catálogo.

Uma observação de governança complementa a comparação. No modelo pontual, o conhecimento da cobertura vive nas pessoas que executaram o exercício, e sai da organização quando elas saem. No modelo contínuo, o conhecimento vive no repositório, com cada regra declarando o que cobre e cada execução provando se cobre, o que transforma cobertura em ativo institucional em vez de memória de equipe.

3. Pipeline de Validação de Novas Detecções

O pipeline de validação transforma cada detecção em artefato versionado e cada mudança em gatilho de teste. O fluxo começa quando o engenheiro de detecção abre um pull request com regra nova ou alterada. O CI roda a validação sintática e depois monta um ambiente de teste com as mesmas normalizações de produção, executa a emulação das técnicas que a regra pretende cobrir, ingere a telemetria gerada, avalia se a regra alertou dentro do tempo esperado e publica o resultado como veredito no pull request. O merge é bloqueado quando a regra não alerta para a técnica alvo ou alerta para técnicas fora do escopo, caracterizando falso positivo construtivo.

O desenho do pipeline precisa de quatro acordos de engenharia para funcionar na prática. Primeiro, cada regra declara em metadados quais técnicas ATT&CK pretende cobrir, porque é esse mapeamento que define a emulação a disparar. Segundo, o ambiente de teste precisa refletir os log sources reais, incluindo versões de agente e normalização, senão o veredito não se transfere para produção. Terceiro, emulações que exigem privilégio ou causam impacto devem rodar em hosts efêmeros dedicados, com regras de engajamento automáticas. Quarto, todo veredito fica registrado com as três marcações de tempo que alimentam métricas, execução, ingestão e alerta.

estagios_pipeline_deteccoes:
  - nome: lint_e_metadados
    checa: sintaxe_sigma, mapeamento_attck, owner_e_severidade
  - nome: build_ambiente
    acao: subir_hosts_efemeros_com_agentes_de_producao
  - nome: emulacao
    acao: executar_atomicos_das_tecnicas_declaradas_na_regra
  - nome: ingestao_e_avaliacao
    acao: ingerir_telemetria, avaliar_alerta_e_falsos_positivos
  - nome: veredito
    saida: comentario_no_pull_request_com_evidencia
    bloqueio_merge_se: sem_alerta_na_tecnica_alvo_ou_falso_positivo
  - nome: pos_merge
    acao: agendar_reexecucao_periodica_para_regressao

O pipeline acima é deliberadamente simples nos estágios, e a complexidade real concentra-se em dois pontos: o ambiente efêmero, que precisa subir com agentes e normalização equivalentes à produção em minutos, e a avaliação, que precisa casar a emulação executada com a regra que deveria alertar. Ambos os pontos são problemas de infraestrutura conhecidos, com solução de engenharia, e não obstáculos conceituais.

4. Regressão de Cobertura

Regressão de cobertura é o fenômeno de uma detecção que funcionava e deixa de funcionar sem mudança aparente na regra. As causas são quase sempre externas à regra: log source alterado, campo renomeado na normalização, agente atualizado com nova taxonomia de eventos, ou telemetria desligada por economia de custo de ingestão. O continuous purple teaming trata regressão como defeito de build, com a mesma seriedade de um teste unitário quebrado. A rotina de regressão reexecuta periodicamente o catálogo de emulações contra as regras mapeadas e compara o resultado com a baseline, e qualquer queda de cobertura abre incidente no time de detecção com prazo de correção.

A cobertura deve ser medida e publicada em duas dimensões que os times costumam confundir. A cobertura declarada conta técnicas que têm ao menos uma regra mapeada, e responde se existe algo escrito. A cobertura validada conta técnicas cuja emulação foi executada recentemente e gerou alerta, e responde se o algo escrito realmente funciona hoje. Publicar apenas a declarada é o erro clássico de dashboard de segurança, porque a distância entre as duas é justamente o risco silencioso que este pipeline existe para eliminar. Em heatmaps de cobertura, a coluna validada é a que deve ir para a reunião de liderança.

A tabela abaixo organiza as causas mais frequentes de regressão e o sinal que o pipeline usa para identificá-las. A utilidade prática é separar diagnóstico de regra de diagnóstico de infraestrutura, dois problemas com donos e prazos diferentes.

5. Integração com CI/CD de Detecções

O continuous purple teaming pressupõe detecção como código, com regras em repositório, revisão por pares e esteira de publicação. Nesse mundo, a emulação é apenas mais um estágio da esteira, como lint e teste unitário, e a IA entra como aceleradora em três pontos. Na geração de casos, um LLM expande um atômico do Atomic Red Team em variações que exercitam a regra em limites diferentes, mudando usuário, horário, volume e ofuscação leve. No julgamento de resultado, um modelo avaliador compara a transcrição da emulação com o alerta gerado e sinaliza correspondências parciais que merecem revisão humana. Na triagem de regressão, o modelo agrupa falhas por causa provável, separando problema de regra, de log source e de ambiente, o que encurta o diagnóstico.

O papel da IA aqui é específico e mensurável, e não substitui a estrutura. Sem catálogo de emulações e sem pipeline, a IA gera payloads sem destino e julgamentos sem evidência. Com a estrutura, a IA aumenta a variedade dos testes e reduz o custo de manutenção, que é historicamente o que faz programas assim morrerem. A regra de ouro é que toda saída de IA entra no pipeline como artefato versionado e revisável, nunca como execução ad hoc fora da esteira, porque o valor está na repetibilidade e não no brilho individual de cada caso gerado.

A fronteira de responsabilidade entre IA e pipeline também precisa ser explícita na governança do programa. A IA propõe variações e agrupa falhas, o pipeline executa e mede, e o engenheiro decide, e nenhuma saída de modelo entra em produção sem passar pelo mesmo pull request que qualquer mudança humana. Essa regra simples evita a formação de uma via expressa de mudança sem revisão, que seria ironicamente o tipo de lacuna que o programa existe para eliminar.

6. Exemplo com Atomic Red Team e CI

O exemplo a seguir usa o Atomic Red Team, biblioteca aberta de testes mapeados ao ATT&CK, dentro de um job de CI em runner Windows. O job executa os atômicos declarados, ingere a telemetria no SIEM de teste e compara o alerta esperado. O comando central é simples e roda em qualquer runner com PowerShell.

Import-Module "C:\ART\invoke-atomicredteam\Invoke-AtomicRedTeam.psd1"
$tecnicas = @("T1055.012", "T1547.001", "T1003.001")
foreach ($t in $tecnicas) {
  Invoke-AtomicTest $t -TestNumbers 1 -ExecutionLogPath "C:\ART\logs\$t.json"
}

O job de CI completa o ciclo com a etapa de avaliação, no qual o pipeline ingere o log de execução e a telemetria do host no SIEM de staging, espera a janela de avaliação e consulta as regras mapeadas. O trecho abaixo ilustra a consulta de verificação em KQL sobre a tabela de alertas do ambiente de teste, exigindo que cada técnica tenha gerado alerta na janela da execução.

SecurityAlert
| where Timestamp between (_execucao_inicio .. _execucao_fim)
| where AttackTechniques has_any ("T1055.012", "T1547.001", "T1003.001")
| summarize Alertas = dcount(AlertName) by AttackTechniques
| where Alertas == 0

Quando a consulta retorna linha, o merge é bloqueado e o engenheiro recebe o par de evidências, o log de execução do atômico e a ausência de alerta, com o histórico da regra. Esse formato fecha o ciclo de validação em minutos e torna o custo de manter milhares de regras previsível, porque cada regra carrega seu próprio teste, do mesmo modo que cada função de software carrega o teste unitário que a protege de regressão.

O trecho abaixo mostra o job de CI que orquestra o exemplo, no formato simplificado de um executor de pipeline. O job sobe o runner Windows efêmero, instala o módulo do Atomic Red Team, executa os atômicos declarados no pull request, ingere a telemetria no SIEM de teste e chama a etapa de avaliação com os limiares do projeto.

job_validacao_deteccao:
  gatilho: pull_request
  ambiente: runner_windows_efemero
  passos:
    - instalar_modulo_atomic_red_team
    - executar_atomicos_das_tecnicas_do_pull_request
    - ingerir_telemetria_no_siem_de_teste
    - aguardar_janela_de_avaliacao
    - avaliar_alertas_e_publicar_veredito
  limiares:
    alerta_obrigatorio: tecnica_alvo
    falso_positivo_maximo: fora_do_escopo
  saida: veredito_no_pull_request_com_evidencia

7. Métricas do Programa Contínuo

Duas leituras da tabela evitam distorções de gestão. Tempo de validação abaixo de horas só é sustentável com ambiente efêmero e ingestão dedicada, e insistir nisso com infraestrutura compartilhada de produção gera fila que mata o programa. E a taxa de regressão detectada alta não é vergonha, é sinal de que a rotina funciona; o número a vigiar é o tempo de correção, porque regressão encontrada e não corrigida equivale a cobertura falsa publicada no dashboard.

8. Erros Comuns e Pontos de Atenção

Um cuidado adicional é o ruído de falsos positivos construtivos no início do programa. Quando a esteira começa a bloquear merges porque regras antigas alertam fora do escopo declarado, a fila cresce antes de melhorar, e a liderança precisa saber que isso é a fase de ajuste, com limite esperado de algumas semanas. O antídoto é priorizar o mapeamento e a validação das técnicas mais usadas pelos atores relevantes ao negócio, seguindo a priorização por ameaça que a biblioteca defende no ciclo de CTI, e depois expandir o catálogo com o mesmo padrão.

O critério de escopo inicial também evita o erro de tentar mapear tudo de uma vez. O recorte recomendado é as técnicas mais usadas pelos atores relevantes para o setor da organização, cruzando o heatmap de cobertura com o perfil de ameaças produzido pela equipe de CTI, e crescendo a partir desse núcleo conforme a esteira se estabiliza. Programas que começam tentando validar quinhentas técnicas em paralelo morrem na primeira semana de fila de ambiente.

9. Integração com o Restante da Biblioteca

A nota generaliza a ficha de resultado do controle SIM.3 em artefatos de pipeline, e os seus números alimentam o SIM.5 de medição de cobertura e o heatmap do grupo MAP, agora com a dimensão validada que o heatmap declarado não tem. Com o AUT.3, de automação de detecção, o pipeline desta nota é a etapa de garantia de qualidade que falta a muitas implantações de SOAR, que automatizam resposta sobre regras nunca testadas. No contexto do capítulo 17, o AutoPT é a especialização para LLMs e a Skyhawk Security é a especialização para nuvem, e as três notas compartilham o mesmo esqueleto de catálogo, execução, medição e regressão.

Para o leitor que constrói a esteira completa da biblioteca, a recomendação de sequência é clara. Primeiro colocar detecções em repositório com CI básico de lint, depois mapear técnicas e implantar emulação com Atomic Red Team, depois instrumentar regressão periódica e, por último, introduzir IA na geração e no julgamento. Tentar começar pelo fim, comprando IA antes da estrutura, reproduz o erro clássico de automação sem processo, e a nota de AUT.1 sobre orquestração descreve o mesmo risco em outro domínio.

Ao aplicar essa sequência, o time deve registrar desde o primeiro dia o que fica fora do catálogo de emulações, porque as técnicas não emuláveis, como engenharia social de execução manual ou exploração que exige alvo real, formam a fronteira honesta do programa. Essa fronteira é o que o exercício pontual de purple team deve atacar, e o registro explícito do que cada modelo cobre evita a ilusão de que o dashboard completo significa adversário coberto.