Breach and Attack Simulation (BAS) Contínuo

Nota da pasta 03 - Validação Contínua de Controles, no Capítulo 19 (Purple Teaming Contínuo).
Trata do BAS como programa contínuo de simulação de violação, com agendamento por prioridade de adversário, integração com telemetria de detecção e alerta de regressão quando uma detecção quebra.
Dialoga com as notas de emulação da pasta 02, com o SIM.1 e o SIM.5 do Capítulo 15 e com o painel de cobertura desta mesma pasta.

1. Contexto e Posicionamento na Biblioteca

Breach and Attack Simulation (BAS) é a disciplina de simular, de forma sistemática e repetível, os comportamentos de um adversário contra os próprios controles, medindo se a prevenção e a detecção respondem como prometido. O mercado consolidou primeiro o BAS pontual, com plataformas comerciais que rodam campanhas trimestrais e emitem relatórios executivos, e o BAS contínuo é a evolução natural: as simulações passam a rodar em agendamento permanente, os resultados entram em pipeline de dados e as detecções passam a ser monitoradas como qualquer outro serviço com SLA. Esta nota define a transição e desenho do programa.

A nota se posiciona como o método da pasta 03: as ferramentas da pasta 02 executam, esta nota define quando, com que prioridade e com que régua. O controle SIM.1 do Capítulo 15 descreve a plataforma gerenciada e o SIM.5 descreve a medição de cobertura; aqui o foco é o ciclo operacional que faz a validação acontecer toda semana, sem depender de projeto especial ou disponibilidade de equipe. A diferença entre BAS e emulação ad hoc é a mesma diferença entre monitorar e fazer um snapshot: apenas a primeira produz tendência.

2. BAS Pontual versus BAS Contínuo

A distinção entre as duas modalidades não está nas técnicas executadas, e sim no regime de operação. O BAS pontual responde a um evento, a contratação de plataforma, a auditoria, o lançamento de nova detecção, e produz uma fotografia com data. O BAS contínuo responde a uma pergunta permanente, os controles estão funcionando agora, e produz uma série temporal capaz de revelar regressões e progressos. A tabela compara os dois regimes nos aspectos que importam para o programa.

O argumento econômico do regime contínuo é direto. Uma detecção que quebra na semana 12 e só será reavaliada na campanha da semana 26 passou 14 semanas sem defesa em uma técnica que a organização acreditava coberta. Com rodada semanal, a mesma quebra é detectada na semana 13, e a janela de exposição cai de meses para dias. Esse raciocínio, aplicado a todo o parque de detecções, é o que justifica o investimento em automação da validação.

3. Agendamento por Prioridade de Adversário

Um programa contínuo real não pode testar tudo toda semana, e a priorização por adversário resolve o dilema. A lista de atores prioritários, derivada dos requisitos de inteligência da organização, define conjuntos de simulação: cada ator priorizado tem suas TTPs traduzidas em testes, e o calendário de rodadas cobre os atores em frequência proporcional ao risco. Atores com motivação direta contra o setor, como crime financeiro contra bancos ou espionagem contra infraestrutura crítica, rodam semanalmente; ameaças relevantes, mas secundárias, rodam quinzenal ou mensalmente.

A construção do conjunto de testes por ator segue a mesma disciplina da emulação: a cadeia do ator, extraída de relatórios e do mapeamento ATT&CK, vira uma lista de testes nomeados, versionados e reutilizáveis. Um conjunto de rotina típico para ator de ransomware inclui execução inicial por script, persistência por tarefa agendada, desativação de defesa, dump de credenciais, descoberta de compartimentos e comportamento de impacto em arquivos armadilha. Cada item carrega o identificador ATT&CK, o teste que o executa e a detecção que deveria respondê-lo.

A tradução do ator para o conjunto de testes vale um exemplo concreto, que ilustra a granularidade esperada.

Conjunto de testes do ator: ransomware-operador-financeiro v1.3
Prioridade: 1, cadência semanal
  1. T1204.002   execução inicial por documento com macro        atomic 1.2
  2. T1059.001   script PowerShell de reconhecimento básico      atomic 3.1
  3. T1053.005   persistência por tarefa agendada                caldera ability
  4. T1562.001   tentativa de desativação de agente de EDR       atomic controlado
  5. T1003.001   acesso à memória do LSASS                       caldera ability
  6. T1135       descoberta de compartilhamentos de rede         atomic 2.1
  7. T1486       escrita e renomeação em arquivos armadilha      atomic 1.1
Detecções esperadas: regras ED-104, ED-118, ED-127, ED-131 e ED-140
Ambiente: range mínimo de AD, targets da versão 2025.10

