Purple Team : o jeito mais rápido de parar de “achar” e começar a medir
Se você trabalha em SOC, conhece o ciclo: chega alerta, corre atrás de log, falta contexto, regra barulhenta, playbook que ninguém segue, e no fim a sensação de que “a gente detecta… eu acho”.
Purple Team, é a vacina contra esse “eu acho”.
Não é um time novo. Não é um mega projeto. É um processo simples: simular ataques controlados, observar o que o SIEM enxerga, ajustar detecção/resposta e re-testar até ficar bom.
O ciclo do purpleteam
1) Escolha 3 técnicas do MITRE ATT&CK (as mais prováveis no seu ambiente)
2) Execute uma emulação controlada (passo a passo reproduzível)
3) Valide ingestão: o evento chegou no SIEM? chegou certo?
4) Tune detecção: correlação, Sigma, thresholds, supressões
5) Ajuste resposta: triagem, runbook, SOAR (se tiver)
6) Re-teste e registre PASS/FAIL com evidência
O ponto é simples: sem re-test, é só narrativa. Com re-test, vira engenharia.
O “Dia 1” no SIEM: onde geralmente quebra
Antes de falar de regra, eu olho isso aqui:
- Fonte de log habilitada (endpoint/identity/cloud) e com cobertura real
- Parsing/normalização OK (os campos que importam existem e estão preenchidos)
- Latência de ingestão conhecida (e aceitável)
- Retenção e busca funcionando (dá pra investigar depois, não só “ao vivo”)
- Enriquecimento básico (usuário, host, criticidade do ativo, ambiente)
- Dashboard simples de sanity check: “rodei o teste → o evento apareceu?”
Muita detecção “falha” não porque a regra é ruim — mas porque a telemetria chega torta, atrasada ou incompleta.
3 casos de teste que dão retorno rápido no SOC
Sem APT cinematográfico. Começa com o que dá incidente de verdade:
1) Credential Access (controle de credenciais)
O que você valida:
- eventos corretos (identidade/endpoint)
- correlação (usuário + host + comportamento)
- severidade (não explodir em falso positivo)
2) Lateral Movement (movimento lateral)
O que você valida:
- encadeamento host→host e user→host
- visibilidade de autenticações/acessos remotos
- capacidade de “contar a história” com logs
3) Exfiltration (lite)
O que você valida:
- baseline e thresholds (volume, destinos, padrões)
- contexto no alerta (o que saiu, de onde, por quem)
- triagem acionável (não só “tráfego alto”)
Entrega mínima de uma sessão Purple (SOC-ready)
Se não sair isso aqui, tá incompleto:
- Mapa: Técnica → Logs → Regra → Alerta → Ação
- PASS/FAIL por técnica com evidência (eventos/prints/queries)
- Query salva no SIEM (pra repetir e auditar depois)
- Regra/alerta ajustado (e o “por quê” do ajuste)
- Runbook/playbook enxuto (quem faz o quê, em quanto tempo, com quais dados)
- Re-test documentado (antes/depois)
Métricas que importam (e não passam vergonha)
- TTD (tempo pra detectar)
- TTR (tempo pra responder)
- Cobertura por técnica (pass/fail)
- Taxa de falso positivo pós-tuning
- Qualidade do alerta: tem contexto suficiente pra agir sem “caçar log” por 40 minutos?
Armadilhas clássicas (pra evitar dor gratuita)
- “Tem log” ≠ “dá pra investigar” (campo faltando mata a análise)
- Regra boa sem runbook = alerta bonito e incidente vivo
- Ajustar regra e não re-testar = fé, não método
- Transformar Purple em disputa Red vs Blue (não é campeonato)
Se você quer implementar isso sem drama, faz o seguinte: escolhe 1 ambiente, 1 fonte de log principal, 3 técnicas ATT&CK e roda uma sessão curta por semana. Em um mês, o SOC muda de patamar — porque você troca opinião por evidência.
