Adversary Emulation: por que MITRE ATT&CK virou requisito de board

Em 2018, "MITRE ATT&CK" era jargão de Blue Team avançado. Em 2026, é palavra que aparece em board deck, em apólice de cyber insurance, em pergunta de auditor regulatório, em RFP de empresa enterprise. A pergunta "vocês fazem Adversary Emulation com mapeamento ATT&CK?" virou filtro de qualificação de fornecedor.

Este artigo explica para o decisor por que ATT&CK virou padrão, o que mudar nas próximas propostas, e como diferenciar Adversary Emulation real de "Red Team genérico com label novo".

O que é o MITRE ATT&CK (sem o tutorial técnico)

MITRE ATT&CK é uma base de conhecimento estruturada de táticas, técnicas e procedimentos (TTPs) usados por adversários reais, mantida pelo MITRE Corporation desde 2013. É essencialmente um vocabulário comum para descrever como ataques cibernéticos acontecem na prática.

Estrutura básica:

• 14 Táticas (objetivos do adversário): Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command & Control, Exfiltration, Impact, etc.
• ~200 Técnicas (como o adversário atinge o objetivo): T1078 (Valid Accounts), T1059 (Command and Scripting Interpreter), T1003 (OS Credential Dumping), etc.
• Centenas de Sub-técnicas: variações específicas das técnicas
• ~140 Grupos mapeados: APT29, FIN7, Lazarus, Carbanak, etc., cada um com sua lista preferida de TTPs

Por que isso virou padrão? Porque resolve um problema antigo: comunicar risco cibernético em linguagem comum entre técnico, gestor e regulador.

Adversary Emulation vs Red Team "genérico"

Red Team genérico

O time externo tenta atingir os objetivos contratados usando as técnicas que conhece bem. O relatório descreve a narrativa da operação. As métricas são "atingimos N objetivos em M dias" e talvez "vulnerabilidades exploradas".

Problema: o board e o regulador não conseguem responder "estamos protegidos contra Lazarus, que é o grupo que vem atacando bancos da nossa região?" — porque o relatório não conecta as ações executadas com adversários conhecidos.

Adversary Emulation

O time externo, antes de operar, escolhe um adversário-modelo baseado em Threat Intelligence relevante para a indústria do cliente. Constrói o playbook da operação replicando as TTPs específicas desse adversário (mapeadas em ATT&CK). Executa. O relatório vai além: para cada técnica usada, mostra ID ATT&CK, descrição, e — crucialmente — se o cliente detectou ou não.

Saída: mapa de calor ATT&CK. Verde nas células detectadas, vermelho nas não detectadas. O board olha e entende: "ok, estamos cobrindo Initial Access e Execution, mas estamos cegos em Lateral Movement e Defense Evasion".

Por que ATT&CK virou padrão de fato

1. Reguladores adotaram

• NIST SP 800-53 referencia ATT&CK em diversos controles
• Frameworks de pagamento (PCI DSS) começam a referenciar
• BACEN, ANS e ANPD usam linguagem compatível
• TIBER-EU exige mapeamento ATT&CK explícito

2. Seguradoras de cyber adotaram

Questionários de underwriting de cyber insurance em 2026 perguntam explicitamente "qual sua cobertura ATT&CK?". Resposta "70%+ em táticas críticas" reduz prêmio anual. Resposta "não temos métrica" aumenta.

3. Ferramentas de defesa adotaram

Todo SIEM/XDR moderno (CrowdStrike, Microsoft Defender, Sentinel, Splunk) entrega dashboard de cobertura ATT&CK out of the box. Operacionalmente, o time defensivo já vive em ATT&CK.

4. CTI providers adotaram

Relatórios de inteligência de qualquer fornecedor sério já vêm com TTPs mapeadas. Sem isso, não dá para correlacionar ameaça com cobertura defensiva.

O resultado: se seu Red Team não fala ATT&CK, ele está desconectado do resto do ecossistema.

O que mudar nas suas próximas propostas de Red Team

Adicione estas exigências explícitas:

1. "O escopo deve incluir Adversary Emulation"

Não "Red Team Assessment" genérico. Use o termo. Quem não souber explicar a diferença, está vendendo serviço antigo com nome novo.

