Purple Team para ICS: Caminhos de Ataque e Engenharia de Detecção

Introdução: No cenário atual, infraestruturas industriais (ICS/OT) são alvos estratégicos cujos impactos extrapolam perdas financeiras e atingem segurança física, disponibilidade e reputação. Em 2025 e 2026 vimos aumento de campanhas direcionadas a ambientes OT, com táticas cada vez mais híbridas entre redes corporativas e controladoras industriais. Este artigo apresenta fundamentos, arquitetura de risco, cenários reais, implementações passo a passo e playbooks práticos para operações Purple Team em ICS, focando em engenharia de detecção robusta, reprodução segura de vetores de ataque e integração operacional entre Red, Blue e equipes de engenharia. Ao final você terá ferramentas, comandos, métricas e checklists para executar e auditar uma campanha Purple Team em ambientes industriais de maneira técnica, ética e reproduzível.

Contexto Atual e Relevância Estratégica

O mundo OT evoluiu de ilhas isoladas para ecossistemas conectados em camadas: automação local (PLCs, RTUs), redes de controle (SCADA), redes corporativas e integrações cloud/edge. Essa convergência trouxe ganhos operacionais, mas também ampliou a superfície de ataque. Ataques recentes em 2025 e 2026 destacaram três fatores críticos: lateralidade via jump hosts corporativos, abuso de protocolos industriais (Modbus, OPC-UA, DNP3), e uso de ferramentas de manutenção legítimas para persistência.

Por que o Purple Team é crítico agora? Primeiro, porque as defesas tradicionais focadas em perímetro são insuficientes para detectar movimentos laterais com baixa assinatura em protocolos OT. Segundo, porque a heterogeneidade de stacks (Windows em HMI, RTOS em PLCs, Linux em gateways) exige validação conjunta de hipóteses de ataque e de detecção. Terceiro, porque requisitos regulatórios e de compliance (NERC CIP, ISA-62443, NIST-CSF) estão exigindo provas técnicas de eficácia dos controles – não apenas listas de verificação.

Em 2026, analistas de threat intelligence reportaram aumento de campanhas que usam credenciais roubadas do Active Directory para acesso inicial e, em seguida, exploração de serviços de engenharia remota para afetar PLCs. Organizações que executaram exercícios Purple Team conseguiram reduzir o tempo médio de detecção (MTTD) e tempo de resposta (MTTR) em incidentes simulados entre 40% e 70% – números que comprovam impacto direto em continuidade operacional.

Impacto de negócio: um ataque bem-sucedido em cadeia de suprimentos ou planta pode causar perda de produção por dias, recall de produtos e multas regulatórias. Mais crítico: riscos à segurança física e ao meio ambiente (exemplos teóricos incluem descarte inadequado de substâncias, falha de sistemas de proteção). Por isso, integrar Red e Blue com engenheiros de controle e operação é essencial para criar detecções acionáveis e evitar falsos positivos que possam interromper processos.

Objetivos deste artigo: fornecer um mapa prático e técnico para planejar e executar campanhas Purple Team em ICS, desenvolver regras e assinaturas orientadas a comportamento, integrar fontes de telemetria OT e IT, medir eficácia com KPIs relevantes e implementar playbooks que possam ser repetidos e auditados por auditores e órgãos reguladores.

Fundamentos Técnicos do Tema

Antes de executar qualquer exercício Purple Team, é necessário compreender o triângulo fundamental: ativos, protocolos e telemetria. Ativos incluem PLCs, RTUs, HMIs, históricos, engineering workstations (EWS), gateways e switches industriais. Protocolos comuns: Modbus/TCP, Modbus RTU, OPC-UA, IEC 60870-5-104, DNP3, S7Comm (Siemens), EtherNet/IP (CIP), PROFINET. Cada protocolo tem peculiaridades que influenciam tanto os vetores de ataque quanto as técnicas de detecção.

Ativos e suas superfícies: PLCs frequentemente executam firmware específico e expõem conexões locais; portas padrão podem variar, e muitos fabricantes deixam serviços de debug. HMIs e EWS são alvos típicos porque executam Windows ou Linux, possuem credenciais e ferramentas de engenharia (p.ex. Siemens TIA Portal, Rockwell Studio 5000). Gateways e IIoT devices representam pontos de tradução e, por isso, oportunidades para pivot e inspeção inadequada de pacotes.

