A segurança de Purple Team representa uma evolução na forma como as organizações conduzem testes de segurança e melhoram suas defesas. Em vez de manter as equipes de ataque (Red Team) e defesa (Blue Team) em silos, o Purple Team promove uma colaboração ativa e contínua entre elas, com o objetivo de maximizar a eficácia das detecções e respostas a incidentes. Essa abordagem não é uma nova equipe, mas sim uma cultura e um conjunto de práticas que integram conhecimentos, ferramentas e objetivos.

Nesta aula, vamos nos aprofundar nos três pilares fundamentais do Purple Team: colaboração, ajuste de detecção (detection tuning) e contexto compartilhado. Esses pilares são essenciais para transformar exercícios de segurança em oportunidades de melhoria real e mensurável. Você aprenderá como implementar essas práticas no seu dia a dia, utilizando exemplos práticos e técnicas que podem ser aplicadas em qualquer organização, independentemente do tamanho ou maturidade.

Collaboration

A colaboração no Purple Team é o alicerce de toda a abordagem. Tradicionalmente, o Red Team tenta encontrar vulnerabilidades e explorar sistemas, enquanto o Blue Team tenta detectar e responder a essas ameaças. No entanto, sem comunicação, o Red Team pode descobrir falhas que o Blue Team já conhece, ou o Blue Team pode não entender as táticas mais recentes usadas pelos atacantes. A colaboração muda esse cenário, criando um ciclo de feedback contínuo.

Na prática, a colaboração envolve reuniões regulares, sessões de planejamento conjunto e a criação de canais de comunicação abertos. Por exemplo, antes de um exercício de Red Team, as equipes podem se reunir para definir objetivos claros, escopo e regras de engajamento. Durante o exercício, o Blue Team pode fornecer informações em tempo real sobre alertas e atividades suspeitas, enquanto o Red Team pode ajustar suas táticas com base no feedback. Após o exercício, uma reunião de debriefing é essencial para discutir o que funcionou, o que não funcionou e o que pode ser melhorado.

Um exemplo prático de colaboração é o uso de um canal de comunicação compartilhado, como um Slack ou Microsoft Teams, onde ambas as equipes podem postar observações em tempo real. Além disso, a criação de um 'contrato' de colaboração, que define como as informações serão trocadas e como as decisões serão tomadas, pode ajudar a formalizar o processo. A colaboração também se estende ao desenvolvimento de casos de uso e cenários de ataque, onde o Red Team pode ensinar ao Blue Team as técnicas mais recentes e o Blue Team pode ensinar ao Red Team sobre as defesas existentes e os pontos cegos.

# Exemplo de um plano de colaboração em um exercício Purple Team

1. Reunião inicial: definir escopo, objetivos e regras de engajamento.
2. Durante o exercício:
   - Red Team: execute ataques controlados, documente cada passo.
   - Blue Team: monitore alertas, colete evidências, responda em tempo real.
   - Canal compartilhado: comunique descobertas e ajustes.
3. Debriefing: discuta resultados, métricas, lições aprendidas.
4. Ações de acompanhamento: implemente melhorias no SOC, ajuste detecções.

Detection tuning

O ajuste de detecção (detection tuning) é o processo de refinar as regras de detecção e os alertas para reduzir falsos positivos e aumentar a taxa de detecção de ameaças reais. No contexto do Purple Team, esse ajuste é feito de forma colaborativa: o Red Team fornece cenários de ataque realistas, e o Blue Team usa esses cenários para testar e melhorar suas detecções. Isso garante que os alertas sejam relevantes e acionáveis, evitando a fadiga de alertas que pode levar a incidentes perdidos.

Um dos principais desafios no ajuste de detecção é equilibrar sensibilidade e especificidade. Regras muito sensíveis geram muitos falsos positivos, sobrecarregando os analistas; regras muito específicas podem perder variações de ataques. O Purple Team aborda isso usando uma metodologia iterativa: o Red Team executa um ataque, o Blue Team verifica se o ataque foi detectado, e, se não foi, eles trabalham juntos para criar ou ajustar uma regra de detecção. Esse processo é repetido para diferentes tipos de ataque, criando um catálogo de detecções eficazes.

