SIM.1 - Simulação com Plataforma de Ataques Gerenciada

Controle SIM.1 do grupo SIM (Simulação de Ataques), derivado do Capítulo 15 do Framework CTH.
Define o uso de uma plataforma BAS (Breach and Attack Simulation) para validar controles de detecção e prevenção de forma contínua, automatizada e reproduzível.
No programa integrado de CTI e Threat Hunting, cumpre o papel de transformar suposições sobre a eficácia defensiva em evidência mensurável, alimentando a fila de melhoria de detecções e a métrica de cobertura consolidada no controle SIM.5.

1. Contexto e Posicionamento no Framework CTH

A simulação com plataforma de ataques gerenciada é a porta de entrada do grupo SIM e estabelece a base
operacional dos demais controles do grupo. O Framework CTH considera a validação de detecção o componente
mais crítico de um programa de threat hunting maduro, porque, sem validação contínua, a equipe opera com
suposições sobre a eficácia das detecções, suposições que costumam se mostrar incorretas no momento do
incidente. Uma plataforma BAS permite exercitar o ciclo completo, da execução da técnica de ataque até a
geração do alerta e a reação da equipe, sempre em ambiente controlado e com resultados documentados.

O controle articula-se com o restante do framework em três direções. Para trás, consome as TTPs
priorizadas pela análise de ameaças (grupo ANA) e a telemetria coletada pelo grupo DAT, porque a simulação
só produz conclusão válida se os dados que deveriam capturar a técnica estão sendo efetivamente ingeridos.
Para frente, entrega resultados que se consolidam na métrica de cobertura de SIM.5 e que geram tarefas
para o pipeline de detecção do controle AUT.3. Para dentro, exige governança de escopo e de risco
alinhada ao nível de maturidade definido no grupo GOV.

2. Conceito de BAS e Diferenças para Pentest e Varredura de Vulnerabilidades

BAS (Breach and Attack Simulation) é a prática de executar, de forma automatizada e recorrente, ações que
imitam técnicas de adversários reais para medir se os controles de segurança detectam ou previnem tais
ações. O objetivo central não é descobrir vulnerabilidades inéditas, mas responder com evidência a uma
pergunta objetiva: se um adversário executasse esta técnica agora, o ambiente reagiria? A resposta é
produzida por técnica, por controle e por data, o que permite construir séries históricas comparáveis.

As três práticas de avaliação mais comuns operam em planos distintos e se complementam. A varredura de
vulnerabilidades inventaria falhas conhecidas em superfícies expostas; o pentest demonstra, em um projeto
pontual conduzido por pessoas, o que um humano criativo alcança; a BAS mede, continuamente e por software,
se as detecções prometidas funcionam. A tabela a seguir organiza as diferenças principais.

A consequência prática dessa distinção é de alocação de esforço. Falhas corrigidas não voltam, mas regras
de detecção degradam silenciosamente a cada atualização de produto, migração de SIEM ou mudança de formato
de log. Somente a prática de simulação contínua percebe essa degradação antes de um adversário real, e é
essa propriedade que justifica o posicionamento da BAS como controle contínuo e não como projeto.

3. Capacidades de uma Plataforma BAS Gerenciada

Uma plataforma BAS gerenciada reúne quatro capacidades que, juntas, viabilizam a validação sistemática
exigida pelo controle. A biblioteca de ataques reúne centenas ou milhares de execuções mapeadas a técnicas
do MITRE ATT&CK, organizadas por tática, plataforma e perfil de ator. A execução segura distribui agentes
para endpoints de teste (Windows e Linux), dispara os payloads com mecanismos que evitam dano real, como
exfiltração simulada para destinos controlados pela própria plataforma, e registra cada passo executado.

O relatório de resultados cruza o que foi executado com o que foi detectado ou prevenido, por técnica e
por controle de segurança, diferenciando detecção de prevenção e medindo o tempo entre execução e alerta.
O planejamento de remediação transforma cada lacuna em item acionável, indicando a técnica afetada, o
controle responsável e a recomendação, seja ajustar regra, seja ampliar coleta de dados, seja revisar
política do EDR. A tabela resume como cada capacidade apoia o framework.