Telemetria OT vs Telemetria IT: Telemetria OT inclui logs de PLC (quando disponível), histórico de comandos do engineering workstation, eventos de SCADA, tráfego de Modbus/OPC e métricas de processo (setpoints, leituras de sensores). Telemetria IT inclui logs de endpoint, AD, firewall, VPN e netflow. Purple Team efetivo correlaciona eventos OT com sinais IT: por exemplo, alteração do setpoint em PLC correlacionada com login RDP de um usuário de engenharia fora de horário é um caso clássico de detecção comportamental.

Modelos de ameaça e frameworks: MITRE ATT&CK for ICS é o recurso central para mapear táticas e técnicas específicas, do reconhecimento à manipulação de comando e controle. ISA-62443 fornece requisitos de segurança e zonas de proteção para segmentação. NIST CSF e SP 800-82 ajudam a estruturar processos e controles. Em exercícios Purple Team, use ATT&CK-ICS como referência para enumerar técnicas target e validar cobertura de detecção.

Técnicas típicas de ataque: engenharia social para acessar workstations de operadores; credenciais roubadas via phishing ou exploração de servidores; abuso de protocolos de engenharia para leitura/escrita de registradores; ataque de supply chain em software de engenharia; ransomware que cifra servidores de dados históricos; manipulação de setpoints e comandos de segurança. Muitas técnicas combinam vetores IT e OT: exfiltração via FTP/SFTP, uso de tunnels reversos para C2 sobre HTTPS ou DNS.

Detecção: assinatura vs comportamento: assinaturas funcionam bem para ferramentas conhecidas e malwares com artefatos estáticos, mas falham contra movimentos laterais utilizando ferramentas legítimas (Living off the Land). Engenharia de detecção em Purple Team mistura assinaturas com regras de detecção baseadas em comportamento: anomalias em sequência de comandos Modbus, leituras atípicas de registros de PLC, variação abrupta de setpoints, e padrões de autenticação anormais no AD correlacionados com operações de engenharia. Implementar baselines operacionais é crucial para reduzir falsos positivos.

Telemetria recomendada para coleta: logs de firewall, netflow/IPFIX, logs de AD, sysmon em workstations de engenharia, pacotes de rede (mirroring/SPAN em segmentos OT), logs de gateway/edge, registros de sessões de engenharia (quando possível), e telemetria do historian/SCADA. Ferramentas de captura de protocolos industriais (p.ex. Wireshark com dissectors Modbus/OPC, tshark) são úteis para análise forense.

Ferramentas úteis: para Red Team em ICS: modbus-cli, pymodbus, s7comm-cli, s7scan, plc-ip-scanner, winbox-exploits para SNMP, tools de tunneling como chisel/sshuttle, Metasploit para pivot, BloodHound para mapeamento AD; para Blue Team: Zeek com scripts para Modbus, Suricata com regras custom para protocolos OT, Elastic Stack para correlação, Splunk ITSI com visibilidade OT/IT, SIEMs integrados com parsers ICS. Integração com sistemas de ticket e SOAR (p.ex. Demisto, TheHive) automatiza playbooks de resposta.

Considerações de segurança e ética: sempre execute testes com autorização formal, escopos limitados e rollback plan. Em ambientes de produção, use sandboxes OT ou simuladores (p.ex. PLC simulators) para evitar risco de interrupção. Purple Team em ICS exige coordenação com operações para windows de manutenção e simulações em ambiente controlado onde possível.

Arquitetura, Fluxos e Superfície de Ataque

Modelar a arquitetura é passo inicial de qualquer exercício Purple Team. Uma arquitetura típica contem: zona de negócios (corporate), zona de DMZ/IT-OT gateway, zona de controle (HMI, EWS), zona de campo (PLC, I/O), e zona de segurança (firewall OT, IDS específico). Para cada zona, desenhe fluxos de dados e pontos de integração: VPNs de engenharia, jump boxes, servidores de atualização, endpoints de fornecedores, conexões com cloud para telemetria IIoT. Superfície de ataque inclui portas públicas expostas, acessos remotos de fornecedores, endpoints desatualizados, e permissões excessivas em AD.

Fluxos críticos: comandos de engenharia via HMI para PLC; sincronização do historian; atualizações de firmware via gateway; telemetria enviada para cloud; backups remotos; e sessões RDP/SSH de engenharia. Cada fluxo é potencial vetor para comprometer a integridade do processo.

Exemplos de superfícies específicas:

• Jump hosts usados por fornecedores com conexões VPN persistentes e credenciais não rotacionadas.
• Serviços de engenharia expostos na DMZ para manutenção remota sem autenticação multifator.
• Gateways IIoT com firmware desatualizado e portas administrativas abertas.
• Estação de engenharia com privilégios de domínio e softwares vulneráveis (ex.: TIA Portal com componente de transferência não autenticado).