Ferramentas como SIEM (Security Information and Event Management), EDR (Endpoint Detection and Response) e IDS/IPS (Intrusion Detection/Prevention Systems) são frequentemente usadas para implementar as detecções. Por exemplo, uma regra de detecção pode ser criada no Sigma (um formato aberto para regras de detecção) e depois traduzida para a linguagem do SIEM. Abaixo está um exemplo de uma regra Sigma simples para detectar o uso de uma ferramenta de reconhecimento comum.

# Exemplo de regra Sigma para detectar reconhecimento de rede

title: Reconhecimento de rede com Nmap
description: Detecta varreduras de porta usando Nmap
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort:
      - 22
      - 80
      - 443
      - 445
    Protocol: TCP
  condition: selection
falsepositives:
  - Administradores legítimos
level: medium

O ajuste de detecção também envolve a análise de métricas, como taxa de verdadeiros positivos, falsos positivos e tempo de detecção. O Purple Team pode usar essas métricas para priorizar melhorias e medir o progresso ao longo do tempo. Além disso, é importante documentar todas as detecções e suas justificativas, criando uma base de conhecimento que pode ser consultada no futuro.

Shared context

O contexto compartilhado é o terceiro pilar do Purple Team e se refere à criação de uma visão unificada do ambiente de segurança, incluindo ativos, vulnerabilidades, táticas do adversário e defesas existentes. Ter contexto compartilhado permite que ambas as equipes tomem decisões informadas e alinhem seus esforços. Sem isso, o Red Team pode atacar sistemas que são críticos sem saber, e o Blue Team pode não entender quais ativos são mais valiosos para o negócio.

A construção de contexto compartilhado envolve a criação de documentação centralizada, como um 'livro de conhecimento' ou um repositório de informações. Isso pode incluir inventários de ativos, mapas de rede, diagramas de arquitetura, listas de controles de segurança e inteligência de ameaças. Ferramentas como wikis, sistemas de gerenciamento de configuração (CMDB) e plataformas de inteligência de ameaças (TIP) são frequentemente usadas para esse fim. Além disso, reuniões regulares para revisar e atualizar essas informações são essenciais.

Um exemplo prático de contexto compartilhado é a criação de um 'documento de contexto do adversário' que descreve as táticas, técnicas e procedimentos (TTPs) mais relevantes para a organização. Esse documento pode ser usado pelo Red Team para planejar ataques realistas e pelo Blue Team para priorizar detecções. Outra prática é a utilização de modelos de maturidade de segurança, como o MITRE ATT&CK, para mapear as capacidades de detecção existentes e identificar lacunas. Abaixo está um exemplo de como o contexto compartilhado pode ser estruturado.

# Exemplo de estrutura de contexto compartilhado

1. Inventário de ativos:
   - Servidores: IP, SO, serviços, criticidade.
   - Endpoints: dispositivos, usuários, software.
2. Mapa de rede:
   - Segmentos, zonas de segurança, fluxos de dados.
3. Controles de segurança:
   - Firewalls, IDS/IPS, EDR, SIEM.
4. Inteligência de ameaças:
   - Atores relevantes, TTPs, indicadores de comprometimento (IOCs).
5. Detecções atuais:
   - Regras, alertas, status.

O contexto compartilhado também é fundamental para a comunicação eficaz. Quando o Red Team reporta uma vulnerabilidade, o Blue Team precisa entender o impacto no negócio e a urgência da correção. Da mesma forma, quando o Blue Team relata um incidente, o Red Team pode ajudar a identificar a causa raiz e sugerir melhorias. Essa troca de informações só é possível quando há um contexto comum bem definido e acessível a todos.

Boas práticas e observações finais

Para implementar o Purple Team com sucesso, algumas boas práticas devem ser consideradas. Primeiro, comece pequeno: escolha um exercício específico e foque em melhorar a colaboração e as detecções relacionadas. Segundo, estabeleça métricas claras para avaliar o progresso, como o número de detecções eficazes ou a redução de falsos positivos. Terceiro, invista em ferramentas que facilitem a colaboração e o compartilhamento de informações, como plataformas de comunicação e repositórios centralizados.

