Laboratório para Simulação de Adversários em ICS

por União Geek · 13 de julho de 2026

Laboratório para Simulação de Adversários em ICS

Introdução: Em um mundo onde sistemas de controle industrial (ICS/OT) comandam desde usinas elétricas até linhas de montagem automatizadas, defender sem praticar é como treinar um bombeiro sem fogo. Este artigo apresenta um roteiro técnico e aprofundado para projetar, construir e operar um laboratório de simulação de adversários voltado a ambientes ICS. Você vai entender a relevância estratégica dessa capacidade, os fundamentos técnicos dos protocolos e equipamentos, arquitetura de laboratório (físico, virtual e híbrido), cenários replicáveis, comandos práticos para Kali/Parrot/Windows, hardening, playbooks para Red Team e Blue Team, métricas, armadilhas comuns e um FAQ técnico pensado para SEO. Ao final, terá checklist operacional e referências oficiais para validar cada etapa.

Contexto Atual e Relevância Estratégica

Subtópico: Por que montar um laboratório de simulação de adversários em ICS hoje?

Nos últimos anos, o risco sobre infraestruturas críticas escalou em complexidade e frequência. Atacantes já demonstraram capacidade de causar impactos físicos e econômicos severos, como os casos públicos de Stuxnet (2010), Industroyer/CrashOverride (2016-2017), Triton/Trisis (2017) e incidentes contínuos expostos por empresas como Dragos e Mandiant. Esses eventos provaram que vulnerabilidades em PLCs, HMIs, RTUs e gateways podem ser exploradas para alterar processos físicos, provocar downtime e afetar segurança humana. Um laboratório controlado permite replicar vetores de ataque, validar deteções, treinar resposta e testar contramedidas sem risco para produção.

Subtópico: Mudanças recentes no cenário (contexto 2024 e tendências)

Embora minhas referências fechadas alcancem até meados de 2024, tendências observadas até então continuam relevantes: convergência IT/OT, adoção crescente de protocolos seguros como OPC UA, incremento no uso de cloud e IIoT que ampliam a superfície de ataque, além do surgimento de supply-chain risks para firmware e componentes ICS. Em 2024, relatórios públicos de agentes de risco mostraram aumento de campanhas que exploram autenticação fraca, vulnerabilidades em stacks III-party (bibliotecas), e falhas de configuração em gateways. Em 2025/2026 espera-se que a sofisticação aumente com automação de ataques e uso de AI para reconhecimento de topologias OT; portanto, laboratórios para simulação de adversários em ICS são estratégicos para antecipar e mitigar essa evolução.

Subtópico: Impacto de negócio

Uma interrupção prolongada em ICS pode representar perdas diretas (controle de processos, produção parada), indiretas (multas regulatórias, imagem), e riscos humanos. Para empresas reguladas por normas como NERC CIP (setor elétrico) ou sob requisitos de segurança industrial (IEC 62443/ISA-62443), demonstrar capacidade de testar e mitigar ameaças com um laboratório ajuda a reduzir exposição e atender auditorias. Além disso, para provedores de serviços gerenciados e integradores OT, laboratórios são essenciais para validar soluções, firmwares e atualizações antes da jornada para ambiente real.

Subtópico: Objetivos táticos do laboratório

Reproduzir topologias ICS típicas (PLC-HMI-SCADA- Historian – DMZ – ERP).
Validar assinaturas e regras em SIEM/SOC para tráfego Modbus, DNP3, IEC 60870-5-104, OPC UA.
Testar ferramentas de detecção de anomalias baseadas em rede (NTA) e host (EDR/endpoint OT).
Executar exercícios de Red Team para treinar resposta e playbooks do Blue Team.
Realizar vulnerabilidade assessment e testes de hardening em dispositivos e softwares OT.

Subtópico: Conformidade, responsabilidade e ética

Qualquer atividade que envolva simulação de adversários em ICS exige governança estrita: escopo autorizado, segregação de rede, isolamento físico/virtual, acordos de não-divulgação e planos de rollback. Em ambientes industriais reais, testes sem autorização podem causar danos físicos. No laboratório, reproduzir falhas e ataques exige rotinas de backup e snapshot, e políticas claras de segurança para evitar fuga de código malicioso para outras redes.

Fundamentos Técnicos do Tema

Subtópico: Componentes típicos de um ambiente ICS

Um ambiente ICS clássico contém vários elementos convergentes: controladores lógicos programáveis (PLCs), controladores lógicos baseados em RTU, sistemas SCADA (HMI, Historian), servidores de engenharia, switches industriais (EtherNet/IP, Profinet), gateways OT/IT, sensores/atuadores, e protocolos de campo. Compreender cada componente e suas falhas operacionais é pré-requisito para simulação de adversário.

Subtópico: Protocolos essenciais e características