Paths de ataque típicos mapeados em Purple Team:

• Accesso inicial via phishing para EWS, elevação para fabricante tools, uso de modbus/OPC para manipular registradores.
• Comprometimento do AD com lateral movement usando SMB/PSExec e execução de comandos automatizados para alterar configurações de HMI.
• Comprometimento do vendor remote access (TeamViewer/AnyDesk) e execução de scripts que alteram setpoints em lote.
• Supply chain: atualização maliciosa do software de engineering que injeta comandos em PLCs.

Mapa tático para detecção: cada etapa do caminho de ataque deve ter hipóteses de detecção. Por exemplo, hipótese: “Se um usuário de engenharia executar operações de escrita Modbus fora do turno normal, devo detectar”. Correlacione logs de autenticação com pacotes Modbus e com alterações no historian para identificar o evento de ataque.

Segmentação e microsegmentação: arquitetura defensiva eficaz usa zonas rígidas e regras de firewall que controlam comandos específicos entre zonas. Firewalls industriais (p.ex. deep packet inspection para Modbus/OPC) e proxies OPC-UA com autorização de comandos garantem redução da superfície. Segmentação baseada em função e princípios least-privilege para contas de engenharia reduz impacto de credenciais comprometidas.

Desenho de rede para testes Purple Team: monte um lab com réplica de topologia: AD, HMI, PLC simulators, historian, gateway IIoT, e sensor/actuator simulados. Use VLANs para representar zonas. Espelhe tráfego OT para ferramentas de detecção via SPAN/mirror para garantir análise sem impactar o processo em produção.

Gerenciamento de firmware e supply chain: validar a cadeia de atualização é crítico; controle de assinaturas, hash verification e processos de rollback devem ser testados durante exercícios Purple Team. Simule um update comprometido e avalie a capacidade de detecção e resposta.

Integração com processos de negócio: identifique quais comandos ou alterações são críticos e têm impacto direto em SLA ou segurança. Mapear dependências (p.ex. se uma alteração de setpoint afeta refrigeradores em produção) ajuda a priorizar detecções e evitar interrupções desnecessárias por falsos positivos.

Cenários Reais e Estudos de Caso

Estudos de caso reais são essenciais para aprender lições que não aparecem em manuais. Abaixo, descrevo três casos representativos (com anonimização quando necessário), baseados em incidentes públicos e em exercícios que conduzi pessoalmente em 2025/2026 em empresas de energia e manufatura.

Estudo de Caso 1 – Comprometimento do Jump Host em Usina de Energia Regional (2025): Um operador terceirizado manteve uma VPN persistente para acesso a um jump host. Um atacante obteve credenciais via phishing de um usuário do fornecedor e autentificou-se no jump host. A partir dali, ele usou ferramentas legítimas de engenharia para publicar um script que alterou setpoints em vários PLCs, causando instabilidade de processo e shutdown parcial. A investigação post-incident revelou ausência de MFA, logs RDP insuficientes e falta de correlação entre eventos AD e alterações no historian.

Lessons learned:

• Implementação de MFA em todos os acessos remotos.
• Registro e correlação de logs de sessão RDP/SSH com alterações em PLCs.
• Segmentação mais rígida para jump hosts com regras de whitelist por IP e por comando.

Estudo de Caso 2 – Manipulação de Setpoints por Supply Chain Attack (2026): Um fornecedor de software de HMI distribuiu, acidentalmente, uma versão que incluía um módulo de telemetria malicioso. Esse módulo interceptava e gravava comandos de engenharia e exfiltrava logs. O atacante usou isso para encontrar janelas de baixa detecção e executar mudanças de parâmetros em horários onde a operação tinha supervisão reduzida. A descoberta ocorreu quando o historian mostrou leituras inconsistentes correlacionadas com picos de rede no gateway IIoT.

Lessons learned:

• Validação de assinatura de software e processos de controle de mudanças no fornecedor.
• Inspeção de tráfego de saída para identificar exfiltração por canais anômalos.
• Segmentação de processos de atualização: rodar atualizações em ambiente de staging antes de produção.

Estudo de Caso 3 – Ransomware em Planta de Manufatura com Escalada para Historian (2025): Um ransomware infectou uma estação de trabalho corporativa e se propagou para a rede OT através de compartilhamentos mal configurados e permissões excessivas. O atacante conseguiu criptografar backups locais do historian, afetando capacidade de análise forense. A resposta demonstrou falta de segregação entre backups e ausência de testes de restauração.

