Modelagem de Ameaças em Indústrias de Processo

Introdução: As refinarias e indústrias de processo representam ativos críticos com impacto direto sobre a economia, segurança pública e meio ambiente. Historicamente alvo de adversários financeiros, hacktivistas e operadores estatais, esses ambientes combinam tecnologia de informação (IT) e tecnologia operacional (OT) com protocolos legados, equipamentos proprietários e requisitos de disponibilidade em tempo real. Neste artigo você encontrará um compêndio técnico – com fundamentos conceituais, mapeamento de superfície de ataque, estudos de caso reais, passos práticos para implementar modelagem de ameaças, playbooks operacionais, métricas e checklists para Blue Team e Red Team – tudo orientado para uso aplicável em refinarias e indústrias de processo. O objetivo é que, ao final, você seja capaz de planejar, executar e validar uma modelagem de ameaças que gere controles priorizados, mensuráveis e alinhados às normas ISA/IEC 62443, NIST-CSF e MITRE ATT&CK for ICS.

Contexto Atual e Relevância Estratégica

As indústrias de processo – refinarias, petroquímica, papel e celulose, siderurgia, fertilizantes, e geração de energia – têm se tornado alvos sistemáticos por uma combinação de motivos: alto impacto potencial, presença de interfaces digitais expostas, automação crítica e dependência de cadeias logísticas integradas. Vulnerabilidades em controladores lógicos programáveis (PLCs), sistemas SCADA, sistemas de controle distribuído (DCS) e gateways IIoT podem resultar em paralisações industriais, vazamentos de substâncias perigosas, contaminação ambiental e perdas financeiras significativas. Para executivos e operadores, o valor da modelagem de ameaças está em transformar cenários de risco abstratos em priorizações concretas para investimentos TCO (Total Cost of Ownership) e redução de risco operacional.

Panorama de risco recente: A convergência IT/OT trouxe visibilidade e eficiência, mas também expôs ativos OT a vetores explorados em IT: phishing que conquista credenciais, cadeias de fornecedores comprometidas, software de gestão em nuvem mal configurado e acessos remotos fracos. Mesmo que exemplos de impacto massivo mais recentes com divulgação pública datem de anos anteriores (por exemplo, incidentes que elevaram a conscientização em 2021), o padrão de incidentes e as técnicas evoluíram até 2024 e continuam em transformação em 2025/2026. Para 2026, as observações do mercado mostram aumento na automatização de ataques por ransomware especializados em OT e exploração de dispositivos IIoT com bibliotecas de firmware vulneráveis.

Impacto ao negócio: Ao contrário de sistemas puramente IT, indisponibilidade em OT normalmente custa não apenas dinheiro, mas riscos à segurança humana e ao meio ambiente. Uma parada na linha de produção de uma refinaria por 24 horas pode representar milhões em perdas diretas, além de multas regulatórias e danos reputacionais. A modelagem de ameaças permite relacionar ativos críticos a métricas de negócio: perda de produção por hora, exposição regulatória, criticidade ambiental e dependência de fornecedores externos. Sem esta camada de tradução, decisões de segurança se tornam baseadas em percepções e não em risco real.

Por que agora: A adoção acelerada de arquiteturas híbridas (edge computing, IIoT, cloud-assisted control), as pressões por manutenção preditiva baseada em dados e as integrações de terceiros aumentam a superfície de ataque. Regulamentações e frameworks (ISA/IEC 62443, NERC CIP, NIST) estão exigindo controles mais explícitos para 2025-2026. Organizações que começarem a modelar ameaças hoje – com foco alinhado a critérios de negócio e operacionais – reduzirão exposição, priorizarão investimentos e melhorarão capacidade de resposta.

O que você aprenderá: Como escolher e aplicar metodologias (STRIDE, PASTA, Attack Trees, MITRE ATT&CK mapping), mapear ativos e fluxos de dados, construir DFDs adaptados a OT, identificar vetores críticos (exposição remota, supply chain, insiders), implementar contadores e hardening, e criar playbooks acionáveis para Blue Teams e Red Teams. Também entrego templates de execução, comandos para reconhecimento em ambientes segurançados de laboratório e checklists detalhados para auditoria e validação.

Fundamentos Técnicos do Tema

A modelagem de ameaças (threat modeling) é tanto uma disciplina analítica quanto um processo colaborativo, que transforma arquitetura e fluxo de dados em hipóteses de ataque e controles. No contexto de refinarias e indústrias de processo, alguns fundamentos técnicos precisam ser internalizados antes de iniciar: distinção entre IT e OT, características de disponibilidade e segurança funcional, protocolos industriais, e a importância de dados operacionais e telemetria em tempo real.

Princípios básicos: Modelagem de ameaças articula quatro pilares: (1) identificação de ativos e limites (assets and trust boundaries); (2) modelagem de fluxos de dados e de controle; (3) geração de hipóteses de ameaça e cenários de ataque; (4) priorização baseada em impacto e probabilidade. Para indústrias de processo, acrescente: estados de falha segura (safe-state), sequências de intertravamento, modos de degradação e requisitos regulatórios de segurança funcional (ex.: SIL).