4. Ferramentas Comerciais e Comparativo de Enfoque

O mercado oferece plataformas consolidadas, e a escolha deve partir da cobertura das técnicas prioritárias
para o setor da organização, não do tamanho absoluto da biblioteca. Os nomes mais citados em avaliações de
mercado são SafeBreach, Cymulate, AttackIQ e Pentera, cada um com enfoque predominante distinto, conforme a
tabela a seguir.

Duas observações completam o quadro. Primeiro, a plataforma comercial não elimina os controles seguintes do
grupo SIM: emulação encadeada (SIM.2), exercícios purple team (SIM.3) e testes de IOC e IOA (SIM.4)
permanecem necessários e podem contar com ferramentas abertas como Caldera e Atomic Red Team. Segundo,
qualquer plataforma precisa provar que seus payloads são seguros; piloto em laboratório, com o EDR em modo
de auditoria, é etapa obrigatória antes de produção e antes da assinatura do contrato.

5. Benefícios e Casos de Uso

Os benefícios se concentram em três frentes que se reforçam. A primeira é a medição contínua de controles:
em vez de avaliar a postura uma vez por ano, a organização acompanha a capacidade de detecção a cada ciclo,
com a mesma régua. A segunda é a priorização de investimento: quando a simulação mostra que 60 por cento
das lacunas se concentram em Defense Evasion, a decisão de contratar, ajustar ou descartar ferramenta deixa
de ser opinião e passa a ser decisão sustentada por dados. A terceira é a validação da promessa de
fornecedor: afirmações comerciais de detecção de X por cento das técnicas são substituíveis por um piloto
que executa as técnicas no ambiente real e mede o resultado.

Casos de uso típicos incluem o onboarding de nova fonte de logs, quando se deseja provar que a técnica X
passou a gerar telemetria; a avaliação de troca de EDR, comparando detecção por técnica entre dois
produtos; a preparação para auditoria e certificação, com evidências de teste periódico de detecções; e a
justificativa orçamentária anual, usando a série histórica de cobertura como indicador de maturidade para
a liderança, em conjunto com o relato do grupo MET.

6. Cadência de Execução e Integração com Mudanças no Ambiente

A cadência mínima do controle é mensal, conforme SIM.1.2, evoluindo para execução semanal automatizada no
nível avançado de SIM.1.5. Além da cadência regular, a plataforma deve ser disparada por eventos de
mudança: publicação de nova regra de detecção, atualização do SIEM ou do EDR, alteração de política de
endpoint, migração de nuvem ou onboarding de fonte de dados. Cada mudança relevante é um risco de
degradação silenciosa, e a simulação é o teste de regressão da postura defensiva.

O cenário abaixo ilustra um caso de simulação mensal documentado no padrão recomendado.

# Cenário BAS: cadeia inicial de ransomware orientada a detecção
cenario: ransomware-fase-inicial
objetivo: validar detecção da preparação para criptografia
tecnicas:
  - id: T1059.001
    nome: Command and Scripting Interpreter, PowerShell
    execucao: comando codificado em Base64 iniciado por processo de produtividade
  - id: T1053.005
    nome: Scheduled Task-Job
    execucao: criação de tarefa persistente com utilitário administrativo
  - id: T1486
    nome: Data Encrypted for Impact
    execucao: escrita simulada em partição de teste, sem dado real
janela: 02h00 às 04h00
ambito: hosts de laboratório BAS-LAB-01 a BAS-LAB-05
notificacao: NOC e gestores de plantão informados antes da execução
resultado_desejado: alerta em até 5 minutos por técnica no SIEM e no EDR

Cada execução deve gerar um registro com data, versão do cenário, técnicas executadas, resultados por
técnica e alterações no ambiente desde a última execução. Esse registro é a matéria-prima da série
histórica que o controle SIM.5 consumirá, e sua ausência é o erro mais caro desta fase.

7. Riscos e Cuidados Operacionais