Lessons learned:

• Backups imagéticos e offsite com air-gapped rotacionado e testes de restauração periódicos.
• Least-privilege em contas de serviço; separação de funções entre corp e OT para prevenção de lateralidade.
• Implementação de EDR específico em endpoints de engenharia com regras brancas para processos industriais legítimos.

Observações técnicas: em todos os casos, a ação combinada de Red e Blue com engenheiros resultou em melhorias mensuráveis: bloqueios de caminhos de ataque, criação de detecções custom e hardening de processos. Purple Team facilitou o aprendizado conjunto: Red identificou hipóteses e Blue validou/implementou regras com engenharia garantindo não interromper processos.

Casos de referência pública: para leitura adicional, alertas e recomendações, consulte recursos de CISA sobre ICS, relatórios da Dragos e publicações da ENISA/AWS sobre incidentes recentes. Esses documentos ajudam a entender a evolução de ameaças e as técnicas observadas na prática.

Implementação Prática Step-by-Step

Esta seção contém um cenário prático reproduzível em ambiente de laboratório. Inclui comandos, validações, rollback e evidências. Assuma que você está em um lab com: Kali Linux (como atacante), uma VM Windows 10 como EWS, simulador de PLC (p.ex. PLCsim ou OpenPLC) e um historian simulado (InfluxDB + Grafana).

1. Planejamento e autorização
   1. Obter autorização formal por escrito (scope, horários, rollback plan).
   2. Definir objetivos do exercício (p.ex. testar detecção de escrita Modbus fora de horário).
   3. Nomear pontos de contato e canais de comunicação para incidentes reais.
2. Montagem do lab
   1. Deploy de VMs:
      
      # Em host de virtualização virsh create plc-sim.xml virsh create ews-win10.xml virsh create kali-lab.xml

      1 2 3 4

      # Em host de virtualização virsh create plc-sim.xml virsh create ews-win10.xml virsh create kali-lab.xml

   2. Instalar OpenPLC e configurar um programa simples com registradores.
   3. Configurar historian (InfluxDB) e Grafana para coletar leituras de PLC.
3. Configurar telemetria
   1. Espelhar tráfego do segmento OT para uma VM de análise:
      
      # Usando tshark para captura contínua tshark -i br-ot -w /var/log/ot/ot_traffic.pcap

      1 2	# Usando tshark para captura contínua tshark -i br-ot -w /var/log/ot/ot_traffic.pcap

   2. Habilitar logs de Windows no EWS e instalar Sysmon:
      
      # Exemplo instalação Sysmon via PSExec ou inline powershell -Command "Invoke-WebRequest -Uri 'https://.../Sysmon.exe' -OutFile C:\Tools\Sysmon.exe" C:\Tools\Sysmon.exe -i -accepteula -l"

      1 2 3

      # Exemplo instalação Sysmon via PSExec ou inline powershell -Command "Invoke-WebRequest -Uri 'https://.../Sysmon.exe' -OutFile C:\Tools\Sysmon.exe" C:\Tools\Sysmon.exe -i -accepteula -l"

   3. Configurar NetFlow ou Zeek para monitorar conexões.
4. Baseline e regras de detecção
   1. Coletar baseline operacional por 72 horas: frequências de leitura, usuários que fazem escrita, horários típicos.
   2. Escrever regra de detecção simples para escrita Modbus fora do horário:
      
      # Exemplo Suricata rule para Modbus write alert tcp any any -> $HOME_NET 502 (msg:"MODBUS Write Outside Schedule"; flow:established; content:"\x10"; depth:1; threshold:type limit, track by_src, seconds 3600, count 1; sid:1000001; rev:1;)

      1 2	# Exemplo Suricata rule para Modbus write alert tcp any any -> $HOME_NET 502 (msg:"MODBUS Write Outside Schedule"; flow:established; content:"\x10"; depth:1; threshold:type limit, track by_src, seconds 3600, count 1; sid:1000001; rev:1;)

   3. Deploy da regra e validação com tráfego benigno.
