O engenheiro de automação conhece cada detalhe da planta. Sabe o comportamento de cada PLC, o histórico de cada alarme, os atalhos que mantêm a produção rodando quando o tempo é curto.

Com o passar dos anos, ele foi acumulando acessos, não por descuido, mas por necessidade. Hoje, ele programa a lógica dos controladores, opera o sistema em turnos críticos e, quando uma emergência exige, desabilita alarmes de segurança para manter a linha funcionando.

Cada uma dessas ações, isolada, é legítima. Juntas, formam exatamente o tipo de conflito que a IEC 62443, padrão internacional de segurança para sistemas de automação e controle industrial, exige que esteja segregado. E é o primeiro ponto que uma auditoria vai procurar.

Esse cenário não é exceção.  

O fato é que o problema de uma parcela significativa das plantas industriais não está na competência do profissional, mas na ausência de estrutura que separe funções incompatíveis antes que alguém explore essa concentração de acesso.

É o que mostramos agora!

O que é a IEC 62443 e por que ela exige SoD documentada

A IEC 62443 é uma série de padrões internacionais desenvolvida pela ISA (International Society of Automation) e adotada pela IEC (International Electrotechnical Commission) para segurança de IACS, Industrial Automation and Control Systems, os sistemas de automação e controle industrial que governam processos físicos em plantas de óleo e gás, energia elétrica, petroquímica, manufatura, saneamento e mineração.

O que diferencia a IEC 62443 de frameworks de segurança mais conhecidos, como a ISO 27001, é a ordem de prioridade. Enquanto a ISO 27001 coloca confidencialidade no centro, a IEC 62443 prioriza disponibilidade, integridade e confidencialidade, nessa sequência.

Em ambientes industriais, uma parada não planejada pode ser tão catastrófica quanto uma violação de dados. Em alguns casos, mais.

A norma é estruturada em quatro grupos de documentos, cobrindo desde fundamentos e gestão até requisitos técnicos de sistemas e componentes. No núcleo de todos os níveis estão sete Requisitos Fundamentais (Foundational Requirements). Dois deles são diretamente relevantes para a Segregação de Funções:

• FR1 — Controle de Identificação e Autenticação: todo usuário — humano, processo de software ou dispositivo — deve ser identificado e autenticado antes de acessar qualquer sistema de controle.

• FR2 — Controle de Uso: cada usuário autenticado deve receber apenas os privilégios estritamente necessários para executar suas funções — nem mais, nem menos.

O FR2 é onde a SoD se materializa na norma. Ele estabelece que a concessão de privilégios deve ser granular, baseada em função e revisada periodicamente.

Quando um único usuário acumula privilégios de programação, operação e desabilitação de alarmes, o FR2 está sendo violado — independentemente de qualquer intenção.

A norma organiza os ambientes industriais em zonas e dutos de comunicação, seguindo o Modelo de Referência Purdue, e define quatro níveis de segurança — SL 1 a SL 4 — que determinam a robustez dos controles exigidos com base no perfil de risco de cada zona.

Quanto maior o nível, maior a exigência de segregação, rastreabilidade e controle de acesso.

O problema do dia a dia: por que conflitos SoD em OT são invisíveis

Sistemas industriais foram projetados para disponibilidade, não para rastreabilidade de acesso. Durante décadas, operaram em redes isoladas — os chamados ambientes air-gapped — onde a premissa era que o isolamento físico substituía os controles de acesso.

Nesse contexto, a cultura de "quem sabe, opera" se consolidou. O engenheiro mais experiente tinha acesso a tudo porque era ele quem resolvia os problemas.

Essa lógica funcionou enquanto os sistemas permaneceram isolados. Com a convergência entre IT (Information Technology — tecnologia da informação) e OT (Operational Technology — tecnologia operacional), esse isolamento deixou de existir.

Redes industriais se conectam a ERPs corporativos, a sistemas de manutenção, a redes de fornecedores. E com essa conectividade, os riscos de acesso do mundo corporativo migraram para o ambiente industrial — sem que os controles acompanhassem.

Os conflitos mais críticos em ambientes industriais seguem padrões consistentes:

• Quem programa o PLC não deveria ser o mesmo que opera o sistema em produção.

• Quem configura o SCADA não deveria ser o mesmo que valida mudanças no ambiente.

• Quem tem acesso à workstation de engenharia do SIS (Safety Instrumented System — sistema instrumentado de segurança, a última linha de defesa automatizada de uma planta) não deveria ter acesso simultâneo ao DCS (Distributed Control System — sistema de controle distribuído que governa o processo produtivo).

• Quem pode desabilitar alarmes de segurança não deveria ser o mesmo que responde ao evento que gerou o alarme.

O problema é que esses conflitos raramente aparecem de forma explícita. Eles se acumulam ao longo do tempo, embutidos em permissões concedidas por urgência, legadas de funções anteriores ou simplesmente nunca revisadas.

Em uma planta com dezenas de sistemas — SCADA, PLCs, DCS, SIS, MES (Manufacturing Execution System — sistema de execução de manufatura), SAP PM — o volume de combinações possíveis torna qualquer análise manual inviável.

O que os casos reais ensinaram: Stuxnet e Triton

A teoria dos conflitos SoD em OT ganhou contornos concretos em dois incidentes que redefiniu permanentemente a forma como o setor industrial trata segurança de acesso.

Stuxnet — Natanz, 2010

O Stuxnet é considerado o primeiro ciberataque publicamente conhecido a causar danos físicos a uma infraestrutura industrial. O alvo eram as centrífugas de enriquecimento de urânio na instalação de Natanz, no Irã, controladas por PLCs Siemens S7.

O vetor de entrada foi uma workstation de engenharia — a estação usada para programar a lógica dos controladores. Um USB infectado introduziu o malware na rede, e a partir da workstation o código se propagou diretamente aos PLCs.

O conflito explorado foi preciso: a mesma estação usada para programar os controladores tinha acesso irrestrito à rede de controle operacional. Não havia segregação entre quem desenvolve lógica de automação e quem tem acesso aos sistemas em produção.

LEIA TAMBÉM: Gestão de terceiros: o risco invisível que sua auditoria não está vendo

Com esse acesso, o Stuxnet modificou a lógica ladder dos PLCs — forçando as centrífugas a operar em velocidades irregulares — enquanto enviava dados falsificados ao SCADA. Os operadores viam tudo "dentro do normal" enquanto o equipamento era destruído.

A lição estrutural: acesso irrestrito de workstations de engenharia a sistemas de controle em produção é o vetor de ataque mais explorado em ambientes industriais. E é um conflito SoD que a IEC 62443 trata explicitamente.

Triton/Trisis — Refinaria petroquímica no Oriente Médio, 2017

Sete anos depois de Stuxnet, o Triton — também conhecido como Trisis ou HatMan — representou uma escalada qualitativa: foi o primeiro ataque público dirigido especificamente a um SIS, o sistema instrumentado de segurança projetado para acionar o desligamento de emergência de uma planta quando parâmetros críticos são ultrapassados.

O SIS é, por definição, a última barreira automatizada entre uma operação normal e um acidente com danos físicos, ambientais e risco de vidas. Atacá-lo diretamente significava atacar exatamente essa barreira.

A análise do Mandiant — empresa de inteligência em segurança que investigou o incidente — identificou o mecanismo central da vulnerabilidade: workstations de engenharia com acesso simultâneo ao DCS e ao SIS.

A recomendação explícita do relatório é direta: estações que programam controladores SIS não devem ter conexão dupla com outros sistemas de controle de processo.

Esse é, em essência, um conflito SoD. A mesma estação que configurava o sistema de segurança podia acessar o sistema de processo — e vice-versa. Com esse acesso, os atacantes obtiveram controle remoto completo do SIS, com capacidade técnica de colocar a planta em estado inseguro.

LEIA TAMBÉM: Por que Inteligência Artificial em gestão de riscos deixou de ser opcional

O incidente foi descoberto porque o sistema de segurança acionou um shutdown de emergência ao detectar um erro de validação de código — não porque os controles de acesso alertaram alguém.