Metodologias aplicáveis: As metodologias mais utilizadas e adaptáveis a OT incluem:

• STRIDE: útil para exercer identificação sistemática de ameaças em cada elemento do DFD (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Em OT, ‘Denial of Service’ e ‘Tampering’ são especialmente críticos por afetarem disponibilidade e integridade de comandos.
• PASTA (Process for Attack Simulation and Threat Analysis): abordagem orientada a riscos e atores, boa para mapear motivações (financeira, sabotagem, espionagem), vetores e impacto em negócio; exige dados de ameaça e modelagem de atacantes (threat actors).
• Attack Trees: permitem decompor um objetivo do atacante (ex.: parada de linha) em subobjetivos e controles mitigantes; fácil de integrar com critérios de custo/complexidade.
• MITRE ATT&CK for ICS: matriz de técnicas e táticas específicas para ambientes industriais, excelente para criar detecções e playbooks.

Especificidades OT vs IT: Há diferenças cruciais:

• Retardo e determinismo: comandos em DCS/PLC são sensíveis a latência; mitigação que introduz jitter pode ser inaceitável.
• Protocolos legados: Modbus/TCP, DNP3, OPC Classic usam autenticação fraca ou inexistente; atualizações de firmware são raras.
• Patch management restrito: janelas de parada para aplicar patches são limitadas, exigindo compensações e controles compensatórios.
• Segurança funcional e SIL: controles de segurança devem preservar invariantes seguros; uma mitigação deve garantir que a segurança funcional não seja degradada.

Ativos típicos e sensores críticos: PLCs, RTUs, IEDs, HMI, DCS, historians, gateways protocolares, dispositivos de segurança industrial (SIS), roteadores industriais, servidores de engenharia, sistemas MES/ERP integrados. A modelagem deve priorizar ativos cujo comprometimento cause alteração física: válvulas, motores, bombas, queimadores.

Fluxos de dados e trust boundaries: No design da modelagem, delimite zonas: Enterprise IT, DMZ, OT Corporate (MES), Process Control Zone, Safety Instrumented Zone, Field Devices. Cada fronteira tem diferentes requisitos de autenticação, monitoramento e resposta.

Detecção e telemetria: Telemetria OT (tags Modbus/DNP3/OPC UA), logs de historians, pacotes de rede em tempo real, integridade de firmware e hashes de configuração são dados primordiais para modelagem de ameaça operacional. Um plano sem instrumentação para coletar esses dados torna qualquer priorização frágil.

Ameaças típicas: ataques de ransomware que criptografam servidores MES e bilhetes de engenharia; manipulação de setpoints via sessões legítimas; supply chain com firmware malicioso; exploração de VPNs mal configuradas; ataques internos (insider/terceiros) com credenciais válidas. Ao modelar, defina atores (script kiddies, criminosos financeiros, operadores de estado) e capacidades (sophistication, persistence, access vector).

Mapeamento a frameworks: Use ISA/IEC 62443 para controle técnico e de processo; NIST-SP800-82 para recomendações específicas; MITRE ATT&CK for ICS para enumerar técnicas. Esse alinhamento garante que a modelagem gere entregáveis auditáveis e rastreáveis para compliance e investimento.

Resultados esperados: Um threat model bem elaborado entrega (1) uma lista priorizada de cenários com métricas de impacto e probabilidade; (2) recomendações de controles mitigantes com custo, prazo e dependências; (3) requisitos de detecção específicos (ex.: assinatura Modbus anômalo, sequência incomum de writes para setpoint); (4) playbooks de resposta ligados a KPIs operacionais.

Arquitetura, Fluxos e Superfície de Ataque

Refinarias e plantas de processo têm arquiteturas heterogêneas. A superfície de ataque é vasta e inclui interfaces remotas, provedores de manutenção remota, dispositivos IIoT, gateways de protocolação e integrações de OT-IT. Aqui descreveremos a arquitetura típica, como modelar fluxos de dados e onde concentram-se os vetores de ataque mais críticos.

Arquitetura típica por zonas: Uma arquitetura padronizada facilita a modelagem. Um modelo comum inclui:

• Enterprise Zone – sistemas corporativos, ERP, e-mail, equipes de TI.
• Perimeter/DMZ – jump servers, data historians expostos à enterprise, servidores de atualização.
• Operations/Control Zone – servidores MES, SCADA, HMI, engineering workstations.
• Process Control Zone – DCS, PLCs, RTUs, I/O racks.
• Safety Instrumented Systems (SIS) – sistemas independentes para intertravamentos de segurança.
• Field Devices – sensores, transmissores, atuadores, válvulas controladas.

Fluxos de dados críticos: Fluxos frequentes incluem: comandos de controle (setpoints) do HMI para PLC; telemetria de sensores para historian; atualizações de configuração de engineering workstation para PLC; dados de manutenção remota para gateways de fornecedor; integração de MES com ERP para ordens de produção. Cada fluxo tem propriedades de confidencialidade, integridade e disponibilidade que afetam o modo de priorização.

Superfície de ataque por vetor:

• Exposição remota e VPNs – acesso remoto não segmentado é um vetor recorrente: credenciais roubadas permitem acesso direto ao engineering workstation.
• Supply chain e manutenção terceirizada – contas e ferramentas de terceiros com acesso a redes OT frequentemente não submetidas a testes de segurança equivalentes.
• Protocolos não autenticados – Modbus sem autenticação, OPC Classic sem criptografia, DNP3 com autenticação obsoleta.
• Firmware/patching – imagens de firmware não verificadas e atualizações fora de ciclo.
• Interfaces de engenharia – engenharia workstations com ferramentas como TIA Portal, RSLogix, ou Vijeo acessíveis com privilégios elevados.
• Dispositivos IIoT – sensores com credenciais padrão e firmware vulnerável.

Mapeamento de ativos para risco: Para priorizar, construa tabelas que correlacionem o ativo com impacto (produção, segurança, ambiental), superfície de ataque, facilidade de exploração e controles existentes. Essa matrix suporta decisões econômicas e operacionais.

Exemplo técnico de identificação de fluxo: Em um fluxo típico HMI -> Historian -> MES, considere pontos de injeção: falsificação de dados no Historian (tampering), replay de dados para ocultar ações (repudiation), manipulação de setpoint via HMI (tampering/elevation) e interrupção de telemetria (DoS). Para cada ponto, liste evidências que você consegue coletar (PCAP de rede, logs do historian, timestamps anômalos) e regras de detecção possíveis (ex.: sequência de writes para variável crítica > X por minuto).

Assets com criticidade alta:

• Controladores de segurança (SIS) – qualquer alteração indevida pode romper invariantes de segurança.
• Gateways de interconexão – convertendo OPC/Modbus e provendo acesso a engineering tools.
• Historian – fonte de dados operacionais e base para decisões automatizadas.
• Engineering Workstations – residem as ferramentas de programação e templates de configuracão (PLC logic).

Vetores emergentes (2024-2026): Com o aumento de arquiteturas edge/cloud, vetores como APIs de gerenciamento em nuvem, integrações via MQTT, e orquestração baseada em Kubernetes para aplicações de operação começam a aparecer como novos pontos de risco. Mapear cada integração externa como um boundary com requisitos de autenticação, autorização e monitoramento é obrigatório.

Exposição física vs remota: Em plantas onde dispositivos fornecem acesso local físico, a ameaça de insider e de acesso por visitantes com dispositivos USB prevalece. Em contraste, conexões remotas sem controle de privilégio aumentam risco de comprometer toda a zone. A modelagem precisa registrar ambos como modos complementares de ataque.

Instrumentação de detecção: Para cada fluxo de dados crítico, defina quais sinais de telemetria são necessários: tags Modbus com frequências esperadas, hashes de firmware, logs de sessão de engenharia, check-ins periódicos do asset inventory. Sem isso, a modelagem é prescritiva mas não verificável.

Cenários Reais e Estudos de Caso

Estudos de caso ajudam a transformar teoria em aprendizado prático. Abaixo discutimos incidentes conhecidos que influenciaram práticas de modelagem e controles para indústrias de processo.

Caso Colonial Pipeline (maio de 2021) – contexto e aprendizados: Embora o incidente tenha afetado um oleoduto e não uma refinaria diretamente, suas implicações para infraestrutura crítica e supply chain são valiosas. O ataque ransomware interrompeu operações críticas, expondo fragilidades em acesso remoto e segmentação entre sistemas administrativos e operacionais. O aprendizado imediato: concessão de privilégios mínimos, rotinas de resposta e segregação de redes são fundamentais. Além disso, destacou-se a necessidade de playbooks e preparação para continuidade de negócios.

Caso Oldsmar Water Treatment (fevereiro de 2021) – manipulação direta de processos: Um atacante obteve acesso remoto a um sistema de controle do tratamento de água e alterou doses de hidróxido de sódio remotamente. Aqui, o vetor envolveu dispositivos de suporte remoto e credenciais insuficientes. Aprendizado: validar comandos críticos com dupla verificação humana, autenticação forte para fornecedores, e monitoramento de anomalias nos valores de processo.

Norsk Hydro (2019) – impacto operacional em ambientes industriais: O ataque de ransomware que afetou Norsk Hydro resultou em longas interrupções e recuperação complexa. Embora não seja em refinarias, o caso ilustra como falhas em backups e na segmentação podem elevar custos e tempo de recuperação.

Casos específicos a refinarias e plantas de processo:

• Incidentes de sabotagem e espionagem industrial: Relatórios de fornecedores e órgãos de inteligência pública documentaram tentativas de manipulação de setpoints e exfiltração de propriedade intelectual. Esses casos mostram a importância da prevenção contra acesso remoto não-autorizado e do monitoramento de configurações de PLC.
• Ransomware direcionado a MES/Historian: Ataques que cifram sistemas de suporte de produção impedem visibilidade operacional e podem forçar paradas manuais. A defesa passa por backups imutáveis, segmentação e planos de recuperação específicos para OT.

Estudos de caso de 2024-2026 – tendências: Relatórios de segurança de fornecedores e empresas de resposta a incidentes até 2024 indicaram crescimento em campanhas que combinam phishing para comprometer credenciais com pivot para ambientes OT. Em 2025 e 2026, observou-se uma tendência de exploração de dispositivos IIoT com gerenciamento em nuvem mal configurado. Por razões de segurança factual e transparência, recomenda-se que equipes consultem advisory feeds de CISA, Dragos, e vendors para detalhes de indicadores de compromisso (IOCs) atualizados.

Análise técnica de um cenário de ataque realista:

Objetivo do atacante: interromper a unidade de craqueamento para forçar parada de produção e extorsão.

Vetor inicial: comprometimento de credenciais via phishing de um operador de ordens de manutenção.

Movimentação lateral: uso de ferramentas administrativas legítimas para acessar engineering workstation e descarregar lógica de PLC.

Execução: alteração de tempo de abertura de válvulas e setpoints de fluxo em sequências que induzem instabilidade de processo.

Detecção e falha: ausência de checagem de integridade de lógica; logs do historian sobrescritos ou indisponíveis; procedimentos de reação manuais lentos.

Lições: controle de acesso privilegiado para engineering tools, proteção de segredos, registros imutáveis de alteração (WORM storage), segmentação forte entre engineering e control zones, e validação automática de plausibilidade de setpoints antes de aceitação por PLCs.

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

Esta seção apresenta um processo reproduzível para realizar modelagem de ameaças em refinarias e indústrias de processo, com atividades concretas, artefatos, ferramentas e comandos de laboratório (Kali Linux/Parrot) para reconhecimento seguro em ambientes de teste ou autorizados.

Visão geral do processo:

1. Preparação e alinhamento: escopo, autorização, stakeholders (Tecnologia, Operações, Engenharia, Segurança, Legal).
2. Inventário de ativos: discovery ativo/passivo e catálogo de criticidade.
3. Mapeamento de fluxos: criação de DFDs e zoneamento (segurança física incluída).
4. Identificação de ameaças: aplicação de STRIDE/PASTA/Attack Trees + mapeamento a MITRE ATT&CK ICS.
5. Análise de impacto e probabilidade: métricas de negócio e técnicas (CVSS não é suficiente para OT).
6. Priorização e definição de mitigantes: controles técnicos, processuais e organizacionais.
7. Plano de detecção e resposta: indicadores, regras SIEM/SOAR, playbooks e exercícios.
8. Validação e monitoramento contínuo: testes de penetração, purple team e auditorias periódicas.

Passo 1 – Escopo e autorização:

Subtópico: Reúna as partes interessadas e obtenha autorizações formais para varreduras e testes. Documente limites do escopo, horários de janela (maintenance window), critérios de rollback, plano de comunicação de emergência, e contatos de engenharia para intervenção rápida. Sem autorizacão, qualquer ação é ilegal e perigosa.

Passo 2 – Inventário de ativos:

Subtópico: Faça discovery seguro; prefira varreduras passivas e inventário por agente quando possível. Em labs autorizados, execute varreduras ativas com ferramentas. Exemplo de comandos de reconhecimento (Kali Linux):

Validação e limitações: Em produção, varreduras ativas podem interromper dispositivos. Consulte engenharia e use janelas de teste. Sempre tenha plano de rollback e backups de configuração do PLC.

Passo 3 – Mapeamento de fluxos e DFD:

Subtópico: Documente fluxos de controle e dados: HMI -> Historian, MES -> DCS, VPN fornecedor -> Gateway remoto. Para cada fluxo, registre protocolo, portas, taxa de dados, requisitos de SLA, e pontos de controle possíveis. Use diagramas lógicos e físicos; inclua latências aceitáveis e estados seguros.

Passo 4 – Identificação de ameaças:

Subtópico: Aplique STRIDE sobre cada elemento do DFD e gere cenários por PASTA. Combine com técnica adversarial: mapeie potencial atacante, motivação, capacidades e TTPs (tácticas, técnicas e procedimentos). Use MITRE ATT&CK for ICS para referenciar técnicas por ID e criar regras de detecção.

Passo 5 – Análise de impacto e probabilidade:

Subtópico: Estime impacto financeiro (perda/hora), impacto em segurança humana, e impacto ambiental. Estime probabilidade pela exposição (internet-facing services, fornecedores, credenciais fracas) e por facilidade de exploração (existência de exploit público, necessidade de acesso físico). Resultado: score de priorização.

Passo 6 – Seleção e implementação de mitigantes:

Subtópico: Para cada cenário priorizado, defina controles: segmentação, firewalls industriais, jump servers com MFA, hardening de engineering workstations, whitelisting de comandos para PLC, validação de integridade de firmware, e monitoramento de tags críticos. Descreva custo, prazo e impacto operacional. Inclua justificativa técnica e acordo com engenharia sobre testes em produção.

Passo 7 – Plano de detecção e resposta:

Subtópico: Construa regras SIEM com amostras específicas de telemetria OT (ex.: writes em sequência para setpoint críticos, firmware update fora de janela, conexões RDP iniciadas por IP externo). Produza playbooks SOAR para isolamento de VLAN, bloqueio de credenciais, e requisições de rollback de PLC com verificação humana.

Passo 8 – Validação e recorrência:

Subtópico: Realize exercícios Purple Team (Blue + Red) com escopo controlado para validar detecções; faça pen-tests OT em ambientes de teste; execute análises pós-ação após cada incidente e ajuste o threat model. Agende revisões do threat model semestrais ou sempre que houver mudança arquitetural relevante.

Cenário prático passo a passo (execução autorizada de avaliação em ambiente-lab):

1. Planejamento e autorização: obtenha autorização assinada e janelas de teste.
2. Configuração do ambiente isolado: clone da rede OT em um lab com equipamentos similares (PLC, HMI, historian).
3. Reconhecimento: executar comandos nmap/snmpwalk e capturas
4. Exploração controlada: simular injeção de setpoints com modpoll em um PLC de laboratório
5. Verificação de detecção: validar regras SIEM que disparem com a atividade
6. Rollback: restaurar firmware/config do PLC e registrar evidências

Comandos de exemplo para execução controlada (modbus/modpoll):

Rollback e evidências: Sempre documente hora, comando, operador, e backup. Para rollback, restaure a configuração do PLC usando cópia verificada ou snapshot do historian. Armazene logs e PCAPs em storage WORM para preservação de evidência.

Hardening, Controles e Melhores Práticas

Hardening em ambientes de processo precisa equilibrar segurança e disponibilidade. Abaixo, recomendações práticas testadas e alinhadas a frameworks e melhores práticas do setor.

1. Segmentação e microsegmentação:

Subtópico: Separe redes IT e OT fisicamente ou logicamente. Aplique zonas e conduítes de confiança, com regras de firewall industriais que implementem políticas de mínimo privilégio. Considere microsegmentação para tarefas críticas, usando firewalls industriais e switches com ACLs para limitar fluxos entre dispositivos específicos.

2. Controle de acesso privilegiado:

Subtópico: Use gerenciamento de privilégios para engineering workstations e contas de serviço. Implemente PIM (Privileged Identity Management), MFA para acesso remoto e just-in-time access para fornecedores. Registre todas ações de contas privilegiadas com trilhas de auditoria.

3. Hardening de engineering workstations:

• Aplicar whitelisting de aplicações (aplicações de engenharia autorizadas).
• Remover conexões desnecessárias à internet.
• Harden do sistema operacional: desativar serviços não usados, configurar EDR compatível com OT.

4. Patching e gestão de firmware:

Subtópico: Entenda o ciclo de vida dos dispositivos. Defina janelas de manutenção, test bench para patches, e processos de verificação de assinaturas de firmware. Para dispositivos sem suporte, use controles compensatórios (isolation, compensating monitoring).

5. Monitoramento e detecção:

Subtópico: Colete telemetria OT granular: tags, comandos de escrita, firmware checksums, logs de engineering tools. Use ferramentas que compreendam protocol stack industrial (Deep Packet Inspection para Modbus, DNP3, IEC 61850). Defina regras de baseline e anomalia com thresholds específicos de processo, não apenas heurísticos IT.

6. Hardening de protocolos:

Subtópico: Migre para protocolos seguros quando possível (OPC UA com TLS). Para legacy protocols (Modbus, DNP3), encapsule com gateways que ofereçam autenticação, validação e rate-limiting.

7. Backup e recuperação específica para OT:

Subtópico: Backups de lógica PLC, snapshots de configuration e políticas de recuperação testadas. Use storage WORM para preservar cópias imutáveis de configurações críticas. Teste recovery frequentemente em ambiente de laboratório.

8. Continuidade operacional e planos de contingência:

Subtópico: Planeje fallback manual seguro e sequências de shutdown seguras. Treine operadores para execução sob perda de automação e valide planos sob simulações.

9. Gestão de fornecedores e supply chain:

Subtópico: Aplique requisitos de segurança em contratos com fornecedores, verifique assinaturas de firmware, realize avaliações de segurança e exigência de logs de acesso por parte de terceiros. Monitore conexões remotas de fornecedores em tempo real.

10. Proteção física e controles ambientais:

Subtópico: Controle físico de racks, acesso a salas de controle e proteção contra dispositivos de inserção USB. Use inventário físico e checagens regulares para detectar hardware não autorizado.

Ferramentas e vendors recomendados:

• Solvers de segmentação industrial e firewalls (ex.: Palo Alto, Fortinet com módulos OT, Claroty, Nozomi, Dragos).
• SIEM com parser OT e integração de protocolo (ex.: Splunk Enterprise Security com apps industriais).
• Soluções de PAM/PIM (CyberArk, BeyondTrust).
• Ferramentas de detecção de anomalia de rede OT (Nozomi, Claroty, Dragos).

Medições e validações de hardening:

Use verificações automatizadas (SCAP-like) adaptadas para OT, auditorias de configuração, e testes de penetração controlados. A validação técnica inclui testes de resiliência à latência, integridade de comando e fail-safe behavior.

Playbooks Operacionais para Blue Team e Red Team

Playbooks convertem deteções em ações repetíveis. Abaixo, playbooks concisos para Blue Team (detecção e resposta) e para Red Team (avaliação autorizada). Ambos devem ser executados sob governança e com autorização formal.

Playbook Blue Team – Detecção e Resposta:

• Alerta: regra SIEM disparada: múltiplos writes em setpoint crítico fora de janela.
• Validação: Confirmar logs do historian e PCAP do tráfego Modbus/OPC (validar endereço de origem, sequência de comandos).
• Conteção: Isolar host de origem na ACL do switch/segmentation firewall, aplicar bloqueio temporário ao user account no PAM.
• Mitigação: Reverter setpoints via snapshot de configuração verificado; ajustar intertravamento manual se necessário.
• Eradicação: Se host comprometido: remover engenharia workstation do segmento, realizar forensic, reformat se necessário.
• Recuperação: Restaurar operação normal com testes em estágio controlado; re-atualizar controles compensatórios.
• Lessons Learned: atualizar threat model, ajustar regras SIEM, revisar janelas de manutenção e acesso de fornecedores.

Playbook Red Team – Avaliação Autorizada:

• Escopo e autorização: documento assinado com escopo claro, horas e rollback.
• Reconhecimento passivo: coletar telemetria, enumerar serviços e versões; evitar impactos.
• Reconhecimento ativo controlado: varreduras limitadas: nmap com timing seguro; validar com equipe de engenharia antes.
• Exploração de baixa amplitude (lab): em lab autorizado, demonstrar manipulação de setpoints e impacto.
• Pivot controlado: demonstrar lateral movement teórico e probabilidade de sucesso com artefatos e logs.
• Relatório: evidências, recomendações priorizadas e PoC em ambiente de laboratório; lista de IOCs.

Exemplo técnico de playbook SIEM (detecção Modbus anômalo):

• Regra: disparo quando exista > 3 writes em registradores críticos em intervalo de 60s por mesmo cliente.
• Contexto: correlacionar com sessão RDP iniciada da periferia ou com login de fornecedor.
• Ação automática (SOAR): criar ticket, isolar porta do switch, bloquear IP no firewall industrial.
• Notificação: alertar on-call OT e equipe de engenharia via SMS e canal de emergência.

Métricas, KPIs e Auditoria Técnica

Métricas bem definidas tornam a modelagem de ameaças acionável. Sem métricas, recomendações ficam no vácuo. Abaixo, conjuntos de KPIs técnicos e de negócio e exemplos de auditorias técnicas.

KPIs operacionais e de segurança:

• Tempo Médio para Detecção (MTTD) específico OT – objetivo: reduzir para X minutos (definir baseado em criticidade).
• Tempo Médio para Resposta (MTTR) – ligado a playbooks OT verificáveis.
• Percentual de ativos com backup de configuração recente e verificada – meta > 95% para ativos críticos.
• Quantidade de acessos privilegiados just-in-time versus permanente.
• Taxa de patch aplicada dentro da janela planejada – diferenciar patches críticos de OT.
• Detecções por técnicas MITRE ATT&CK ICS cobertas por regra – medir cobertura percentual.
• Tempo de recuperação do processo (hours) em caso de falha – alinhado ao SLA operacional.

Métricas de maturidade:

• Score de maturidade baseado em controles ISA/IEC 62443 (avaliado por auditoria técnica).
• Porcentagem de sistemas de controle com EDR/monitor OT ativos.
• Frequência e resultados de exercícios Purple Team e pen-tests OT.

Auditoria técnica – checklist mínimo:

• Inventário completo de ativos com versões e fornecedores.
• Baseline de tráfego e regras de firewall revisadas.
• Validação de backups e testes de restauração para PLCs e HMI.
• Verificação de whitelisting de aplicativos e políticas de change management.
• Verificação de contratos de fornecedores com cláusulas de segurança e logs de acesso.

Métricas para priorização de mitigantes:

Use métricas combinadas: Impacto por hora de parada x Probabilidade de sucesso do ataque = Risco residual. Incorpore custo de mitigação para calcular ROI de controles. Expresse em termos que o board entenda: redução de X% do risco por investimento Y.

Erros Comuns, Armadilhas e Correções

Organizações frequentemente repetem erros que ampliam risco em ambientes de processo. Abaixo, as armadilhas mais recorrentes e correções práticas.

Erro 1: Tratar OT como IT:

Correção: Entender requisitos de disponibilidade e segurança funcional; testar mitigantes quanto a latência e comportamento determinístico; envolver engenharia desde o início de qualquer mudança.

Erro 2: Falta de autorizações e janelas de teste:

Correção: Crie processos de autorização formal, use ambientes de sandbox e test benches, não execute varreduras invasivas sem consentimento.

Erro 3: Confiar em perímetro lógico único:

Correção: Implementar múltiplas camadas de defesa: segmentação, whitelisting, controles de serviço e checagens de integridade.

Erro 4: Ignorar fornecedores e supply chain:

Correção: Impor requisitos contratuais de segurança, autenticação forte para conexões remotas, e auditorias periódicas de fornecedores críticos.

Erro 5: Falta de telemetria adequada:

Correção: Defina KPIs de telemetria; implemente coleta de tags críticos, PCAP de eventos, e registros de engineering tools; armazene evidências em formato imutável.

Erro 6: Uso indiscriminado de conectividade remota:

Correção: Use jump servers com PIM e MFA, acesso just-in-time, e monitoramento contínuo; audite sessões remotas com replay e captura.

Erro 7: Implementar mudanças rápidas sem testes de integridade:

Correção: Estabeleça processo de change control com validação de lógica antes e depois, e rollback testado.

FAQ Técnico para Busca Orgânica

Esta seção responde a perguntas reais que engenheiros e profissionais de segurança pesquisam, com respostas objetivas e desenhadas para featured snippets.

1. O que é modelagem de ameaças em OT?

Modelagem de ameaças em OT é o processo de identificar ativos críticos, mapear fluxos de dados e controle, gerar cenários de ataque e priorizar mitigantes com base em impacto operacional, segurança humana e probabilidades de exploração.

2. Quais metodologias usar para indústrias de processo?

STRIDE para checagem sistemática, PASTA para análise orientada ao negócio, Attack Trees para decomposição de objetivos, e mapeamento com MITRE ATT&CK for ICS para definir detecções e playbooks.

3. Quais protocolos precisam de atenção especial?

Modbus/TCP, DNP3, OPC Classic/DA, IEC 61850, PROFINET e Ethernet/IP. Priorize a migração para protocolos seguros (OPC UA/TLS) quando possível e aplique gateways que ofereçam autenticação e validação para legacy.

4. Como testar sem interromper a produção?

Use ambientes de laboratório (test bench), varreduras passivas, janelas de manutenção autorizadas, e simulações com digital twins. Se necessário executar testes ativos, coordene com engineering e tenha rollback imediato preparado.

5. O que incluir em um playbook de resposta OT?

Procedimentos de validação inicial, contenção (isolamento de VLAN/porta), mitigação (rollback de configuração), comunicação de emergência, investigação forense e lições aprendidas com atualização do threat model.

6. Como priorizar vulnerabilidades em OT?

Priorize por impacto operacional (produção/hora), segurança humana, possibilidade de exploração (veículo de acesso) e disponibilidade de mitigação. Não use apenas CVSS; incorpore contexto OT.

7. Quais logs OT são essenciais?

Logs de historian, logs de engineering workstation, transferência de firmware/configuração, logs de gateways e audit trails de PAM. PCAPs de tráfego de protocolos industriais também são valiosos.

8. Devo criptografar tráfego Modbus?

Modbus nativamente não oferece criptografia. Considere encapsular tráfego via VPN industrial, usar gateways que ofereçam autenticação/inspeção, ou migrar para protocolos com TLS/DTLS suportado.

9. Como medir maturidade de segurança OT?

Use frameworks como ISA/IEC 62443 e avalie controles organizacionais, técnicos e de processo. Meça por KPIs (MTTD/MTTR, cobertura de detecção, diversidade de controles) e auditorias técnicas regulares.

10. O que é MITRE ATT&CK for ICS?

É um framework que descreve táticas, técnicas e procedimentos específicos para ambientes industriais, permitindo mapear ameaças e construir detecções e playbooks baseados em técnicas conhecidas.

11. Como proteger acesso de fornecedores remotos?

Use jump servers dedicados com PIM, MFA, microsegmentação, monitoramento de sessão com gravação, e contratos que obriguem a logs e auditoria. Acesso just-in-time reduz exposição.

12. Que métricas devo enviar ao board?

Risco residual por ativo crítico (em $/hora), cobertura de detecção (percentual de técnicas MITRE detectadas), MTTD/MTTR OT, e progresso em remediação de vulnerabilidades críticas. Traduza técnico para impacto financeiro e operacional.

Erros Comuns, Armadilhas e Correções

Subtópico: Repetição deliberada desta seção para reforçar a correção de práticas (resumo breve e prático). Muitas organizações caem nas mesmas armadilhas. As correções imediatas a priorizar são: segmentação por criticidade, controle estrito de acesso privilegiado, validação de fornecedores, instrumentação de telemetria e backups verificados. Implementar essas ações reduz drasticamente o risco de cenários críticos descritos anteriormente.

Considerações Finais

Modelagem de ameaças em refinarias e indústrias de processo não é um documento estático: é um programa contínuo que liga arquitetura, processos e operações. Para ser efetiva, precisa ser orientada ao negócio, validada por engenharia, instrumentada com dados e repetida após cada mudança de arquitetura. Ao priorizar controles que preservam segurança funcional e disponibilidade, e ao integrar detecção orientada a processos, equipes conseguem reduzir exposição e melhorar capacidade de resposta.

O que diferencia organizações maduras é a capacidade de traduzir riscos técnicos para impacto de negócio e de manter um ciclo de análise, mitigação, teste e retomada. Em plantas críticas, isso significa alinhar engenharia, operações e segurança em processos que respeitam a física do processo e as realidades operacionais. Se você levar uma lição desta peça, que seja esta: sem telemetria e sem validação operacional, qualquer modelagem é apenas teoria. Instrumente, valide, repita.

Segurança não é um produto que se compra; é uma prática que se cultiva. Comece pequeno, mas comece com o essencial: inventário confiável, segmentação, controles para acesso remoto e telemetria que permita detectar alterações físicas em tempo útil. O resto vem com disciplina e prática.

Recursos Visuais Sugeridos

• https://us-cert.cisa.gov/ics – Página de advisories e materiais sobre ICS/OT pela CISA
• https://www.mitre.org/att-ck/ics – MITRE ATT&CK for ICS (táticas e técnicas)
• https://www.isa.org/isa62443 – ISA/IEC 62443 overview e normas relacionadas
• https://www.dragos.com/resources/ – Whitepapers e guides da Dragos sobre ameaças a OT
• https://www.sans.org/white-papers/ – SANS ICS whitepapers e checagens práticas
• https://www.nist.gov/publications – Busque NIST SP 800-82 (Industrial Control Systems Security)
• https://www.abb.com/security – Documentação técnica de segurança para automação industrial

Cenário prático obrigatório

1. Preparação e autorização
   1. Obter autorização formal assinada com escopo e janelas de teste.
   2. Designar equipe de intervenção e plano de rollback.
2. Configuração do ambiente de laboratório
   1. Montar clone da rede OT com PLCs e HMI de testes.
   2. Provisionar historian e SIEM de testes.
3. Reconhecimento passivo/ativo autorizado
   1. Comandos: (em Kali autorizado)
   sudo nmap -sS -Pn -n -p 502,44818 --open -oA nmap_ot 10.10.100.0/24 sudo tcpdump -i eth0 port 502 -w captura_modbus.pcap

   1 2	sudo nmap -sS -Pn -n -p 502,44818 --open -oA nmap_ot 10.10.100.0/24 sudo tcpdump -i eth0 port 502 -w captura_modbus.pcap

   2. Validação: revisar nmap output e pcap com tshark/Wireshark.
4. Exploração controlada (lab)
   1. Usar modpoll para ler/escrever registradores em PLC de lab:
   modpoll -m tcp -r 40001 -c 2 10.10.100.45 modpoll -m tcp -r 40001 -t 3 -w 1 -a 1 10.10.100.45

   1 2	modpoll -m tcp -r 40001 -c 2 10.10.100.45 modpoll -m tcp -r 40001 -t 3 -w 1 -a 1 10.10.100.45

   2. Evidência: salvar PCAP, logs do PLC, printscreens do HMI.
   3. Rollback: restaurar snapshot do PLC com ferramenta do vendor.
5. Detecção e validação SIEM
   1. Checar se regra de SIEM dispara com escrita em setpoint crítico.
   2. Se não disparar, ajustar alert thresholds e criar regra correlacionando IP e escrita.
6. Relatório e lições aprendidas
   1. Documentar IOCs, TTPs, recomendações de mitigação e plano de remediação.
   2. Executar reunião com operações para discutir mudanças em produção.

Checklist Operacional

Checklist Blue Team (detecção, contenção, hardening, logging):

• Inventário de ativos atualizado e verificado.
• Segmentação de rede implementada por zonas e criticidade.
• PAM com MFA para contas privilegiadas e engenharia workstations.
• Jump servers para acesso remoto com gravação de sessão.
• Backups de configuração de PLC e HMI armazenados em WORM.
• Regras SIEM/SOAR específicas para protocolos OT (Modbus/DNP3/OPC).
• Monitoramento de integridade de firmware e checksums.
• Procedimentos aprovados para patching e janelas de manutenção.
• Planos de resposta e playbooks testados semestralmente.
• Exercícios Purple Team realizados regularmente.

Checklist Red Team (escopo autorizado, hipótese, execução, evidência, reporte):

• Autorizações e limites do escopo assinados por todas as partes.
• Hipóteses de ataque alinhadas a atores e motivação realistas.
• Plano de execução com timeline e janelas de rollback.
• Metodologia de reconhecimento definida (passiva antes de ativa).
• Ferramentas e comandos documentados e reproduzíveis.
• Recolhimento de evidências (PCAP, logs, prints) com integridade preservada.
• Comunicação pré-definida para incidentes acidentais detectados.
• Relatório entregue com PoC em ambiente lab e recomendações práticas.

Referências

• https://us-cert.cisa.gov/ics
• https://attack.mitre.org/matrices/ics/
• https://www.isa.org/isa62443/
• https://www.nist.gov/publications/guide-industrial-control-systems-security-sp-800-82-revision-2
• https://www.dragos.com/resources/
• https://www.sans.org/white-papers/
• https://www.schneider-electric.com/en/work/support/resources-and-tools/security-advisories/
• https://www.abb.com/security
• https://www.mandiant.com/resources
• https://www.kaspersky.com/blog/ics-security/
• https://www.national-audit-offices.org/ (consultar relatórios sobre infraestrutura crítica)
• https://www.iso.org/standard/72415.html (ISO/IEC 27001 overview)
• https://www.cisa.gov/stopransomware (recursos e guidance sobre ransomware)
• https://www.talosintelligence.com/ (Intel e advisories)