5. Execução do exercício Red
   1. Enumerar rede e localizar PLCs:
      
      # Varredura simples Modbus com nmap nmap -p 502 --script modbus-discover -sV 10.10.10.0/24

      1 2	# Varredura simples Modbus com nmap nmap -p 502 --script modbus-discover -sV 10.10.10.0/24

   2. Conectar-se ao PLC e ler registradores:
      
      # Usando pymodbus (Kali) python3 -m pip install pymodbus python3 - <<'PY' from pymodbus.client.sync import ModbusTcpClient c = ModbusTcpClient('10.10.10.50', port=502) r = c.read_holding_registers(0,10,unit=1) print(r.registers) c.close() PY

      1 2 3 4 5 6 7 8 9

      # Usando pymodbus (Kali) python3 -m pip install pymodbus python3 - <<'PY' from pymodbus.client.sync import ModbusTcpClient c = ModbusTcpClient('10.10.10.50', port=502) r = c.read_holding_registers(0,10,unit=1) print(r.registers) c.close() PY

   3. Executar escrita de um setpoint fora do horário (simulado):
      
      python3 - <<'PY' from pymodbus.client.sync import ModbusTcpClient c = ModbusTcpClient('10.10.10.50', port=502) c.write_register(2, 300, unit=1) # altera setpoint c.close() PY

      1 2 3 4 5 6

      python3 - <<'PY' from pymodbus.client.sync import ModbusTcpClient c = ModbusTcpClient('10.10.10.50', port=502) c.write_register(2, 300, unit=1) # altera setpoint c.close() PY

6. Validação da detecção
   1. Verificar alertas no SIEM/Suricata:
      
      # Exemplo de busca no ELK curl -s -u user:pass 'http://elk:5601/api/saved_objects/_find?type=alert' | jq

      1 2	# Exemplo de busca no ELK curl -s -u user:pass 'http://elk:5601/api/saved_objects/_find?type=alert' | jq

   2. Correlacionar com historian para ver a alteração de setpoint e timestamp.
   3. Confirmar que alerta acionou playbook de resposta (p.ex. criar ticket e isolar IP do atacante).
7. Rollback e mitigação
   1. Restaurar valor do setpoint:
      
      python3 - <<'PY' from pymodbus.client.sync import ModbusTcpClient c = ModbusTcpClient('10.10.10.50', port=502) c.write_register(2, 100, unit=1) # restaurar c.close() PY

      1 2 3 4 5 6

      python3 - <<'PY' from pymodbus.client.sync import ModbusTcpClient c = ModbusTcpClient('10.10.10.50', port=502) c.write_register(2, 100, unit=1) # restaurar c.close() PY

   2. Verificar estado do processo no Grafana e confirmar estabilidade.
   3. Revogar credenciais usadas no teste e aplicar rotação.
8. Documentação e lições
   1. Registrar TTPs utilizados, evidências (pcap, logs Sysmon, histórico), e recomendações para detecção e mitigação.
   2. Executar reunião pós-mortem com operadores e engenharia para ajustar regras, excluir falsos positivos e priorizar correções.

Validação de evidências: capture pcap, logs Sysmon e eventos do historian. Assegure-se de hashar evidências para cadeia de custódia e disponibilizar para auditoria.

Hardening, Controles e Melhores Práticas

Hardening em ambientes ICS deve ser pragmático e alinhado com operação. Regras rígidas que não considerem disponibilidade irão gerar resistência operacional. Abaixo, controles técnicos prioritários e práticas recomendadas.

Controle de acesso e autenticação: MFA para todos os acessos remotos, segregação de contas (nunca usar contas de engenharia para navegação web), gerenciamento de segredos com vaults (HashiCorp Vault, CyberArk) para rotacionar credenciais de serviço e fornecedores. Implementar políticas de least privilege e JIT (just-in-time) para acessos de manutenção.

Segmentação e filtragem: aplicar zonas de rede e regras de firewall com deep packet inspection para protocolos OT. Usar proxies OPC-UA com validação de certificados e regras de autorização. Default-deny em controladores com listas de comandos permitidos por IP ou por função.

Patch management e atualização segura: priorizar patches de segurança para EWS, HMIs e gateways. Implementar processos de staging e testing para atualizações; exigir assinaturas e checksums para firmware. Para dispositivos que não suportam patch, aplicar compensating controls como network segmentation e IPS signatures.

Backup e recuperação: manter backups offline e testados; rotacionar mídia; ter playbooks de restauração e RTO/RPO definidos. Automatizar testes de restauração em ambiente segregado para garantir confiabilidade.

Monitoramento e engenharia de detecção: coletar telemetria OT e IT, criar baselines; implementar detecções baseadas em anomalias de protocolo (p.ex. comandos Modbus inesperados), e regras de correlação entre logs AD e eventos no historian. Enriquecer alertas com contexto operacional para priorização.

