Purple team melhora detecções porque elimina o intervalo entre o ataque simulado e o feedback ao defensor: red team e blue team executam e observam ao mesmo tempo, na mesma sessão de trabalho. Em vez de receber um relatório semanas depois de um teste cego, o time de defesa acompanha cada técnica enquanto ela roda, ajusta a regra na hora e pede a reexecução para confirmar que a detecção dispara de fato. O método tem lastro institucional: num trabalho conjunto divulgado em outubro de 2023, as agências de segurança estadunidenses identificaram as 10 configurações erradas mais comuns em redes corporativas a partir de avaliações conjuntas de red team e blue team, e o monitoramento interno insuficiente aparece entre os achados recorrentes. Este guia mostra como estruturar esse ciclo dentro do SOC, da escolha das técnicas até a regra validada rodando em produção.
Por que purple team funciona
A diferença entre purple team e um pentest tradicional não é a agressividade do ataque, é o modelo de conhecimento compartilhado. No exercício de purple team, a atividade ofensiva é exposta e explicada enquanto acontece: o red team informa o host de origem, o alvo, o horário exato e os indicadores gerados; o blue team responde mostrando o alerta, a busca ou a lacuna. Cada TTP (tática, técnica e procedimento) recebe, portanto, uma resposta imediata e verificável, e não uma nota subjetiva ao fim do engagement.
O segundo motivo é a natureza do objeto testado. Uma vulnerabilidade se remedia com patch e se fecha; um comportamento de adversário não. Ele muda de ferramenta, de contexto e de conta, e a resposta defensiva precisa evoluir junto. É por isso que o exercício foca em TTPs mapeadas ao MITRE ATT&CK e em cadeias de ataque realistas, escolhidas a partir de inteligência de ameaças sobre agentes que efetivamente miram a organização. Se o seu SOC já passou por casos de movimento lateral com detecção de pass-the-hash ou por bypass de MFA no estilo do ransomware Gunra, esses são candidatos naturais ao primeiro exercício.
O ciclo do exercício na prática
Um exercício produtivo segue uma sequência disciplinada, consolidada em frameworks abertos como o Purple Team Exercise Framework (PTEF):
- Seleção de adversário e TTPs: o analista de CTI apresenta o agente de ameaça, seus alvos históricos e os comportamentos documentados, mapeados por técnica no ATT&CK.
- Mesa redonda de expectativas: antes de qualquer execução, cada área declara o que espera ver: SOC indica logs e alertas esperados, hunt indica casos de busca, DFIR indica métodos de identificação forense.
- Baseline de cobertura: o time azul registra, para cada técnica no escopo, se existe regra, em qual plataforma (SIEM, EDR, NDR, cloud) e quando foi validada pela última vez. Essa foto inicial é o que permitirá medir ganho no fim.
- Execução assistida: o red team executa a técnica compartilhando tela, IP de origem, alvo e timestamp; o blue team segue o processo padrão de investigação.
- Registro de resultado: para cada TTP documenta-se se houve bloqueio, alerta, apenas log ou nenhuma visibilidade, com tempo decorrido.
- Ajuste e reexecução: quando um ajuste curto aumenta a visibilidade, ele é aplicado na sessão e a técnica é executada de novo, com o resultado novo documentado.
O passo 6 é o que separa purple team de um workshop: a repetição controlada no mesmo dia transforma observação em melhoria medida. Sem reexecução, o exercício produz constatações; com reexecução, produz evidência de que a mudança funciona.
Da lacuna à regra de detecção
No PTEF, a engenharia de detecção é tratada como saída crítica do exercício, responsável por traduzir lacunas identificadas em capacidades de detecção de produção. Na prática, cada lacuna levantada na sessão vira um item de trabalho com dono e ciclo definido: documentar a técnica e a telemetria disponível, desenhar a regra com sua lógica e fontes de dados, validar contra a execução registrada da TTP, ajustar limiares contra a atividade benigna do ambiente, publicar via pipeline e inscrever a técnica na suíte de regressão para que a detecção não se degrade em silêncio. Regras tratadas como software, com versionamento em repositório e revisão por pares, sobrevivem a trocas de plataforma e turnos.
A classificação da lacuna define o dono do conserto, e misturar categorias é o erro mais comum do fechamento:
| Resultado observado | Classificação da lacuna | Ação e dono |
|---|---|---|
| Técnica executada sem log relevante | Lacuna de visibilidade (telemetria) | Habilitar fonte de dados no EDR/SIEM — dono: engenharia de plataformas |
| Log existe, nenhum alerta | Lacuna de detecção | Autorar regra e validar contra reexecução — dono: engenharia de detecção |
| Alerta dispara, analista não sabe agir | Lacuna de processo | Criar ou revisar playbook de triagem — dono: gestão do SOC |
| Alerta dispara com alto falso positivo | Lacuna de afinação | Ajustar lógica e limiares com baseline — dono: engenharia de detecção |
| Detecção válida, resposta lenta | Lacuna de resposta | Automatizar ação contenção com revisão humana — dono: engenharia SOAR |
Métricas que provam melhoria
Pass/fail binário esconde o progresso. O padrão mais útil é pontuar cada técnica em escala gradual, do zero (sem visibilidade) até detecção afinada com resposta automatizada, e comparar com o baseline do início do exercício. Três métricas sustentam a conversa com a liderança: cobertura de técnicas validadas antes e depois, tempo entre execução e primeira detecção dentro do exercício e proporção de lacunas fechadas por ciclo. Evite promissoras genéricas: o que convence é a tendência por técnica ao longo dos exercícios, porque uma regra que funcionou no dia 1 e falhou no mês seguinte indica deriva de detecção, não sucesso do programa. Manter TTPs num conjunto de teste automatizado, executado periodicamente, transforma essa checagem em rotina barata em vez de projeto trimestral.
Governança e continuidade do programa
Programas maduros operacionalizam o purple team: em vez de eventos isolados, equipes de CTI, red e blue trabalham como time virtual contínuo, disparando execuções quando um novo comportamento de adversário é documentado. Para setores regulados, o método já tem endereço: na orientação TIBER-EU do Banco Central Europeu para testes liderados por ameaças no setor financeiro, no encerramento do teste, o exercício de purple team é elemento fixo do processo, dedicado a aspectos selecionados que não foram investigados em outras etapas, com escopo, objetivos e regras de engajamento definidos em conjunto pelos times vermelho e azul. O detalhe importa: a colaboração não substitui a fase ofensiva confidencial, ela a complementa para maximizar aprendizado.
Para o SOC que começa agora, a recomendação é enxuta: um exercício por mês, três a cinco técnicas por sessão, lacunas classificadas na tabela acima e revisão do backlog na passagem de turno. Consistência mensal com fechamento real de lacunas supera qualquer exercício anual ambicioso cujos achados morrem num PDF.