Para projetar simulações realistas é crucial dominar os protocolos: Modbus/TCP e Modbus RTU (simplicidade e ausência de autenticação), DNP3 (usado em energia e utilidades), IEC 61850 e IEC 60870 (subestações elétricas e automação), PROFINET e EtherNet/IP (fábricas), OPC UA (telemetria e integração com IT), e protocolos proprietários de vendors (Siemens S7, Rockwell). Cada protocolo tem peculiaridades: Modbus usa funcional codes simples, DNP3 suporta time synchronization e câmeras de estado, OPC UA pode operar com certificação TLS e estratégias de aplicação de ataques são diferentes quando TLS/secure channels estão presentes.

Subtópico: Vectores de ataque comuns

Dois grandes vetores aparecem com frequência: comprometimento de credenciais e pivot pela rede IT até dispositivos OT; e exploração direta de vulnerabilidades em stacks OT (firmware, protocolos). Exemplos: exploração de portas expostas (502/Modbus), execução remota em engenharia servers (ex: EDS/PCS vulnerabilities), injeção de comandos em PLC através de protocolos sem autenticação, e ataques de supply-chain em firmwares de PLC. Ataques modernos combinam reconhecimento automático (Nmap, custom scanners), exploração de vulnerabilidades conhecidas (CVE), e ações de sabotagem (comandos que alteram setpoints). Em 2017, Triton atacou dispositivos de segurança (SIS) para desabilitar proteções; isso mostra a evolução do objetivo final: controlar a lógica que impede danos físicos.

Subtópico: Emulação vs hardware real

Laboratórios podem ser 100% virtuais, totalmente com hardware real, ou híbridos. Emulação (OpenPLC, PLCsim, QEMU) oferece baixo custo e facilidade de snapshot/rollback; hardware real (PLCs Siemens/Allen-Bradley) fornece fidelidade e mostra quirks reais de firmware, interfaces físicas e ruídos elétricos. Para exercícios avançados, recomenda-se a combinação: emular lógica de controle e conectar a um PLC real para validar firmware e integração de I/O.

Subtópico: Ferramentas e stacks recomendados

Ferramentas de ataque: Kali Linux (nmap, metasploit, scapy), cxpscanner (probes para Modbus/DNP3), os-simulators (OpenPLC, S7CommPlus). Ferramentas de defesa: Zeek com scripts para Modbus, Suricata com regras para ICS, Bro/Zeek ICS scripts, ELK/Opensearch para correlação, Splunk/QRadar integrando parsers ICS. Platforms de orquestração de lab: EVE-NG, GNS3, VMware, Proxmox + Docker para isolar containers. Para análises mais profundas, use Wireshark com dissectors para protocolos ICS, e ferramentas de fuzzing customizadas em Python com Scapy.

Subtópico: Considerações sobre segurança do laboratório

Isolamento físico e/ou lógico é obrigatório. Use VLANs, firewalls de laboratório e regras de IPTABLES para impedir que VMs de ataque saiam para a internet. Ative registros detalhados (pcap, logs do hypervisor) e mantenha snapshots de imagens limpas. Notifique stakeholders e registre escopo e horário das simulações.

Arquitetura, Fluxos e Superfície de Ataque

Subtópico: Modelos de arquitetura para laboratórios ICS

Arquitetura do laboratório deve refletir uma topologia OT realística: zona de produção (PLCs, RTUs, sensores), zona de operações (HMI, SCADA, Historian), zona de engenharia (Engineering Workstations, FTP/SMB servers), e zona de DMZ/IT (MES/ERP, SIEM). Em seguida, defina caminhos de comunicação e controles entre zonas. Segmentar zonas com firewalls e aplicar regras de acesso mínimo reproduzirá superfície de ataque realista.

Subtópico: Exemplo de fluxo de ataque

Fluxo típico: atacante compromete estação IT (phishing ou vulnerabilidade), ganha acesso lateral, encontra credenciais de engenharia armazenadas em servidor compartilhado, conecta via protocolo não seguro (ex: S7Comm ou Modbus/TCP) ao PLC e injeta comandos, alterando setpoints ou iniciando condições inseguras. Em paralelo, pode tentar desmontar logs ou encriptar Historian para evitar análise. Uma arquitetura de laboratório deve permitir exercitar cada etapa: phishing simulado, pivoting (jump hosts), descoberta de rede OT, exploração de protocolo e evasão de deteção.

Subtópico: Superfície de ataque detalhada

Identifique ativos críticos e exposições: portas abertas, serviços não atualizados, credenciais default, gerenciamento remoto inseguro (VPNs mal configuradas), NTP e time skew, backups sem criptografia e interfaces de engenharia com privilégios desnecessários. Mapear a superfície envolve inventário de dispositivos (MAC/firmware/serial number), análise de topologia (temps, redundância e failover) e compreensão de dependências físicas (natureza do processo controlado).

Subtópico: Arquitetura recomendada do laboratório

