Como avaliar um relatório de Red Team: 12 perguntas do decisor

O relatório do Red Team chegou. São 80-150 páginas, design caprichado, palavras importantes. Como você sabe se vale o que custou? Esta é a pergunta que separa CISOs que extraem valor do exercício dos que arquivam o documento como "fizemos Red Team em 2026" e seguem a vida.

As 12 perguntas abaixo são o que uso para auditar qualquer relatório de Red Team, meu ou de fornecedores que indico. Se algumas dessas respostas estão ausentes ou fracas, você tem direito de pedir complemento sem custo adicional.

Nível 1: estrutura e camadas

Pergunta 1: O relatório tem 3 camadas distintas?

Relatório bem feito tem três audiências e três documentos (ou três seções claramente separadas):

• Executive Summary (2-5 páginas): para CEO/board. Linguagem de risco e negócio. Sem jargão técnico. Métricas-chave.
• Management Report (15-30 páginas): para CISO, head de TI, head de risco. Narrativa da operação, métricas detalhadas, mapa ATT&CK, recomendações estratégicas.
• Technical Findings (50-100+ páginas): para time técnico. Cada finding com prova, replay step-by-step, recomendação técnica acionável.

Se você recebeu um único documento "tudo em um", já é red flag. Quem entrega Red Team profissional respeita as audiências.

Pergunta 2: O Executive Summary funciona sozinho?

Pegue só essas 2-5 páginas e leia como se fosse um C-level sem contexto. Você consegue responder:

• O que foi testado? (escopo em uma frase)
• Quem foi simulado? (adversário-modelo)
• O Red Team foi bem sucedido? Em quanto tempo?
• Em que momento o time defensivo detectou (se detectou)?
• Quais são os 3-5 riscos críticos identificados?
• O que precisa ser feito nos próximos 90 dias?

Se o executive summary não responde isso claramente, ele falhou. Peça correção.

Nível 2: rigor técnico

Pergunta 3: Cada ação está mapeada no MITRE ATT&CK?

Para cada técnica usada pelo operador, deve haver:

• ATT&CK ID (ex: T1078.001)
• Nome da técnica
• Sub-técnica se aplicável
• Descrição contextual: "Como o adversário X usa esta técnica"

Sem isso, você não consegue traduzir o relatório para a linguagem do seu programa de detecção. Veja por que isso virou padrão em Adversary Emulation e MITRE ATT&CK.

Pergunta 4: Há Heat Map ATT&CK consolidado?

Idealmente uma imagem clara mostrando as 14 táticas em colunas, células de técnica colorizadas por status de detecção (verde/amarelo/vermelho). É a "capa visual" do relatório. Se não tem, peça.

Pergunta 5: Cada finding técnico tem prova replicável?

Olhe 3-5 findings aleatórios. Para cada um:

• Há screenshot/log mostrando a evidência?
• Os passos descrevem o que foi feito de forma que outro operador poderia replicar?
• Há indicação de horário/timestamp dentro do ambiente?
• O finding está classificado em severidade com justificativa?

Se findings são vagos ("conseguimos acesso à rede interna após explorar vulnerabilidade não especificada"), peça detalhamento. Você pagou por isso.

Pergunta 6: As métricas de detecção/resposta estão lá?

O relatório precisa ter, em algum lugar visível:

• MTTD por tática: Mean Time To Detect, separado por fase da kill chain
• MTTR por incidente: Mean Time To Respond, quando aplicável
• Cobertura ATT&CK: percentual de técnicas testadas que foram detectadas
• Objetivos atingidos vs autorizados
• TTPs evadidas (não detectadas)

Para entender essas métricas em profundidade, leia MTTD e MTTR para o board.

Nível 3: utilidade para remediação

Pergunta 7: Cada finding tem recomendação técnica específica?

"Implementar controle adequado" é recomendação inútil. "Codificar regra Sigma X no SIEM monitorando evento Y" é recomendação acionável. Boa recomendação inclui:

• Comando, código ou config exata onde possível
• Onde aplicar (sistema, console)
• Esforço estimado (horas-pessoa)
• Pré-requisitos
• Validação: como confirmar que ficou efetivo

Pergunta 8: Há recomendações estratégicas além das táticas?