A lição estrutural: a integração crescente entre redes OT e IT, sem segregação adequada entre sistemas de diferentes criticidades e funções, transforma ambientes projetados para isolamento em superfícies de ataque abertas. E os atacantes sabem exatamente onde procurar esses pontos.

O que a auditoria IEC 62443 vai verificar

Uma auditoria de conformidade IEC 62443 não se limita a verificar se firewalls estão configurados ou se patches estão aplicados. Ela vai direto aos controles de acesso e à segregação de funções — porque é onde a maioria das não-conformidades se concentra.

Os pontos que auditores prioritariamente verificam em relação à SoD:

• Separação de funções entre programação e operação de PLCs — existe diferenciação formal entre quem desenvolve lógica de automação e quem opera os sistemas em produção?

• Isolamento de workstations de engenharia de SIS — estações que configuram sistemas de segurança têm acesso segregado de outros sistemas de controle?

• Controle de acesso por zona IEC 62443 — os privilégios de usuários respeitam as fronteiras de zona definidas na arquitetura de segurança?

• Capacidade de desabilitação de alarmes — quem pode desabilitar alarmes de segurança está formalmente separado de quem responde aos eventos?

• Trilha de auditoria e rastreabilidade — existe registro de quem acessou o quê, quando e com qual autorização em cada sistema crítico?

• Revisão periódica de acessos — os perfis de usuários em sistemas OT são revisados com regularidade documentada?

A maioria das plantas não tem essas respostas prontas — não porque os controles não existam, mas porque nunca foram formalizados, documentados e conectados à estrutura de zonas e requisitos da IEC 62443. O resultado são findings que poderiam ter sido antecipados e remediados antes da auditoria chegar.

Como mapear conflitos SoD em sistemas OT antes que virem problema

O mapeamento de conflitos SoD em ambientes industriais tem uma complexidade adicional em relação ao mundo corporativo: sistemas OT são heterogêneos por natureza. SCADA, PLCs, DCS, SIS e MES de fabricantes diferentes, com estruturas de acesso proprietárias, protocolos industriais específicos e interfaces que não foram projetadas para integração com gestão centralizada de identidades.

O que precisa ser coberto em um mapeamento eficaz:

• Inventário de usuários e perfis em cada sistema crítico — quem tem acesso a quê, em qual sistema e com qual nível de privilégio.

• Cruzamento de funções incompatíveis por zona IEC 62443 — quais combinações de acesso violam os requisitos FR1 e FR2 da norma.

• Identificação de controles compensatórios para conflitos que não podem ser eliminados por restrição técnica — e formalização desses controles como evidência auditável.

• Documentação estruturada por zona de segurança — a Matriz SoD precisa refletir a arquitetura de zonas e dutos da IEC 62443, não apenas uma lista genérica de conflitos.

• Plano de remediação com responsáveis e prazo — achados sem plano de ação não encerram findings em auditoria.

Em plantas com dezenas de sistemas e centenas de usuários, esse mapeamento por planilha ou processo manual não escala, pois o volume de combinações possíveis entre perfis, sistemas e funções supera qualquer análise humana sistemática.

Para a IEC 62443, a Segregação de Funções é requisito fundamental porque a concentração de funções incompatíveis em ambientes industriais não é apenas um risco regulatório, mas um vetor que ataques como Stuxnet e Triton exploraram de forma cirúrgica.

O que Natanz e a refinaria petroquímica do Oriente Médio têm em comum não é a sofisticação dos invasores, mas ausência de segregação entre funções que deveriam estar separadas — e que, se estivessem, teriam exigido um nível adicional de comprometimento que poderia ter interrompido o ataque antes do dano.

Na sua planta, quem programa o PLC também pode operar o sistema e intervir nos alarmes de segurança?

Se a resposta for sim, esse é o sinal de alerta para investigar a confiabilidade da sua Matriz SoD

O SoD Discovery da Vennx mapeia conflitos de acesso em sistemas OT e corporativos, gerando a Matriz SoD estruturada que auditorias IEC 62443 exigem com rastreabilidade completa e SLA recorde devido aos recursos de IA utilizados pela empresa no rastreio de toda a organização.  

Conheça o SoD Discovery e fale com um especialista Vennx!