Você implantou uma ferramenta de Breach and Attack Simulation – BAS para rodar simulações e ter relatórios das falhas nos controles de segurança. A equipe de segurança acompanha os dashboards. E, ainda assim, os incidentes continuam acontecendo, às vezes exatamente nos vetores que a ferramenta já havia sinalizado.
Esse é um limite que muitas empresas que fazem BAS encontram: a ferramenta funciona, mas a postura de defesa não tem uma melhora incremental na velocidade esperada.
Como destaca o CTEM.org, o BAS é “uma das formas mais escaláveis de produzir evidência contínua e repetível de que os controles de segurança se comportam como esperado”. Mas essa evidência precisa entrar em um ciclo que a transforme em ação. É essa ação que geralmente não acontece de maneira adequada.
A razão é mais estrutural do que técnica, pois o BAS é um mecanismo de validação, não de mobilização.
Nós temos conseguido resultados muito melhores quando realizamos o BAS dentro de um programa CTEM — Continuous Threat Exposure Management.
Neste artigo explicamos por que e como a integração BAS-CTEM muda o resultado.
O que o BAS entrega bem
O Breach and Attack Simulation automatiza a execução de técnicas adversariais em um ambiente real, com o objetivo de verificar se os controles de segurança — EDR, SIEM, firewall, SOAR, controles de e-mail — detectam, bloqueiam ou respondem como esperado.
Na prática, uma plataforma de BAS executa TTPs (táticas, técnicas e procedimentos) mapeadas no MITRE ATT&CK, simula movimentos laterais, exfiltração de dados e escalonamento de privilégios, e retorna evidências mensuráveis, como “esse controle bloqueou”, “esse não detectou”, “essa cadeia de ataque chegou até aqui”.
O que o BAS entrega bem:
- Verificação contínua da eficácia dos controles
- Identificação de lacunas de detecção (telemetria ausente, regras mal configuradas…)
- Evidência técnica auditável, repetível, sem depender de janela de pentest anual
- Testes orientados a TTPs de ameaças reais e relevantes ao setor.
O que o BAS não foi projetado para fazer sozinho
- Definir o que proteger primeiro com base em risco de negócio
- Descobrir a superfície de ataque da organização
- Priorizar a remediação considerando a criticidade de ativo, probabilidade de exploração e impacto operacional
- Garantir que os achados se transformem em correção atribuída, rastreada e verificada.
É normalmente nessas respostas que a ferramenta BAS não entrega que estão o problema. Vejamos os efeitos abaixo:
Gap de remediação
O BAS pode sinalizar um controle falho de EDR hoje. Se não houver um processo formal de priorização de patches, atribuição e SLA de remediação, essa descoberta vai engrossar o backlog, e provavelmente ainda estará lá quando o próximo ciclo de simulação rodar.
Descobertas se tornam ruído
O BAS, quando opera sem integração a um processo de priorização por risco de negócio, contribui para um problema que já assola os programas de segurança: sobrecarga de alertas.
O efeito prático: analistas passam a tratar achados de BAS como mais um item na fila. Sem contexto de negócio — “esse controle falhou em uma cadeia que pode chegar ao sistema de faturamento” —, a urgência se dissolve.
Dados do Ponemon-Sullivan Report mostram que 26% das organizações citam a priorização de risco pouco clara como o maior obstáculo para remediar exposições.
Escopo do BAS é parcial por definição
Ferramentas de BAS simulam ataques em condições controladas. Cada execução cobre um subconjunto do ambiente, com técnicas pré-carregadas. O BAS responde bem a “esse controle funciona contra esse TTP?”, mas isso não necessariamente responde se o caminho de ataque ameaça mais ativo mais crítico agora?.
Essa correlação é talvez o ponto mais negligenciado. Porque a organização pode rodar centenas de simulações por mês e nunca chegar a testar um caminho de ataque que pode ser bem-sucedido, simplesmente porque ele não estava no escopo padrão da ferramenta.
Segundo a XM Cyber, ferramentas tradicionais de BAS frequentemente:
- Focam em vulnerabilidades individuais, sem simular cadeias de ataque complexas
- Oferecem visão estática da postura de segurança, sem monitoramento contínuo adaptativo
- Apresentam limitações de integração com ambientes cloud
- Dependem de cenários predefinidos que podem não refletir as TTPs mais recentes.
O BAS dentro do CTEM
Diferentemente do BAS, que é uma ferramenta, o CTEM é definido pelo Gartner como um programa operacional contínuo que opera em cinco fases interdependentes. Para ver uma descrição detalhada das etapas, acesse este artigo. Em resumo, temos:
- Scoping — Definir o que importa para o negócio
- Discovery — Mapear a superfície de ataque real
- Prioritization — Focar no que tem impacto real
- Validation — Onde o BAS entra como protagonista
- Mobilization — Garantir que a correção aconteça.
Vamos analisar ponto a ponto os benefícios de incluir o BAS dentro de um programa CTEM.
O BAS passa a testar o que foi priorizado, não o que é conveniente testar
Dentro do CTEM, os cenários de BAS são escolhidos a partir das exposições priorizadas nas fases anteriores. Se a fase de priorização identificou que o caminho crítico passa por credenciais de serviço em ambiente Azure com acesso a dados PCI, os cenários de BAS são ancorados exatamente ali, não em um catálogo genérico de simulações.
O CTEM.org propõe uma classificação prática de cenários:
- Tier 1 (sempre ativo): conjunto reduzido de testes de alto sinal conectados a ativos críticos e controles essenciais. Roda com frequência, gera baseline.
- Tier 2 (acionado por mudança): acionado quando há atualização de política de EDR, mudança de identidade, novo deployment em cloud.
- Tier 3 (campanha): pacotes de cenários mais profundos ligados a ameaças emergentes, inteligência de ameaças recente ou iniciativas de negócio específicas.
As descobertas têm destino certo: remediação rastreável
No modelo CTEM, um achado de BAS não termina em um relatório. Ele entra em um backlog priorizado com contexto de risco, responsável designado e SLA. O reteste fecha o ciclo e fornece a métrica que importa: a exposição foi realmente corrigida?
As métricas recomendadas pelo CTEM.org para esse ciclo incluem:
| Métrica | O que mede |
| Validated exposure burn-down | Exposições priorizadas que saíram de “assumido” para “comprovadamente corrigido” |
| Control effectiveness drift rate | Com que frequência controles críticos regridem após mudanças |
| Mean Time to Validate (MTTV) | Tempo entre identificar uma exposição prioritária e ter evidência empírica de sua explorabilidade |
| MTTR-V | Tempo entre validação de falha e correção verificada |
| Coverage of critical attack paths | Percentual de caminhos para ativos críticos com evidência de validação recente |
O contexto de negócio transforma a linguagem do BAS
Um CISO não consegue justificar investimentos quando diz que 53% das simulações falharam no controle X, ele consegue quando afirma que a equipe identificou um caminho de ataque validado do vetor de phishing até o ambiente de dados de clientes, com impacto estimado em caso de exploração que inclui notificação regulatória e potencial de R$ Y em multa da LGPD.
O CTEM fornece o contexto de negócio que transforma o output técnico do BAS em linguagem executiva acionável.
Exemplo prático: como o mesmo achado tem destinos diferentes no CTEM e no BAS
Cenário 1 – BAS isolado
Uma simulação identifica que o controle de EDR não detecta técnica de process injection (T1055 do MITRE ATT&CK) em 3 endpoints do setor financeiro. O relatório é gerado. O analista abre um ticket. O ticket entra na fila junto com 47 outros. Três meses depois, o BAS roda novamente. A mesma técnica ainda não é detectada.
Cenário 2 – BAS dentro do CTEM
A fase de priorização do CTEM identificou que esses 3 endpoints têm acesso direto ao sistema de aprovação de pagamentos — uma joia da coroa. O BAS é acionado com cenário Tier 1 para validar exatamente esse caminho. A falha de detecção é validada com evidência técnica. A exposição entra no backlog com contexto: processo de injeção não detectado em endpoints com acesso ao sistema de pagamentos — risco de impacto financeiro direto. Responsável designado. SLA de 15 dias. Reteste agendado. Em 3 semanas, o controle está ajustado e o reteste confirma a detecção.
Mesmo achado técnico. Destinos completamente diferentes.
Sem CTEM, o BAS testa o que está no catálogo padrão da ferramenta, gera relatórios técnicos, alimenta backlog sem priorização clara e raramente fecha o ciclo com reteste verificado. Dentro CTEM, o BAS vai testar cenários derivados das exposições priorizadas por risco de negócio.
Ter uma ferramenta de BAS é suficiente para implementar CTEM?
Não. Como vimos, o CTEM envolve outras etapas. Ele requer scoping orientado a negócio, descoberta contínua de superfície de ataque, priorização com contexto de impacto real, validação da exposição e um processo formal de mobilização.
O BAS é um dos mecanismos da fase de validação; não é o programa completo.
Mas é possível começar o CTEM tendo apenas uma ferramenta de BAS como ponto de entrada.
Usando os dados históricos de BAS, você pode identificar padrões de falha e os ativos mais expostos. Esses dados pode informar a fase de scoping e priorização inicial do CTEM.
BAS é combustível, CTEM é o motor
O erro mais comum do BAS não está na ferramenta. Novamente, está no processo, que não foi desenhado para transformar evidência em ação.
As ferramentas BAS entregam o que prometem: validação contínua, técnica, repetível da eficácia dos controles.
Mas validação sem priorização baseada em risco real, sem atribuição clara e sem mobilização estruturada não reduz a postura de exposição da organização.
O Gartner projetou uma redução de dois terços no exposição para organizações que estruturam seus investimentos em segurança com base em CTEM. Essa projeção não está atrelada à compra de uma ferramenta específica. Está atrelada à existência de um programa que conecta cada achado técnico a uma decisão de negócio e a uma ação verificável.
Você quer ver uma jornada para o CTEM? Acesse este guia que construímos.