Findings técnicos são óbvios. Bom relatório também identifica padrões: "8 dos 12 findings críticos têm raiz em má configuração de Active Directory. Recomendamos projeto de hardening AD de 6 meses com escopo X."

Padrões viram projetos de programa, não tickets individuais. É onde mora 80% do valor de longo prazo.

Pergunta 9: Há plano de remediação prioritizado?

Bom relatório vem com tabela:

• 30 dias: ações críticas + quick wins
• 60-90 dias: hardening estrutural
• 180 dias: melhorias de processo e treinamento
• 12 meses: investimentos de tooling/arquitetura

Sem isso, você fica com a tarefa de criar essa estrutura, que é trabalho de 40-80h do CISO. Por que pagar Red Team que não entrega isso?

Nível 4: aprendizado e contexto

Pergunta 10: A narrativa da operação está coerente?

Algumas páginas no início do Management Report devem contar a história da operação:

• Como obtivemos Initial Access
• Como mantivemos persistência
• Como escalamos privilégios
• Como nos movemos lateralmente
• Como atingimos o objetivo
• Em que momento fomos detectados (se fomos)

Lida em voz alta, deveria fazer sentido como uma história. Se parece random walk técnico, falhou a narrativa, e o board vai sentir isso.

Pergunta 11: Há comparação com adversários reais conhecidos?

"Esta TTP é a mesma usada pelo grupo X no caso Y de 2024" é a frase que conecta o exercício à realidade. Sem isso, você fica com sensação abstrata. Com isso, vira concreto.

Pergunta 12: Há proposta de próximo ciclo?

Relatório bom termina sugerindo:

• Quando fazer próximo exercício (12-18 meses?)
• Qual deveria ser o foco mudado (adversário novo? cenário novo?)
• O que fazer no meio do caminho (Purple Team em 6 meses?)
• Métricas a acompanhar trimestralmente

Sem isso, o relatório é um ponto isolado. Com isso, vira programa.

Os sinais de relatório ruim

Além das 12 perguntas, alguns red flags imediatos:

• Excesso de jargão sem explicação no Executive Summary. CEO não precisa saber o que é "Kerberoasting". Precisa saber que credenciais administrativas foram extraídas usando técnica conhecida do MITRE ATT&CK.
• Severidade inflada: todos os findings são "Críticos". Isso é cobertura comercial, não rigor.
• Templates óbvios: o relatório parece preenchimento de template com seu nome no lugar de "<client>". Em alguns lugares, talvez tenha esquecido um placeholder.
• Recomendações vagas: "implementar Zero Trust" é meme, não recomendação.
• Falta de versão técnica: só tem Executive Summary e algumas screenshots. Você comprou consultoria, não auditoria fluffy.
• Sem rastreamento ATT&CK: já abordado, mas merece ênfase. Em 2026, é o mínimo.

O processo de aceite

Estabeleça SLA contratual de aceite:

1. Fornecedor entrega versão draft do relatório (15-20 dias após fim da operação)
2. Você tem 10 dias úteis para revisar
3. Você envia lista consolidada de pedidos de correção/complemento
4. Fornecedor responde em 5 dias úteis
5. Aceite formal após segunda iteração
6. Apresentação executiva ao board (se contratada) em até 30 dias

Sem esse processo, você assina aceite no calor da entrega e depois descobre o que falta, tarde demais para negociar.

Pagamento amarrado a aceite

Modelo recomendado de pagamento:

• 30% no início (planejamento)
• 30% no meio (operação)
• 30% na entrega do draft
• 10% após aceite formal do relatório final e executive readout

Os últimos 10% existem para garantir qualidade da entrega final. Sem essa amarração, há incentivo para o fornecedor entregar relatório fraco e seguir para o próximo cliente.

Conclusão

Relatório de Red Team vale o que pagamos quando ele se torna ferramenta de mudança real. As 12 perguntas deste artigo te ajudam a validar isso antes do aceite final. Use-as como checklist em qualquer relatório que receber, meu, do seu fornecedor preferido, ou de qualquer outro.

Se você ainda está na fase de avaliar propostas (antes do engagement), revise nosso guia completo do decisor com 12 perguntas para o fornecedor antes da contratação.