Proposta: isolamento em pelo menos três VLANs ou redes físicas – (1) Rede de Gateway/DMZ (HMI, Historian); (2) Rede de Controle (PLCs, switches industriais); (3) Rede de Engenharia/IT (workstations, build servers). Um segmento separado para Red Team permite gerar tráfego malicioso e controlar pivots. Camadas de visibilidade incluem SPAN ports/port mirroring para capturar tráfego com Wireshark/Zeek, e TAPs virtuais para pcap centralizado. Em setups híbridos, use conversores físicos (USB-I/O) e simulações via Docker/OpenPLC conectadas a PLC real via Modbus TCP para criar um ambiente crível.

Subtópico: Ferramentas de mapeamento de superfície

Nmap com scripts NSE para Modbus/S7: identificar funções e possíveis escritas.
Scapy para montagem de pacotes customizados e fuzzing.
PLCScan/PLCScanner (ferramentas Open Source) para descoberta rápida.
Splunk/ELK com parsers para correlacionar eventos entre IT e OT.

Subtópico: Exposição por integração cloud/IIoT

Atualmente muitos sistemas OT expõem telemetria para cloud ou usam gateways IIoT para ingestão. Essas integrações ampliam surface attacks: credenciais de API, certificados mal gerenciados, e misconfigurações em TLS podem permitir acesso remoto. Um laboratório deve incluir componentes cloud-sim (mocked ingestion endpoints) para testar perfis de risco e controle de tráfego.

Cenários Reais e Estudos de Caso

Subtópico: Estudo de caso 1 – Triton/Trisis (2017) e implicações

Triton é um caso emblemático: adversários conseguiram manipular controladores SIS (Safety Instrumented Systems) – dispositivos críticos que atuam como última barreira de proteção. O vetor incluiu acesso a estações de engenharia e uso de ferramentas específicas para interagir com hardware de segurança. As lições: 1) sistemas de segurança tornam-se alvos de alto valor; 2) segregação e defesa em profundidade falham quando credenciais são compartilhadas; 3) testes em laboratórios devem incluir simulações de SIS, replicando lógica de segurança e falhas de interação.

Subtópico: Estudo de caso 2 – Industroyer/CrashOverride (2016)

Industroyer atacou subestações elétricas utilizando mensagens válidas de protocolos industriais para abrir breakers. Dessa campanha tiramos ensinamentos sobre o uso de tráfego legítimo para causar efeitos adversos. Em um laboratório devemos replicar tráfego de comando legitimo e monitorar diferenciação entre operação normal e anômala, verificando a eficácia de IDS/IPS e sistemas NTA em detectar padrões de comando abusivos.

Subtópico: Estudo de caso 3 – Ataques recentes a linhas de produção e fornecedores

Em 2021-2023 houve vários incidentes que mostraram interrupções via ransomware que atingiram cadeias de suprimentos industriais (ex: Colonal Pipeline 2021; incidentes em fabricantes); em muitos casos, o vetor inicial foi IT, com pivot para OT. Como consequência, exercícios de laboratório devem integrar a simulação do impacto de ransomware sobre servidores Historian, backups e estações de engenharia, e testar playbooks de recuperação que preservem segurança funcional do processo.

Subtópico: Caso local e lições operacionais (exemplos históricos brasileiros)

No Brasil, incidentes públicos em OT geralmente se referem a falhas operacionais e esforços de proteção de infraestruturas críticas. Embora casos específicos de ataques sofisticados tenham sido menos divulgados por razões de segurança, o que se observa é uma tendência de crescimento em tentativas de acesso remoto e scans massivos de Modbus/DNP3 na internet. Laboratórios locais devem contemplar cenários de conformidade com ANEEL/ANP e práticas de notificação de incidentes ao CERT.br e agências reguladoras.

Subtópico: Análise tática: como transformar estudo de caso em cenário replicável

Para cada estudo de caso, decompose em fase: Reconhecimento (asset inventory), Acesso inicial (phishing/exploit), Pivoting (credenciais/remote services), Controle (comandos sobre PLC), Ocultação (log tampering) e Efeito físico (setpoint modifications). No laboratório, crie exercícios que reproduzam cada fase com objetivos claros de validação de detecção e mitigação, metas de tempo (MTTD/MTTR), e métricas de sucesso (detecção de anomalia, contenção pré-falha).

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

Subtópico: Planejamento e requisitos

Antes de começar, documente: objetivo do laboratório (teste de detecção, validação de firmware, treinamentos), requisitos de hardware (servidores, switches industriais, PLCs), ferramentas (EVE-NG, OpenPLC, Kali, Zeek, Suricata), e requisitos de segurança (segmentação, backup, aprovação). Defina uma topologia mínima para seu primeiro laboratório: uma VM de SCADA/HMI, dois PLCs (um emulado OpenPLC, outro físico se possível), um Historian, um gateway de DMZ e uma VM do Red Team (Kali).

Subtópico: Montagem do ambiente – infraestrutura base

