Red team vs blue team: exercícios de adversarial testing

1. O que são Red Team e Blue Team no contexto de desenvolvimento

No universo de segurança para desenvolvedores, Red Team e Blue Team representam duas perspectivas complementares. O Red Team simula ataques reais contra sistemas, aplicações e infraestrutura, adotando a mentalidade de um adversário determinado. O Blue Team defende esses mesmos ativos, monitorando, detectando e respondendo a incidentes.

Diferente de um pentest tradicional — que geralmente é pontual e focado em encontrar vulnerabilidades específicas — os exercícios contínuos de adversarial testing simulam campanhas completas de ataque, testando não apenas o código, mas também os processos de detecção e resposta. O desenvolvedor, nesse contexto, atua como parte do Purple Team, colaborando ativamente com ambos os lados para traduzir achados técnicos em correções de código e melhorias nos pipelines de CI/CD.

2. Por que desenvolvedores devem se importar com adversarial testing

Para o desenvolvedor, o adversarial testing oferece três benefícios diretos:

  • Identificação de vulnerabilidades antes da produção (shift-left security): ao simular ataques em ambientes de staging ou homologação, falhas como injeção SQL ou XSS são descobertas antes de impactar usuários reais.
  • Ciclo de feedback rápido para correção de código inseguro: cada exercício gera relatórios acionáveis que alimentam diretamente o backlog de segurança do time.
  • Redução de MTTR (Mean Time to Remediate): times que praticam adversarial testing regularmente reduzem o tempo entre a descoberta e a correção de vulnerabilidades, melhorando a cobertura de segurança.

3. Planejamento de um exercício Red Team vs Blue Team

O planejamento começa com a definição do escopo e das regras de engajamento (ROE). Exemplo de ROE para um exercício típico:

text
Escopo: Aplicação web "ecommerce-api" em ambiente de staging
Endpoints permitidos: /api/v1/products, /api/v1/users, /api/v1/orders
Endpoints proibidos: /api/v1/admin (fora do escopo)
Horário: 14h às 18h (janela de ataque)
Restrições: Sem DDoS, sem engenharia social, sem acesso físico
Comunicação: Canal dedicado no Slack para coordenação

Cenários realistas incluem injeção SQL, XSS, escalonamento de privilégio e quebra de autenticação. Ferramentas típicas:

  • Red Team: Metasploit, Burp Suite, BloodHound, Nmap
  • Blue Team: Wazuh (SIEM), Suricata (IDS), Falco (runtime security)

4. Execução do ataque simulado (Red Team)

Fase de reconhecimento

O Red Team começa enumerando endpoints e serviços. Exemplo de saída de enumeração:

text
Endpoint: GET /api/v1/products
Parâmetros: ?category=1&page=1
Resposta: 200 OK (JSON com 10 produtos)

Endpoint: POST /api/v1/users/login
Body: {"email":"test@test.com", "password":"test123"}
Resposta: 401 Unauthorized (mensagem: "Invalid credentials")

Endpoint: GET /api/v1/users/profile
Headers: Authorization: Bearer <token>
Resposta: 200 OK (dados do usuário)

Exploração de vulnerabilidades

Após identificar o endpoint /api/v1/products com parâmetro category suscetível a injeção, o Red Team testa:

text
Payload: ' OR 1=1 --
Request: GET /api/v1/products?category=' OR 1=1 --
Resposta: 200 OK (retorna TODOS os produtos, ignorando o filtro de categoria)

Payload: ' UNION SELECT username, password FROM users --
Request: GET /api/v1/products?category=' UNION SELECT username, password FROM users --
Resposta: 200 OK (dados de usuários expostos no retorno)

Outro cenário comum é o teste de XSS em campos de busca:

text
Payload: <script>alert('XSS')</script>
Request: GET /api/v1/products?search=<script>alert('XSS')</script>
Resposta: 200 OK (payload refletido no HTML sem sanitização)

5. Resposta e defesa (Blue Team)

O Blue Team monitora logs e detecta anomalias. Exemplo de alerta gerado por um SIEM:

text
Alerta: SQL Injection Attempt
Timestamp: 2025-01-15 15:23:45
Origem: 192.168.1.100
Endpoint: /api/v1/products
Parâmetro: category
Payload: ' OR 1=1 --
Ação tomada: Bloqueio automático do IP por 30 minutos
Log correlacionado: 5 tentativas de autenticação falhas nos últimos 10 minutos