O conjunto versionado é um artefato de programa: aparece no repositório, entra na ata da rodada e muda por pull request quando um relatório de inteligência atualiza a cadeia do ator. A coluna de detecções esperadas é o contrato que a rodada testa, e é contra esse contrato que a regressão é calculada.

A rotação entre conjuntos precisa de regras explícitas, para que o calendário não dependa de memória. Uma política comum e funcional é a seguinte.

• Rodada semanal A: cadeia completa do ator prioritário número 1, em ambiente de laboratório, com todos os passos encadeados.
• Rodada semanal B: subconjunto rotativo de técnicas individuais dos atores 2 e 3, para manter cobertura de régua fina.
• Rodada mensal: conjunto de nuvem e identidade, alinhado às notas da pasta 04 deste capítulo.
• Rodada trimestral: avaliação encadeada mais profunda, com Caldera e canal de C2 realista, conforme a pasta 02.
• Rodada sob demanda: teste imediato de toda detecção nova antes da entrada em produção, ligado ao gate de CI/CD da pasta 04.

Com essas regras, o programa mantém ritmo previsível sem exaurir a equipe, e qualquer técnica nova introduzida por relatório de inteligência entra primeiro na rodada sob demanda e depois no conjunto rotativo do ator correspondente.

4. Integração com a Telemetria de Detecção e Métricas por Teste

O BAS contínuo só vale o que vale o pipeline de resultados. Cada teste executado precisa gerar um registro estruturado com, no mínimo, identificador da rodada, timestamp, técnica ATT&CK, host de teste, status de execução e resultado de detecção. Esse índice de resultados é o coração do programa: a partir dele, o painel de cobertura calcula percentuais, a régua de regressão compara rodadas e os KPIs do programa saem sem trabalho manual. A consulta KQL a seguir exemplifica o cálculo de taxa de detecção por técnica no índice de resultados.

// Taxa de detecção por técnica nas rodadas dos últimos 30 dias
BASResults
| where TimeGenerated > ago(30d)
| summarize Testes = count(), Detectados = countif(Resultado == "detectado"),
    SoTelemetria = countif(Resultado == "so-telemetria"),
    NaoDetectados = countif(Resultado == "nao-detectado")
  by Tecnica
| extend Cobertura = round(100.0 * Detectados / Testes, 1)
| order by Cobertura asc

A métrica por teste distingue três estados, e a disciplina de preenchê-los corretamente é o que dá valor ao índice. Detectado significa alerta com timestamp na janela do teste. Só telemetria significa evento bruto presente sem alerta, e o produto é uma tarefa de engenharia de regra. Não detectado significa ausência até de telemetria, e o produto é uma tarefa de coleta. Registrar tudo como detectado ou não, sem o estado intermediário, destrói a capacidade do programa de direcionar o trabalho certo ao time certo.

O inventário de testes é a outra metade da integração. Cada teste tem dono, ferramenta executora, ambiente alvo e detecções que deveria exercitar, e esse inventário versionado é o que permite afirmar cobertura por teste em vez de cobertura por plataforma. Quando um log source quebra, o dono do teste é acionado, e não se descobre na próxima campanha.

As métricas do programa derivam diretamente do índice, e a tabela fixa as definições canônicas que o painel e os relatórios usam.

As metas são pontos de partida e devem ser recalibradas por maturidade, mas as definições precisam ser fixas, porque a série histórica só vale com régua estável. Cada métrica da tabela tem consulta direta sobre o índice de resultados, sem planilha intermediária, e entra nos relatórios do grupo MET do Capítulo 15.

5. Alerta de Regressão quando a Detecção Quebra

O produto mais valioso do BAS contínuo é o alerta de regressão: um teste que resultava detectado e passa a resultar só telemetria ou não detectado entre rodadas consecutivas. A implementação é uma comparação automática entre a última rodada e a anterior, por técnica e por detecção, com disparo de tarefa para o time de detecção quando o resultado piora. A lógica cabe em uma consulta de diferença, como a que segue.

// Regressão: técnica detectada na rodada anterior e não detectada na atual
let anterior = BASResults
  | where Rodada == "2025-40"
  | summarize ResultAnterior = any(Resultado) by Tecnica;
let atual = BASResults
  | where Rodada == "2025-41"
  | summarize ResultAtual = any(Resultado) by Tecnica;
anterior
| join kind=inner atual on Tecnica
| where ResultAnterior == "detectado" and ResultAtual != "detectado"
| project Tecnica, ResultAnterior, ResultAtual, TicketAberto = "auto"