Provisionamento de hosts: utilize um servidor com recursos suficientes para rodar VMs (ex: ESXi, Proxmox, ou EVE-NG). Recomendação mínima para ambiente inicial: CPU 8 cores, 32-64GB RAM, 2TB SSD. Para labs com hardware real, adicione switches industriais e TAPs.
Crie redes isoladas (VLANs) para Produção, Engenharia e Testes. Configure firewall local para evitar tráfego de saída não autorizado.
Instale EVE-NG ou Proxmox para gerenciamento de topologias. EVE-NG facilita integração de imagens de PLC e VMs.

Subtópico: Componentes de software e instalação

Use imagens oficiais quando possível. Lista recomendada:

Kali Linux (latest): para offensive tools.
OpenPLC runtime e editor: https://www.openplcproject.com/.
ScadaBR ou Ignition Edge (HMIs open source/commercial) para HMI simulada.
Historian leve: InfluxDB + Grafana para visualizar telemetria.
Zeek e Suricata para rede NDR/IDS.
ELK/Opensearch para centralizar logs.

Subtópico: Configuração prática – passo a passo (comandos)

Exemplo de configuração minimal para OpenPLC + Modbus Server + HMI em Ubuntu Server 22.04 (sem hardware físico):

# Atualizar sistema
sudo apt update && sudo apt upgrade -y

# Instalar dependências
sudo apt install -y python3-pip docker.io docker-compose git

# Baixar OpenPLC
git clone https://github.com/thiagoralves/OpenPLC_v3.git /opt/openplc
cd /opt/openplc

# Rodar container OpenPLC (exemplo simplificado)
sudo docker-compose up -d

# Instalar InfluxDB e Grafana via Docker Compose (simplificado)
cat > docker-compose.yml <<EOF
version: '3'
services:
  influxdb:
    image: influxdb:2.0
    ports:
      - "8086:8086"
  grafana:
    image: grafana/grafana:8.0.0
    ports:
      - "3000:3000"
EOF

sudo docker-compose up -d

# Instalar scapy para testes de Modbus
sudo pip3 install scapy

# Atualizar sistema

sudo apt update && sudo apt upgrade -y

# Instalar dependências

sudo apt install -y python3-pip docker.io docker-compose git

# Baixar OpenPLC

git clone https://github.com/thiagoralves/OpenPLC_v3.git /opt/openplc

cd /opt/openplc

# Rodar container OpenPLC (exemplo simplificado)

sudo docker-compose up -d

# Instalar InfluxDB e Grafana via Docker Compose (simplificado)

cat > docker-compose.yml <<EOF

version: '3'

services:

influxdb:

image: influxdb:2.0

ports:

- "8086:8086"

grafana:

image: grafana/grafana:8.0.0

ports:

- "3000:3000"

EOF

sudo docker-compose up -d

# Instalar scapy para testes de Modbus

sudo pip3 install scapy

Subtópico: Cenário prático obrigatório – passo a passo operacional

Objetivo: Simular descoberta e manipulação de registradores Modbus em um OpenPLC, validar detecção por Suricata e Zeek.
Preparação: Tenha três VMs: Target(OpenPLC, IP 10.10.10.10), HMI(10.10.10.20) e Attacker Kali(10.10.10.30). Garanta que SPAN/TAP captura tráfego entre Target e HMI.

Comandos no Attacker (Kali):

# Descoberta de hosts
nmap -sS -p 502 --open 10.10.10.0/24 -oG nmap_modbus.txt

# Identificar registradores Modbus com modbus-py scripts (exemplo)
python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); print(c.read_holding_registers(0,10))"

# Escrever valor para um registrador (simular alteração de setpoint)
python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); c.write_register(1,123); c.close()"

# Descoberta de hosts

nmap -sS -p 502 --open 10.10.10.0/24 -oG nmap_modbus.txt

# Identificar registradores Modbus com modbus-py scripts (exemplo)

python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); print(c.read_holding_registers(0,10))"

# Escrever valor para um registrador (simular alteração de setpoint)

python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); c.write_register(1,123); c.close()"

Validação (Blue Team): Em Zeek/Suricata, verifique alertas e PCAP:

# Verificar logs Suricata
sudo tail -n 200 /var/log/suricata/fast.log