Ações de contenção incluem:

  • Bloqueio imediato do IP ofensor no WAF
  • Rotação de chaves de API se houve vazamento
  • Rollback do último deploy se a vulnerabilidade foi introduzida recentemente
  • Isolamento do container afetado para análise forense

6. Purple Team: integrando aprendizado no ciclo de desenvolvimento

Após o exercício, a sessão de debriefing (Purple Team) identifica o que funcionou e o que falhou. Exemplo de pauta:

text
Data: 16/01/2025
Participantes: Red Team (João), Blue Team (Maria), Dev Team (Ana, Pedro)

Achados críticos:
1. SQL Injection em /api/v1/products (CRÍTICO)
   - Causa raiz: Query dinâmica sem prepared statements
   - Correção: Migrar para ORM com parametrização
   - Prazo: 2 dias

2. XSS refletido em /api/v1/search (ALTO)
   - Causa raiz: Ausência de sanitização de saída
   - Correção: Implementar encoding HTML no template
   - Prazo: 1 dia

3. Logs de autenticação não estavam sendo monitorados (MÉDIO)
   - Causa raiz: Falha de configuração no SIEM
   - Correção: Ajustar regra de correlação
   - Prazo: 3 dias

O backlog de segurança é priorizado com base na vulnerability density (número de vulnerabilidades por linha de código) e no impacto potencial. Novos testes automatizados são criados:

text
// Teste automatizado para SQL Injection (SAST)
Regra: Evitar concatenação de strings em queries SQL
Exemplo de falha: "SELECT * FROM products WHERE category = '" + category + "'"
Exemplo de correção: "SELECT * FROM products WHERE category = @category"

// Teste automatizado para XSS (DAST)
Payload: <script>alert(1)</script>
Endpoint: /api/v1/search?search=<script>alert(1)</script>
Resultado esperado: 400 Bad Request ou payload sanitizado

7. Métricas e evolução contínua

Métricas essenciais para acompanhar a evolução:

text
Métrica                    | Antes do exercício | Após 3 exercícios
---------------------------|--------------------|-------------------
MTTR (horas)              | 72                 | 24
Vulnerabilidades críticas | 5                  | 1
Cobertura de cenários (%) | 30                 | 75
Falhas detectadas/sprint  | 2                  | 8
Falhas corrigidas/sprint  | 1                  | 7

Dashboard de resultados:

text
Sprint 1: Detectadas 2, Corrigidas 1, Pendentes 1
Sprint 2: Detectadas 4, Corrigidas 3, Pendentes 2
Sprint 3: Detectadas 6, Corrigidas 5, Pendentes 3
Sprint 4: Detectadas 8, Corrigidas 7, Pendentes 4

8. Próximos passos para o time de desenvolvimento

Para começar com adversarial testing:

  1. Inicie com baixa complexidade: organize um CTF (Capture The Flag) interno focado em vulnerabilidades web comuns.
  2. Defina um calendário: equipes maduras realizam exercícios bimestrais; iniciantes, trimestrais.
  3. Use plataformas especializadas: AttackIQ e Atomic Red Team oferecem cenários pré-configurados para simulação de ataques.

Exemplo de cronograma sugerido:

text
Mês 1: CTF interno (XSS, SQL Injection básico)
Mês 2: Exercício Red Team vs Blue Team (escopo limitado)
Mês 3: Debriefing e correções
Mês 4: Novo exercício com cenários expandidos

O adversarial testing não é um evento único, mas um processo contínuo de aprendizado e melhoria. Cada exercício fortalece tanto o código quanto a capacidade do time de detectar e responder a ameaças reais.

Referências

  • OWASP Testing Guide — Guia completo para testes de segurança em aplicações web, incluindo cenários de adversarial testing.
  • Atomic Red Team — Biblioteca de testes de segurança baseados em MITRE ATT&CK para simulação de ataques.
  • MITRE ATT&CK Framework — Base de conhecimento de táticas e técnicas de adversários usada em exercícios Red Team.
  • AttackIQ Academy — Plataforma de treinamento e simulação de adversarial testing com cenários práticos.
  • Wazuh Documentation — Documentação oficial do SIEM open source usado por Blue Teams para detecção e resposta.