O alerta de regressão precisa de tratamento operacional sério para não virar ruído. Cada disparo abre tarefa com a evidência dos dois testes, o diff de configuração da janela entre rodadas e o histórico do teste, e a tarefa tem prioridade alta porque uma detecção quebrada é uma promessa falsa ativa. Falsos disparos acontecem por razões banais, agente de telemetria parado, rotação de credenciais de laboratório, janela de ingestão maior que a consulta, e a investigação da regressão deve começar por esses suspects baratos antes de culpar a regra.

A ficha da regressão segue um padrão curto que agiliza a triagem pelo time de detecção.

Ficha de regressão REG-2025-41-07
Técnica: T1003.001, dump de LSASS
Rodada anterior 2025-40: detectado, alerta ED-127 em 2m11s
Rodada atual    2025-41: só telemetria, evento 10 do Sysmon presente
Diff da janela: atualização do agente de coleta na terça, versão 7.2 para 7.3
Primeira hipótese: mudança de esquema de campo no agente 7.3
Responsável: engenharia de detecção, prazo de 7 dias por severidade crítica
Desfecho esperado: reexecução do teste na rodada sob demanda após correção

O diff de configuração é o campo que mais economiza tempo de investigação. Regressões reais de regra acontecem, mas a maioria das quebras vem de mudanças circundantes, atualizações de agente, alterações de GPO, rotação de chaves, e ter o diff na ficha encaminha a investigação para a causa provável já no primeiro minuto.

6. Exemplo de Rotina Semanal de BAS

A rotina semanal concreta é o que diferencia programa de intenção. A tabela a seguir desenha uma semana de referência para um programa maduro, com os papéis e produtos de cada dia.

O bloco a seguir resume a automação que orquestra a semana, em pseudocódigo de agendador, mostrando como as peças se encaixam sem intervenção humana além das decisões.

Agendador do programa BAS contínuo:
  terca 09:00  disparar conjunto do ator 1 via Caldera ou atomic-operator
  terca 12:00  publicar resultados no índice BASResults
  quinta 09:00 disparar subconjunto rotativo e testes de nuvem
  quinta 12:00 publicar resultados e calcular diff de regressão
  sempre       se diff detectar piora, abrir tarefa com evidências
  sexta        relatório semanal com cobertura por tática e gaps abertos

A semana de referência escala bem porque cada papel tem carga estável e cada dia tem produto verificável. Programas que tentam começar com rodada diária costumam colapsar em ruído e fadiga; a cadência semanal com subconjuntos rotativos entrega o mesmo valor com muito menos custo operacional.

7. Erros Comuns e Pontos de Atenção

• Tratar a plataforma de BAS como oráculo e aceitar os percentuais dela sem validar o pipeline de telemetria; cobertura reportada por plataforma mede a execução, e a detecção precisa ser verificada no SIEM da organização.
• Rodar simulações de produção sem janela acordada com o SOC, contaminando a fila de triagem; simulações geram alertas reais e a janela é parte do controle.
• Encher o calendário de testes sem capacidade de consertar gaps, transformando o painel em lista de fracassos; o calendário deve acompanhar a capacidade real de engenharia.
• Registrar apenas dois estados, detectado e não detectado, perdendo o estado intermediário que direciona o trabalho; os três estados são o vocabulário mínimo do programa.
• Deixar o alerta de regressão sem dono e sem prioridade, virando notificação ignorada; regressão é promessa falsa ativa e exige tratamento em dias.
• Medir cobertura em técnicas que nenhum ator prioritário usa e ignorar as que todos usam; a prioridade do adversário define a relevância do teste.

8. Integração com o Restante da Biblioteca

O BAS contínuo consome as ferramentas da pasta 02 como executores e entrega seus resultados para o painel de cobertura em tempo real desta mesma pasta, que consolida testes, detecções e gaps abertos. O gate de detecção em CI/CD da pasta 04 é um caso particular do regime contínuo, em que a rodada sob demanda acontece dentro do pipeline de mudança. As métricas que o programa produz alimentam o SIM.5 e os KPIs do Capítulo 15, e os gaps abertos alimentam o backlog de engenharia de detecção e as hipóteses de hunting do Capítulo 15.

Na ponta de inteligência, o calendário por prioridade de adversário é derivado diretamente dos requisitos de inteligência e do perfil de ameaças produzidos nos capítulos iniciais, fechando o ciclo que começa na estratégia de CTI e termina em detecção verificada. O cyber range da próxima nota é a infraestrutura sobre a qual a rotina semanal roda, e a nota de cobertura define a régua que o programa usa para se medir.