2. "Escolher 1-2 grupos adversários relevantes para nossa indústria"

Para banco: FIN7, Carbanak, Lazarus. Para healthcare: Conti, Hive, BlackCat. Para SaaS B2B: APT29, ScatteredSpider. Peça que o fornecedor justifique a escolha com base em CTI da sua indústria.

3. "Mapear cada ação do operador a uma técnica ATT&CK"

Relatório técnico deve ter coluna "ATT&CK ID" em cada item.

4. "Entregar Heat Map ATT&CK ao final"

Imagem clara, cores verde/amarelo/vermelho, por tática. É a "capa do relatório" que o board olha.

5. "Comparar com Heat Map anterior (se aplicável)"

Em segundos e terceiros engagements, o mapa de diferença é a evidência de evolução. Sem isso, o board pergunta "o que mudou desde o ano passado?" e você não responde.

6. "Identificar TTPs detectadas vs não detectadas"

Não basta "TTP X foi executada". Precisa ser "TTP X foi executada e seu SOC detectou em 11 minutos via regra Y" ou "TTP X foi executada e não houve detecção".

Como o board lê o resultado

Apresentação executiva pós Adversary Emulation tem 3 slides que importam:

Slide 1: Heat Map ATT&CK

Imagem com as 14 táticas em colunas, células por técnica, verde/amarelo/vermelho. Anotação: "X% das TTPs do grupo Y foram detectadas pelo nosso programa. No exercício anterior, era Z%."

Slide 2: Tempo de detecção por tática

Tabela: "Initial Access: 8 min (vs 4h no exercício anterior). Lateral Movement: não detectado (vs não detectado anterior). Exfiltration: 23 min (vs não detectado anterior)."

Slide 3: Top 3 gaps com plano de remediação

"Gap 1: Lateral Movement via DCSync. Plano: codificar regra Sigma X no SIEM. Responsável: João. Prazo: 30 dias. Custo estimado: zero (tooling existente)."

Esse formato torna a conversa estratégica. CEO consegue perguntar "estamos cobrindo bem nosso adversário-modelo?" e ouvir resposta numérica e visual.

Mapeamento ATT&CK como métrica anual

Empresas maduras tratam cobertura ATT&CK como métrica de programa, reportada trimestralmente:

• Q1 baseline: 32% de cobertura nas técnicas relevantes para nosso adversário-modelo
• Q2 após pentest dirigido: 41%
• Q3 após Purple Team: 58%
• Q4 após Adversary Emulation completo: 71% (com mapa de remediação detalhado para os 29% restantes)

Essa progressão é o que vai no relatório anual de risco operacional cibernético. É traduzível em redução de risco quantificado para o CFO.

O erro do "ATT&CK no final, não no início"

Muitos fornecedores executam Red Team "tradicional" e, no relatório, retroativamente mapeiam as ações para ATT&CK. Isso parece OK, mas tem um problema: a operação não foi guiada por adversário. Foi guiada pelas competências do operador. O relatório acaba mostrando o que o operador sabe fazer, não o que o adversário relevante faria.

Adversary Emulation real é o oposto: começa pelo adversário-modelo, deriva as TTPs, e obriga o operador a executar essas TTPs específicas, mesmo que não sejam suas favoritas. É menos espontâneo, mais difícil de operar, mais valioso para o cliente.

Pergunte ao fornecedor: "no engagement, o operador pode escolher TTPs fora do playbook do adversário-modelo?". Se a resposta é "sim, sem restrição", você está comprando Red Team tradicional com mapeamento ATT&CK no final. Pode ainda ter valor, mas não é Adversary Emulation.

Conclusão

MITRE ATT&CK virou padrão da indústria não por moda, mas porque resolve o problema de comunicação entre ofensiva, defensiva, gestão e regulador. Em 2026, qualquer Red Team que não fale ATT&CK fluentemente está vendendo passado.

Para sua próxima contratação, exija Adversary Emulation com adversário-modelo, mapeamento ATT&CK por ação, e Heat Map executivo. O custo adicional é zero (fornecedores sérios já operam assim). A diferença em valor estratégico é enorme.

Para entender como apresentar resultados para o board, continue em Como avaliar um relatório de Red Team.