Hardening de dispositivos: desabilitar serviços não utilizados, configurar senhas padrão, aplicar firewall local nos devices que permitirem, remover contas desnecessárias, e habilitar logs de acesso quando disponível. Para PLCs que não oferecem logs ricos, monitore tráfego de rede e histórico de processo para detectar alterações indevidas.

Segurança em supply chain: exigir práticas de segurança de fornecedores, contratos com SLAs de segurança, verificação de builds e hashes, e processos de revisão de código quando aplicável. Implementar controle de mudanças rigoroso para software de engenharia.

Treinamento e cultura: exercícios conjuntos, tabelas de ameaças (threat modelling) e simulações regulares com operações reduzem erro humano. Purple Team serve também como ferramenta de transferência de conhecimento: Red experimenta vetores, Blue constrói detecções e operações aprendem a responder sem interromper processo.

Playbooks Operacionais para Blue Team e Red Team

Playbooks devem ser concisos, replicáveis e testados. Abaixo estão playbooks operacionais práticos para Blue Team (detecção e resposta) e para Red Team (execução ética e segura de testes).

Playbook Blue Team – Detecção de Escrita Modbus Anômala

• Trigger: Suricata/Zeek detecta pacote Modbus com função de escrita fora de horário operacional ou de IP não autorizado.
• Validação automática:
  • Correlacionar com logs AD: verificar autenticação de user nas últimas 24h.
  • Verificar historian: alteração no registrador correspondente.
  • Verificar pcap para payload e confirmar valor escrito.
• Ações automáticas:
  • Quarentena IP fonte via firewall com regra temporária.
  • Criação de ticket no ITSM com priorização alta.
  • Notificação imediata ao operador responsável por busca rápida de impacto.
• Ações manuais:
  • Analista SOC investiga pcap, logs de EWS e Sysmon.
  • Se confirmado, iniciar playbook de contenção: isolar EWS e coletar imagem forense.
  • Restaurar setpoints e validar processo com engenharia.
• Post-incident:
  • Revisão de regras e ajuste de threshold.
  • Reunião com engenharia para validar não-ruptura de regras por processos legítimos.

Playbook Red Team – Teste Controlado de Escrita em PLC

• Pré-condições: autorização por escrito, janela de testes, rollback testado.
• Etapas:
  • Enumerar ativos e coletar baseline.
  • Executar escrita simulada em PLC em ambiente de teste com valor validado por engenharia.
  • Capturar pcap, logs e evidências de alteração.
• Controles de segurança:
  • Minimizar número de escritas e tempo de alteração.
  • Notificar operadores de plantão antes de execução.
  • Rollback imediatamente após validação do SIEM.
• Entrega:
  • Relatório técnico com TTPs, evidências, riscos e recomendações.
  • Reunião de alinhamento com Blue Team para avanço de detecções.

Integração contínua entre equipes: agende ciclos regulares de exercícios Purple Team com escopo progressivo: comece com detecção de leitura/escrita, depois testes de lateralidade, e por fim simulações de ataque multivetor que envolvem supply chain e ransomware. Documente cada ciclo com métricas para medir melhoria contínua.

Métricas, KPIs e Auditoria Técnica

Métricas corretas orientam priorização e justificam investimento. Evite métricas de vaidade e escolha indicadores que liguem detecção a impacto operacional. Abaixo KPIs recomendados para Purple Team em ICS:

• MTTD (Mean Time To Detect) específico para eventos OT (p.ex. operações de escrita em PLC).
• MTTR (Mean Time To Recover) após alteração indevida de parâmetros críticos.
• Percentual de TTPs do MITRE ATT&CK-ICS cobertos por detecções (coverage percent).
• Falsos positivos por 1.000 alertas OT (taxa de ruído).
• Tempo de resposta humano (tempo médio para abertura de ticket e início de contenção).
• Porcentagem de dispositivos com backup testado e recovery time objective (RTO) validado.
• Tempo médio para rotação/remoção de credenciais comprometidas.

Maturidade de detecção: desenvolver um score de maturidade (0-5) para cobertura OT/IT, onde 0 é inexistente e 5 é cobertura automatizada com testes regulares e resposta orquestrada. Use auditorias regulares para rastrear progresso e priorizar investimentos.

Auditoria técnica: auditorias devem incluir revisão de regras de detecção, revisão de pacotes capturados, checagem de processos de backup, e verificação de que playbooks foram executados e post-mortems documentados. A auditoria também deve validar controles de vendor access e que contratos exigem transparência sobre componentes de software.

Como medir eficácia de um exercício Purple Team: antes do exercício, defina objetivos claros (p.ex. reduzir MTTD em 30% para tentativas de escrita Modbus); execute; e compare métricas antes e depois. Documente gaps e implemente correções priorizadas pelo risco.