# Buscar transações Modbus no Zeek logs
grep modbus /opt/zeek/logs/current/*

# Gerar pcap do tráfego Modbus
tcpdump -i eth0 port 502 -w modbus_test.pcap

# Verificar logs Suricata

sudo tail -n 200 /var/log/suricata/fast.log

# Buscar transações Modbus no Zeek logs

grep modbus /opt/zeek/logs/current/*

# Gerar pcap do tráfego Modbus

tcpdump -i eth0 port 502 -w modbus_test.pcap

Rollback: Restaure snapshot da VM Target ou reescreva registradores com valores seguros:

# Reverter registro para valor safe python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); c.write_register(1,0); c.close()"
1
2
3
# Reverter registro para valor safe
python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); c.write_register(1,0); c.close()"
Evidência: Arquive pcap, logs Suricata/Zeek, output do nmap, e arquivo de comando do attacker em um repositório git interno com hash e timestamp para auditoria.

Subtópico: Integração com SIEM e automação

Faça ingestão de logs do Zeek/Suricata e dos dispositivos (syslog, NetFlow) para seu SIEM (ELK/Opensearch/Splunk). Crie dashboards para telemetria e regras de correlação: por exemplo, um alerta para escrita Modbus combinada com autenticação falha na Engineering Workstation. Automatize snapshots antes de cada exercício para possibilitar rollback completo em caso de impacto.

Hardening, Controles e Melhores Práticas

Subtópico: Boas práticas de segregação de redes

Segregue redes OT e IT com firewalls de próxima geração, aplicando políticas específicas por zona. Para cada fluxo autorizado, defina proxies ou jump hosts e aplique inspeção profunda (DPI) customizada para protocolos ICS. Utilize listas brancas de comandos Modbus/IEC/APPLICATION logic and explicit allow-lists between HMI e PLC.

Subtópico: Gestão de identidades e acessos

Implemente gestão robusta de credenciais: use PKI/Certificados para OPC UA e SSH, aplique MFA em engineering workstations, e restringa contas privilegiadas por tempo e just-in-time access. Evite uso de contas genéricas; audite o uso de contas de serviço e rotacione credenciais de forma automatizada.

Subtópico: Hardening de dispositivos e atualizações

Implemente processo de validação de firmware em laboratório antes do deploy. Mantenha um catálogo com versões aprovadas, e utilize assinaturas digitais quando suportado pelo vendor. Para dispositivos que não suportam atualizações seguras, minimize exposição: remova serviços desnecessários, intercepte portas administrativas com jump hosts e aplique filtros de tráfego restritivo.

Subtópico: Monitoramento e detecção

Adote NTA (Network Traffic Analysis) com modelos comportamentais para protocolos ICS. Ferramentas como Zeek com scripts ICS, Suricata com regras customizadas, e sensores de fluxo (NetFlow/IPFIX) ajudam a detectar anomalias. Combine detecção por assinatura (ex: regras para CVE conhecidos) com detecção baseada em comportamento (deviations in command frequency, unusual register writes).

Subtópico: Backup, recuperação e continuidade

Tenha backups periódicos dos projetos de PLC, imagens de firmware e configurações do HMI. Teste procedimentos de recuperação em laboratório (restore de projects, reprogramming de PLC) e certifique-se de que backup não está comprometido. Planos de recuperação devem incluir steps para isolar equipamentos infectados e restore de lógica validada em sequência segura.

Subtópico: Segurança física

Proteja racks, portas de manutenção, e interfaces seriais/USB que podem ser vetor de ataque. Controle acesso físico via biometria/controle de chaves e registre logs de acesso. Em laboratórios híbridos, essa disciplina deve ser replicada para garantir que hardware não seja adulterado.

Playbooks Operacionais para Blue Team e Red Team

Subtópico: Playbook Red Team – Simulação de campanha

Um playbook Red Team profissional para laboratório deve incluir: objetivo, hipóteses, regras de engajamento, plano de ataque (fases), checklist de segurança, e critérios de sucesso. Exemplo de fases:

Fase 0 – Reconhecimento: Nmap, banner grabbing, fingerprint de PLC/HMI.
Fase 1 – Acesso Inicial: phishing simulado em estação de engenharia ou exploração de vulnerabilidade conhecida em servidor de armazenamento.
Fase 2 – Lateral Movement: credenciais encontradas, escalonamento via SMB/WinRM.
Fase 3 – Controle de PLC: uso de Modbus/S7 comms para alterar registradores.
Fase 4 – Evasão: limpeza de logs, modificação de registros de Historian.
Fase 5 – Efetividade: simulação de impacto físico controlado (ex: alterar setpoint) e retirada.

Subtópico: Checklist Red Team (resumido)

Escopo autorizado e horários definidos.
Snapshots e backups realizados antes do teste.
Planos de rollback prontos e testados.
Medições de segurança para evitar breakout (VLANs, firewall).
Registro detalhado de comandos, ferramentas e outputs.
Entrega de relatório com evidências e recomendações técnicas.

Subtópico: Playbook Blue Team – Detecção e resposta

Blue Team precisa de playbook claro com triagem, contenção, erradicação e lições aprendidas. Passos: triagem inicial com logs Zeek/Suricata, evidência (pcap/registradores), isolamento do equipamento afetado (VLAN shutdown), restore de snapshot/HMI, e análise forense. Fornecer runbooks para recuperação segura de PLC e revalidação de lógica é vital para reduzir downtime.

Subtópico: Checklist Blue Team (detalhado)

Detecção: alertas Zeek/Suricata, anomalias de Historian, autenticações anômalas.
Containment: isolar segmento, desabilitar portas e bloquear IPs maliciosos.
Eradicação: remover artefatos, re-flash firmware limpo quando necessário.
Recovery: restaurar lógica de PLC a partir de cópia segura e verificar integridade dos sensores/atuadores.
Lessons Learned: atualizar regras IDS/alertas e ajustar hardening.

Subtópico: Integração entre equipes

Exerça comunicação entre times (ops, segurança, engenharia) com playbooks integrados e uma cadeia de comando clara. Simulações periódicas em laboratório funcionam como “fire drills” para melhorar coordenação e reduzir tempo de resposta funcional (MTTR para processos industriais).

Métricas, KPIs e Auditoria Técnica

Subtópico: Métricas operacionais essenciais

Defina métricas alinhadas a objetivos de segurança OT. Exemplos práticos:

MTTD (Mean Time to Detect) para anomalias OT
MTTR (Mean Time to Recover) para restauração de lógica de PLC
Número de mudanças não autorizadas em registradores por mês
Percentual de ativos com firmware aprovado
Tempo médio de patch deployment para dispositivos aprovados

Subtópico: KPIs para validar eficácia do laboratório

KPIs ajudam a justificar investimento no laboratório. Exemplos:

Redução do tempo de detecção em exercícios (baseline vs pós-treinamento).
Percentual de cenários de ataque detectados em first-tier monitoring.
Tempo médio até rollback seguro (snapshots).
Redução de falsos positivos após tuning de regras IDS.

Subtópico: Auditoria técnica e evidências

Mantenha trilhas de auditoria: logs do hypervisor, snapshots, registros de alterações em PLCs (export projetos), e backups. Para cada exercício, gere um pacote de evidências: pcap, outputs de ferramentas, timeline de ações e um relatório técnico com recomendações. Isso é essencial para compliance com normas (IEC 62443) e auditorias internas.

Subtópico: Ferramentas para medição

SIEM (ELK/Opensearch/Splunk): correlação de eventos e dashboards.
Prometheus + Grafana: métricas de disponibilidade de serviços e latência de comunicação entre HMI e PLC.
Time-series DB (InfluxDB): registrar telemetria de sensores simulados para análise de anomalias.

Erros Comuns, Armadilhas e Correções

Subtópico: Armadilha 1 – Falta de isolamento

Muitos iniciantes criam labs onde a VM de ataque tem acesso à internet sem controle, o que pode resultar em fuga de malware. Correção: implemente NAT controlado e firewalls de laboratório, e use listas brancas de IPs para gestão de updates do hypervisor.

Subtópico: Armadilha 2 – Confundir emulação com fidelidade real

OpenPLC e outros emuladores são ótimos, mas não replicam quirks de firmware ou problemas eletromagnéticos. Correção: sempre que possível, valide teste crítico em hardware real ou em imagens de firmware do vendor em ambiente controlado.

Subtópico: Armadilha 3 – Testes sem autorização documentada

Mesmo em ambientes internos, executar ataques sem autorização pode resultar em consequências legais e operacionais. Correção: adote contratos de testes, aprovações formais e planos de rollback com responsáveis identificados.

Subtópico: Armadilha 4 – Overfitting das regras do IDS

Regras muito específicas reduzem falsos positivos, mas podem perder ataques variantes. Correção: combine regras por assinatura com modelos comportamentais; adote tunning contínuo e exercite com variantes de ataque no laboratório.

Subtópico: Armadilha 5 – Ignorar atualizações e CVEs

Falhar em acompanhar advisories de vendors e CVEs é comum. Correção: mantenha feed de advisories (CISA, vendor bulletins) integrado ao processo de validação em laboratório. Antes de aplicar patches, teste impacto funcional no lab.

FAQ Técnico para Busca Orgânica

Subtópico: Objetivo do FAQ

Esta seção responde perguntas que usuários reais buscam em motores de busca sobre construção de laboratórios para simulação de adversários em ICS, com foco em respostas objetivas e otimizadas para featured snippets.

P: O que é um laboratório ICS para simulação de adversários?

R: É um ambiente controlado que replica infraestrutura de controle industrial (PLCs, HMIs, Historian, gateways) para testar ataques, validar detecção e treinar resposta sem risco ao ambiente de produção.

P: Quais protocolos devo priorizar no laboratório?

R: Priorize Modbus/TCP, DNP3, IEC 61850, IEC 60870-5-104, PROFINET, EtherNet/IP e OPC UA, além de stacks proprietários do vendor que sua organização usa.

P: Devo usar hardware real ou emulação?

R: Comece com emulação (OpenPLC, SCADA open-source) para economia e rapidez, e integre hardware real quando precisar validar firmware, quirks físicos ou I/O reais.

P: Como isolo o laboratório para evitar riscos?

R: Use VLANs separadas, firewalls, restrição de saída para internet, snapshots/backup e um jump host para acessar segmentos sensíveis. Configure políticas de NAT e bloqueios de porta.

P: Quais ferramentas de detecção são mais úteis?

R: Zeek, Suricata com regras ICS, NTA (Network Traffic Analysis), SIEM (ELK/Splunk) com parsers para Modbus/IEC, e sensores de host quando aplicável.

P: É legal realizar testes de intrusão em ICS?

R: Sim, desde que haja autorização por escrito, escopo definido e medidas de segurança. Executar testes sem permissão pode provocar danos e implicar responsabilidade criminal e civil.

P: Quais métricas devo acompanhar?

R: MTTD, MTTR, número de mudanças não autorizadas, percentual de ativos corrigidos e tempo de deploy de patches aprovados.

P: Como documentar resultados de exercícios?

R: Gere pacotes de evidência (pcap, logs, outputs), timelines detalhadas, e relatórios técnicos com recomendações. Armazene em repositório controlado com hashes e timestamps.

P: Quais CVEs são relevantes em ICS?

R: Procure CVEs associados a stacks ICS de vendors específicos (Siemens, Schneider, Rockwell). Use fontes como NVD e vendors advisories. Atualize-se com feeds do CISA para emergentes.

P: Posso automatizar exercícios no laboratório?

R: Sim. Use Ansible, Terraform para infraestrutura, e scripts Python para execução de cenários. Automatizar snapshots e rollback é recomendável para segurança.

P: Que dados devo coletar para auditar um incidente simulado?

R: PCAP do tráfego relevante, logs de dispositivos e SIEM, cópia dos registradores do PLC, imagens de disco das VMs afetadas e registros de comandos do atacante.

P: Quais são boas fontes para aprender ICS security?

R: Repositórios e documentações oficiais: MITRE ATT&CK for ICS, IEC 62443, CISA advisories, Dragos blogs, e fornecedores como Siemens e Schneider que publicam bulletins técnicos.

Considerações Finais

Construir um laboratório para simulação de adversários em ICS é investimento em resiliência. Não se trata apenas de colocar equipamentos em uma sala, mas de criar um ciclo de aprendizado: replicar cenários reais, testar controles, medir eficácia e evoluir. A combinação de emulação rápida e hardware real dá balance entre custo e fidelidade; a segregação de rede e governança reduzem riscos; e playbooks claros garantem que o conhecimento obtido seja aplicado para reduzir risco operacional. No fim, a segurança industrial é uma disciplina que exige prática contínua, testes regulares e disposição para aprender com incidentes – passados e simulados.

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

MITRE ATT&CK for ICS – https://collaborate.mitre.org/attackics/index.php/Main_Page
IEC 62443 – International Society of Automation – https://www.isa.org/standards-and-publications/isa-62443
CISA – Cybersecurity and Infrastructure Security Agency – ICS Advisories – https://www.cisa.gov/ics
Dragos – Research and Reports – https://www.dragos.com/research/
OpenPLC Project – https://www.openplcproject.com/
Zeek (Bro) Network Security Monitor – https://zeek.org/
Suricata IDS – https://suricata-ids.org/
EVE-NG – Network Emulation – https://www.eve-ng.net/
Siemens ProductCERT Advisories – https://cert-portal.siemens.com/productcert/
Schneider Electric Security Advisories – https://www.se.com/ww/en/download/document/SEVD-
National Vulnerability Database (NVD) – https://nvd.nist.gov/
OWASP IoT Project – https://owasp.org/www-project-internet-of-things/

Tabela comparativa de abordagens para laboratório ICS

Abordagem	Risco	Custo Operacional	Esforço de Implementação	Maturidade/Realismo
Emulação 100% (OpenPLC, containers)	Baixo (isolamento fácil)	Baixo	Baixo-Médio	Médio
Hardware real (PLCs, I/O)	Médio-Alto (risco físico e elétrico)	Alto	Alto	Alto
Híbrido (emulação + PLC real)	Médio (melhor controle com maior realismo)	Médio	Médio-Alto	Alto
Cloud-based Lab (SaaS, simulators)	Médio (depende da gestão de dados)	Médio	Baixo-Médio	Médio
Testes em ambiente de produção controlado (canary)	Alto (riscos operacionais)	Alto	Alto	Máximo

Diagrama textual – Arquitetura de laboratório ICS (ASCII)


+----------------------+     +----------------------+    +----------------------+
|   Jump Host (IT)     |-----|  SIEM / ELK Backend  |----|  Portal de Gestão    |
|  (Admin access)      |     |  Zeek/Suricata logs  |    |  (tickets, playbook) |
+----------+-----------+     +----------+-----------+    +----------+-----------+
           |                            |
           |                            |
    VLAN: Engineering               VLAN: Management
           |                            |
+----------v-----------+     +----------v-----------+    +----------------------+
|  HMI / SCADA Server  |-----|     Switch OT        |----|  Historian / DB      |
|  (Ignition/ScadaBR)  |     |  (mirroring/SPAN)    |    |  InfluxDB/Grafana    |
+----------+-----------+     +----------+-----------+    +----------+-----------+
           |                            |
           |                            |
    VLAN: Control                    VLAN: Sensors
           |                            |
+----------v-----------+     +----------v-----------+    +----------------------+
|  PLC - Emulado (10.1)|-----|  PLC - Físico (10.2) |----|  Gateway IIoT (DMZ)  |
|  OpenPLC / Modbus    |     |  Siemens / Allen-Bradley |  |  Cloud ingestion     |
+----------------------+     +----------------------+    +----------------------+

+----------------------+ +----------------------+ +----------------------+

| Jump Host (IT) |-----| SIEM / ELK Backend |----| Portal de Gestão |

+----------+-----------+ +----------+-----------+ +----------+-----------+

| |

VLAN: Engineering VLAN: Management

| |

+----------v-----------+ +----------v-----------+ +----------------------+

| HMI / SCADA Server |-----| Switch OT |----| Historian / DB |

+----------+-----------+ +----------+-----------+ +----------+-----------+

| |

VLAN: Control VLAN: Sensors

| |

+----------v-----------+ +----------v-----------+ +----------------------+

| PLC - Emulado (10.1)|-----| PLC - Físico (10.2) |----| Gateway IIoT (DMZ) |

+----------------------+ +----------------------+ +----------------------+

Cenário prático obrigatório – passo a passo operacional (detalhado)

Preparar infra: Configure um host ESXi/Proxmox com imagens: Kali (attacker), Ubuntu (OpenPLC), Windows 10 (HMI), SIEM (ELK), Sensor (Zeek). Crie VLANs separadas para Engenharia, Controle, e DMZ.
Snapshot: Antes de iniciar qualquer exercício, tire snapshots das VMs alvo (OpenPLC e HMI). Documente hash e timestamp.
Reconhecimento:

# No Kali nmap -sS -p 502,44818,47808,4840 10.10.10.0/24 -oN scan_initial.txt
1
2
3
# No Kali
nmap -sS -p 502,44818,47808,4840 10.10.10.0/24 -oN scan_initial.txt

Validação: confirme no SIEM que o log de varredura foi coletado.
Exploração (não destruiva):

# Leitura de registradores python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); print(c.read_holding_registers(0,10)); c.close()"
1
2
3
# Leitura de registradores
python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); print(c.read_holding_registers(0,10)); c.close()"

Validação: Zeek registra sessão Modbus; Suricata gera alerta Modbus read.
Manipulação controlada: Escreva um novo valor em registrador simulado e monitore reação do HMI.

# Escrever valor python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); c.write_register(1,999); c.close()"
1
2
3
# Escrever valor
python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); c.write_register(1,999); c.close()"

Validação: Grafana mostra alteração; SIEM registra operação escrita.
Rollback: Reestabeleça registrador original:

# Reverter registro python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); c.write_register(1,0); c.close()"
1
2
3
# Reverter registro
python3 -c "from pymodbus.client.sync import ModbusTcpClient; c=ModbusTcpClient('10.10.10.10'); c.connect(); c.write_register(1,0); c.close()"

Validação: Grafana mostra retorno ao estado seguro; verifique integridade dos processos simulados.
Evidências e Relatório: Salve pcap, logs Suricata/Zeek, outputs nmap e scripts usados. Gere relatório com timeline, ferramentas usadas, e recomendações de detecção/hardening.

Checklist Blue Team

Receber notificação de exercício e validar escopo.
Garantir snapshots e backups antes do exercício.
Monitorar alerts Zeek/Suricata para tráfego Modbus/DNP3.
Isolar segmento caso detecção indique alteração de registradores críticos.
Executar rollback automático se condição de segurança for violada.
Registrar timeline e coletar pcap para forense.
Ajustar regras IDS/alertas após exercício.

Checklist Red Team

Obter autorização por escrito com escopo e tempo.
Validar snapshots e identificar responsável de rollback.
Evitar ações que possam danificar fisicamente hardware.
Documentar cada comando, output e evidência.
Encerrar exercício no horário acordado e notificar Blue Team.
Entregar relatório técnico com evidências hashadas.

Recursos Visuais Sugeridos

MITRE ATT&CK for ICS matrix (diagramas e técnicas) – https://collaborate.mitre.org/attackics/
CISA ICS Advisory portal (diagramas e playbooks) – https://www.cisa.gov/ics
OpenPLC documentation and architecture diagrams – https://www.openplcproject.com/documentation
EVE-NG topology examples – https://www.eve-ng.net/index.php/documentation/
Zeek ICS scripts and visualizations – https://github.com/zeek/zeek/tree/master/scripts/policy/protocols
Suricata ruleset for ICS (Emerging Threats) – https://rules.emergingthreats.net/
IEC 62443 overview and diagrams – https://www.isa.org/standards-and-publications/isa-62443
Guides on Modbus and protocol diagrams (Wireshark dissectors) – https://www.wireshark.org/docs/