A simulação executa técnicas de adversário e, por isso, exige o mesmo rigor de autorização de um teste de
invasão. O escopo precisa estar aprovado por escrito, com a lista de hosts, as técnicas permitidas e as
janelas de execução, ainda que os payloads sejam benignos. Ativos críticos de produção, ambientes
regulados e sistemas legados sensíveis devem ficar fora do escopo inicial, entrando gradualmente conforme
a confiança na plataforma aumenta.

Três cuidados técnicos merecem destaque. O tráfego de egresso deve apontar para destinos controlados pela
própria organização ou pela plataforma, jamais para infraestrutura externa desconhecida, para não gerar
exposição nem queimar indicadores. Payloads que utilizam ferramentas administrativas legítimas precisam ser
marcados com identificadores de teste para distinguirem-se de atividade real. E o NOC, os plantões e os
gestores de ativos do escopo devem ser notificados antes de cada execução, com um canal de cancelamento
rápido disponível durante toda a janela de teste.

8. Implementação Prática e Salvaguardas por Nível

O Framework CTH define salvaguardas progressivas para este controle, que formam um caminho de adoção
claro. A tabela apresenta cada salvaguarda com sua descrição e a prática de mercado correspondente.

Na prática, a transição entre níveis depende menos da ferramenta e mais do processo de tratamento de
resultados. Uma organização que executa simulações mensais, porém não analisa lacunas nem cria planos de
remediação, está parada no nível básico, independentemente do preço da licença. O critério de progressão
é sempre o fechamento do ciclo: simular, medir, priorizar, corrigir e resimular.

9. Erros Comuns e Pontos de Atenção

Os erros recorrentes na adoção de BAS concentram-se em quatro padrões que vale a pena reconhecer cedo.

• Tratar a plataforma como projeto pontual: executar simulações por três meses e abandonar o programa
  destrói a série histórica, que é o principal ativo do controle; a cadência precisa sobreviver a trocas
  de equipe e a picos operacionais.
• Simular sem comunicar: execução sem notificação gera falso incidente, horas de triagem desperdiçadas e
  perda de confiança no programa; a comunicação prévia é parte do procedimento, não cortesia.
• Aceitar "detectado" sem qualidade: um alerta genérico disparado por outra regra, sem correlação com a
  técnica executada, não é detecção da técnica; o resultado deve registrar regra, horário e origem.
• Ignorar a telemetria ausente: quando nem o evento bruto aparece no SIEM, a lacuna é de coleta (grupo
  DAT) e não de regra; desenhar detecção sobre dado inexistente é trabalho perdido.

Um ponto adicional de atenção é o excesso de confiança gerado por resultados positivos. Cobertura alta em
laboratório não garante detecção em produção, onde existem volumes maiores de ruído, agentes com
exclusões, segmentação de rede e horários de manutenção. Por isso, parte do portfólio de cenários deve
eventualmente migrar para pilotos limitados em produção, com autorização reforçada, antes de a organização
declarar confiança na cobertura.

10. Integração com Outros Controles do Framework CTH

Este controle é o fornecedor primário de evidência para SIM.5, que consolida os resultados em métrica de
cobertura por tática e por técnica, e para MAP.4, que cruza lacunas de detecção com técnicas de atores
prioritários. As lacunas classificadas como de engenharia de regra fluem para o pipeline do controle
AUT.3, onde são versionadas, testadas e publicadas como código; as lacunas de coleta fluem para o grupo
DAT, que ajusta a telemetria de endpoint e de rede; e as lacunas de proteção fluem para o grupo PRT.

Na direção de entrada, o grupo ANA fornece as TTPs de atores prioritários que orientam os cenários de
SIM.1.3, e o grupo HNT consome os resultados para formular hipóteses de hunting sobre técnicas com
detecção fraca ou inexistente. Os exercícios de SIM.3 reutilizam os cenários aqui criados, e o grupo IR
beneficia-se indiretamente, porque detecções testadas reduzem o tempo médio de detecção que a resposta a
incidentes herda. O grupo MET acompanha a evolução da cobertura como indicador de maturidade do programa,
e o GOV usa a série histórica como evidência de diligência em revisões e auditorias.