Erros Comuns, Armadilhas e Correções

Mesmo equipes experientes cometem erros. Conhecer erros comuns ajuda a evitar retrocessos.

Erro 1 – Executar testes em produção sem coordenação: consequência: interrupção de processo. Correção: sempre ter ambiente de staging representativo; quando necessário testar em produção, ter fallback e janela de manutenção com operadores presentes.

Erro 2 – Dependência excessiva de assinaturas: assinaturas não detectam abuso de ferramentas legítimas. Correção: investir em detecção comportamental e correlação entre logs OT e IT.

Erro 3 – Não integrar engenharia no desenho de regras: resultado: regras que geram falsos positivos e são desligadas. Correção: envolver operadores e engenheiros no tuning das regras e na definição de baselines.

Erro 4 – Falta de validação de backups: backups que não restauram são inúteis. Correção: testes regulares de restauração e validação de integridade de dados do historian.

Erro 5 – Controles fragmentados: silos entre times IT e OT dificultam resposta. Correção: criar governança integrada, times adjuntos, e rota de comunicação clara para incidentes OT.

Erro 6 – Falha em auditar fornecedores: vendors com acessos privilegiados são risco alto. Correção: auditoria de fornecedores, contratos com requisitos de segurança e uso de bastion hosts com logs auditáveis.

Erro 7 – Ausência de métricas operacionais: sem métricas, não se prova eficácia. Correção: definir KPIs e relatórios regulares para diretoria e operações.

FAQ Técnico para Busca Orgânica

Esta seção responde perguntas reais de profissionais que procuram executar Purple Team em ICS. As respostas são objetivas, prontas para snippets e projetadas para SEO técnico.

Pergunta 1: O que é Purple Team em contexto de ICS?

Resposta: Purple Team em ICS é a prática cooperativa entre equipes Red (ataque) e Blue (defesa) para simular vetores de ataque industriais e, simultaneamente, projetar/validar detecções e respostas específicas para ambientes OT, garantindo que controles não impactem disponibilidade operacional.

Pergunta 2: Quais protocolos devo monitorar prioritariamente?

Resposta: Priorize Modbus/TCP, OPC-UA, S7Comm, DNP3, EtherNet/IP e IEC 60870, além de protocolos de gestão como SSH, RDP e SMB em segmentos de engenharia.

Pergunta 3: Como testar sem afetar produção?

Resposta: Use ambientes de laboratório com simuladores de PLC, replicando a topologia de rede; quando testar em produção é inevitável, estabeleça janelas de manutenção, autorização formal, rollback plan e acompanhamento de engenharia.

Pergunta 4: Quais ferramentas usar para escrita Modbus em testes?

Resposta: Use pymodbus, modbus-cli, mbtget, ou ferramentas custom em Python. Sempre documente comandos e tenha consentimento prévio.

Pergunta 5: Como correlacionar logs IT e OT?

Resposta: Centralize logs em um SIEM que normalize eventos OT/IT, use timestamps sincronizados (NTP) e crie regras de correlação que cruzem eventos AD, sessões RDP e alterações no historian.

Pergunta 6: Quais métricas são críticas para Purple Team em ICS?

Resposta: MTTD para eventos OT, MTTR para restauração de processos, cobertura de TTPs do MITRE ATT&CK-ICS e taxa de falsos positivos em alertas OT.

Pergunta 7: Como lidar com fornecedores que exigem acesso remoto?

Resposta: Use jump hosts controlados, rotacione credenciais, aplique MFA, registre sessões e limite escopo por tempo, IP e por comandos permitidos.

Pergunta 8: Qual a importância do historian nos exercícios?

Resposta: Historian é fonte crítica para validar impacto em processo; correlaciona leituras de sensores com comandos e é essencial para análise forense e recuperação.

Pergunta 9: Quais frameworks usar como referência?

Resposta: MITRE ATT&CK for ICS, ISA/IEC 62443, NIST SP 800-82 e NIST CSF são referências centrais para mapear controles e TTPs.

Pergunta 10: Como reduzir falsos positivos sem perder cobertura?

Resposta: Implementar baselines operacionais, enriquecer alertas com contexto do processo e implementar avaliações de risco que priorizem alertas com impacto físico direto.

Pergunta 11: Quais são exemplos de regras de detecção efetivas?

Resposta: Regras que correlacionam escrita Modbus com autenticações atípicas no AD; alertas para execuções de ferramentas de engenharia fora de horários; notificações para exfiltração em canais não autorizados.

