Purple team no SOC é um ciclo colaborativo de validação: o Red Team executa uma técnica autorizada, o Blue Team observa os dados e ambos corrigem a detecção antes de repetir o teste. O resultado esperado é uma evidência reproduzível de que a telemetria chegou, o alerta disparou e o analista tomou a ação prevista. Esse recorte é operacional e diferente de uma notícia sobre vulnerabilidade ou correção de software.
Colaboração com objetivo mensurável
A colaboração não transforma duas equipes em uma terceira equipe permanente. Ela cria uma sessão com hipótese, escopo e resultado observável. Red Team e Blue Team trabalham juntos para ajustar e retestar uma detecção até que ela dispare de forma confiável. A PrimeThreat resume esse movimento como emulação, verificação de telemetry e alerts, ajuste e novo teste. Assim, sucesso não significa “invadir” nem “bloquear tudo”, mas explicar por que um comportamento foi ou não visto.
O vocabulário comum vem do ATT&CK. A MITRE descreve ATT&CK como uma globally-accessible knowledge base de adversary tactics and techniques baseada em observações reais. Na prática, a equipe escolhe uma técnica coerente com o modelo de ameaças e define qual fonte de dados, regra, fila e resposta deveriam aparecer durante o exercício.
Escolha da técnica e do escopo
O primeiro recorte precisa ser pequeno o bastante para produzir um diagnóstico inequívoco. O identificador T1003.001 representa LSASS Memory dumping e pode orientar um teste granular em host monitorado. O exemplo não autoriza execução fora de laboratório: ativos, contas, horário, responsáveis e critério de interrupção devem estar definidos antes do teste.
A linha de base também deve ser honesta. Em análise publicada pela CardinalOps, Enterprise SIEMs tinham detections para 24% das MITRE techniques avaliadas. O número não mede uma empresa específica, mas mostra por que uma matriz preenchida por configuração não substitui validação. Cobertura declarada e cobertura observada são medidas diferentes.
Qualidade dos dados entra no mesmo diagnóstico. A CardinalOps também encontrou 12% de SIEM rules broken por data quality issues, incluindo fontes mal configuradas e campos ausentes. Uma regra pode parecer ativa e nunca disparar. Por isso o exercício registra separadamente coleta, lógica de detecção, roteamento, triagem e resposta.
Loop de validação em seis passos
O procedimento cabe em uma sequência controlada. Os passos Select e Emulate escolhem uma technique relevante ao threat model e a executam de modo controlado em um monitored host. Em seguida, Observe verifica a presença de dados e alertas; Tune corrige a lacuna; Re-test repete exatamente o comportamento; Measure registra o resultado para comparação posterior.
- Selecionar uma técnica relevante e definir o sinal esperado.
- Emular a técnica em ativo autorizado e monitorado.
- Observar coleta, regra, alerta, fila e triagem.
- Corrigir a primeira quebra comprovada da cadeia.
- Repetir o mesmo teste para excluir regressão.
- Registrar evidência, responsável e prazo de nova validação.
Durante Observe, a equipe verifica telemetry, detection rule, alert, SOC queue e analyst triage para cada técnica. Essa separação evita atribuir toda falha à regra SIEM. O problema pode estar na fonte, no parser, na consulta, no encaminhamento ou na execução do runbook.
Hunting e priorização
Threat hunting ajuda a transformar lacunas em hipóteses verificáveis. O SANS apresenta o Hunting Maturity Model como modelo para avaliar a threat hunting capability de uma organização. O uso responsável é diagnóstico: o nível atual orienta a próxima capacidade a desenvolver, sem converter maturidade em um selo abstrato.
A formação oficial oferece outra estrutura útil. O treinamento MITRE divide Threat Hunting em Module 1 Fundamentals, desenvolvimento de Hypotheses, requisitos de dados, lacunas de coleta, analytics e investigação. A sequência reforça que a ferramenta vem depois da hipótese e da disponibilidade de dados.
Não é necessário perseguir toda a matriz. O programa prioriza ATT&CK techniques relevantes ao threat model e às common data sources em vez de buscar 100% de cobertura. Essa decisão deve ser documentada com inteligência de ameaças, exposição dos ativos e impacto operacional, para que a lista possa ser revisada quando o risco mudar.
Ferramentas sem confundir funções
Uma ferramenta de emulação executa comportamento; ela não prova sozinha que o SOC detectou ou respondeu. Atomic Red Team reúne atomic tests indexados por technique ID e pode ser executado com Invoke-AtomicRedTeam PowerShell. Cada teste ainda precisa de autorização, isolamento, limpeza e uma expectativa de telemetria definida antes da execução.
Para cenários encadeados, outra opção é a plataforma da MITRE. MITRE Caldera encadeia abilities em operations com ATT&CK-mapped adversary profiles, agents e plugins. Essa automação aumenta o valor apenas quando cada etapa continua rastreável; um cenário longo sem marcos de observação dificulta localizar a primeira falha.
Métricas e critérios de saída
O exercício termina com medidas comparáveis. MTTD mede o tempo entre technique execution e triaged alert. MTTR mede o intervalo entre detection e containment action. Os dois valores precisam carregar escopo e data, pois uma média sem técnica, ambiente e severidade pode esconder regressões importantes.
Detection coverage acompanha relevant ATT&CK techniques com validated, re-tested detection como trend across exercises. A equipe também registra lacunas encontradas, lacunas corrigidas, responsável e evidência do reteste. Uma técnica só muda para “validada” quando o mesmo comportamento produz novamente o sinal e a ação esperados.
Os achados devem alimentar a engenharia de detecção no SOC e o processo de threat hunting. O ganho do purple team está na cadeia fechada entre teste, evidência, correção e reteste.