Além disso, é fundamental que a liderança apoie a cultura de Purple Team, incentivando a transparência e o aprendizado contínuo. Os exercícios devem ser vistos como oportunidades de melhoria, não como competições. Por fim, lembre-se de que o Purple Team não é um projeto único, mas um processo contínuo que deve ser integrado à rotina de segurança da organização. A cada exercício, as equipes devem revisar e refinar seus processos, detecções e contexto compartilhado, criando um ciclo virtuoso de melhoria.

Referências

Exercícios

  1. Exercício 1: Descreva três benefícios da colaboração entre Red e Blue Team em um exercício de Purple Team. Dê um exemplo de como essa colaboração pode melhorar a detecção de uma ameaça específica.

    ✓ Resposta: Benefícios: 1) Redução de falsos positivos: o Blue Team pode ajustar regras com base nos ataques reais do Red Team. 2) Melhor compreensão das táticas do adversário: o Blue Team aprende com as técnicas do Red Team. 3) Aumento da eficiência: ambos os times evitam retrabalho. Exemplo: Se o Red Team usa uma técnica de living off the land (usando ferramentas legítimas do sistema), o Blue Team pode criar uma detecção baseada em comportamento, não apenas em assinaturas, melhorando a detecção de ataques semelhantes.
  2. Exercício 2: Explique o que é ajuste de detecção e por que é importante no contexto do Purple Team. Cite duas métricas que podem ser usadas para avaliar a eficácia das detecções.

    ✓ Resposta: Ajuste de detecção é o processo de refinar regras de detecção para reduzir falsos positivos e aumentar a detecção de ameaças reais. É importante porque alertas excessivos ou imprecisos podem sobrecarregar os analistas e fazer com que ataques reais passem despercebidos. Duas métricas: 1) Taxa de verdadeiros positivos (TPR) – proporção de alertas que são realmente ataques; 2) Taxa de falsos positivos (FPR) – proporção de alertas que não são ataques.
  3. Exercício 3: Crie um exemplo de uma regra Sigma simples para detectar uma atividade suspeita, como uma tentativa de brute force em SSH. Explique os componentes da regra.

    ✓ Resposta: Exemplo de regra Sigma:
    title: Tentativa de brute force em SSH
description: Detecta múltiplas falhas de autenticação SSH
logsource:
  category: authentication
  product: linux
detection:
  selection:
    EventID: 1000
    User: '*'
    Status: 'Failure'
  condition: selection | count() by src_ip > 5
falsepositives:
  - Usuários esquecendo suas senhas
level: medium
    Componentes: title (nome), description (descrição), logsource (fonte de log), detection (condição de detecção com seleção e condição), falsepositives (possíveis falsos positivos) e level (severidade).
  4. Exercício 4: Liste três informações que devem fazer parte do contexto compartilhado em uma organização e explique por que cada uma é importante para o Purple Team.

    ✓ Resposta: 1) Inventário de ativos: importante para saber quais sistemas são críticos e precisam de mais proteção; 2) Mapa de rede: ajuda a entender os fluxos de dados e possíveis caminhos de ataque; 3) Inteligência de ameaças: fornece informações sobre TTPs relevantes, permitindo que o Red Team planeje ataques realistas e o Blue Team priorize detecções.
  5. Exercício 5: Um exercício de Purple Team revelou que o Blue Team não detectou um ataque usando PowerShell. Proponha um plano para melhorar a detecção desse tipo de ataque, incluindo ações de colaboração e ajuste de detecção.

    ✓ Resposta: Plano: 1) Colaboração: o Red Team fornece detalhes do ataque, incluindo comandos e scripts usados, e o Blue Team analisa os logs existentes para identificar lacunas. 2) Ajuste de detecção: criar regras para detectar execução de PowerShell com parâmetros suspeitos (ex.: -EncodedCommand, -WindowStyle Hidden), uso de scripts não assinados, ou conexões de rede anômalas após a execução. 3) Testar as novas regras com o Red Team para verificar se detectam o ataque sem gerar muitos falsos positivos. 4) Documentar as regras e compartilhar no contexto comum.