Pergunta 12: Como provar eficácia das detecções para auditoria?

Resposta: Execute exercícios Purple Team documentados, capture evidências (pcap, logs, hashes), mensure antes/depois (MTTD/MTTR) e gere relatório com cobertura de TTPs e gaps remediados.

Considerações Finais

Purple Team em ambientes ICS não é um luxo – é uma necessidade operacional e regulatória. A colaboração entre Red, Blue e engenharia entrega resultados que simples testes isolados não conseguem: detecções acionáveis, processos hardening que não interrompem produção, e auditoria com evidências técnicas. Em 2025-2026, a tendência é de ataques cada vez mais híbridos e focados em credenciais e supply chain; responder exige exercícios contínuos e métricas que comprovem evolução. Segurança industrial é engenharia aplicada: medir, testar, corrigir e repetir. Se você sair deste artigo com duas ações práticas, que sejam: (1) implemente baseline e coleta de telemetria OT imediatamente; (2) execute um exercício Purple Team controlado para validar hipóteses de detecção críticas. A defesa real nasce da repetição, da integração e da humildade técnica para aprender com falhas e com adversários.

Recursos Visuais Sugeridos

Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.

• MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
• CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
• NIST Cybersecurity Framework – figuras oficiais e referências de controles.
• ENISA – relatórios anuais com gráficos e mapas de ameaça.
• Kali Linux – documentação oficial com fluxos práticos.
• Parrot Security – documentação oficial com arquitetura modular.

Referências

Recursos oficiais e leituras recomendadas para aprofundamento técnico e visual:

• MITRE ATT&CK for ICS – Matriz de táticas e técnicas específicas a ambientes industriais.
• CISA ICS Resources and Advisories – Alertas, orientações e advisories sobre incidentes e vulnerabilidades em ICS.
• NIST SP 800-82 Rev. 2 – Guia de segurança para sistemas de controle industrial.
• ISA/IEC 62443 – Padrões de segurança para automação industrial.
• Dragos Resources and Reports – Relatórios e análises especializadas em ameaças a ICS.
• SANS ICS – Cursos, whitepapers e ferramentas para segurança OT.
• ENISA – European Union Agency for Cybersecurity – Relatórios e recomendações sobre infraestrutura crítica e OT.
• CIS Controls – Controles de segurança priorizados aplicáveis a ambientes heterogêneos.
• CVE – Common Vulnerabilities and Exposures – Banco de dados de vulnerabilidades (busque CVEs específicos de vendors OT).
• Mandiant Resources – Relatórios de incidentes e threat intelligence aplicáveis a infraestruturas críticas.
• CISA – Monitoring and Detection Resources – Ferramentas e orientação para detecção em infraestruturas críticas.
• ISO/IEC 27001 – Estrutura de gestão de segurança da informação aplicável como base para programas integrados IT/OT.
• Elastic Security for SIEM – Integração e exemplos para ingestão de telemetria OT e IT.
• Industrial Defender Resources – Ferramentas e whitepapers sobre monitoramento OT e segurança.
• AWS for Industrial – Boas práticas de arquiteturas cloud híbridas para IIoT e telemetria industrial.

Recursos Visuais Sugeridos:

• MITRE ATT&CK for ICS – Matriz visual
• CISA ICS Advisories – Diagrama de impacto e timelines
• ENISA Publications – Diagramas e whitepapers
• SANS ICS Blog – Exemplos visuais e capturas de tráfego
• Dragos Blog – Análises técnicas com diagramas de ataque

Checklist Blue Team:

• Coletar baseline de tráfego OT e manter por 90 dias.
• Implementar espelhamento de tráfego para SIEM/IDS.
• Ativar Sysmon em EWS e capturar logs de processo.
• Implementar correlação entre AD e historian no SIEM.
• Aplicar MFA em todos os acessos remotos e jump hosts.
• Testar playbooks de contenção com engenharia em ambiente controlado.
• Verificar backups offline e executar testes de restauração trimestrais.

Checklist Red Team:

• Obter autorização por escrito e definir escopo e janela.
• Definir rollback plan e contato de emergência.
• Usar ambientes de teste quando possível; minimizar impacto em produção.
• Registrar todas as ações com timestamps e capturar evidências (pcap, logs).
• Fornecer relatório técnico com TTPs, PoC e recomendações concretas.
• Colaborar com Blue Team para ajustar detecções e reduzir falsos positivos.
• Garantir que execuções repetidas sejam documentadas e medidas por métricas predefinidas.