BLOG

Zero Trust em IoT/OT: Por Que o Modelo Tradicional Falha em Infraestruturas Críticas e Como Adaptá-lo

Zero Trust em IoT/OT: Por Que o Modelo Tradicional Falha em Infraestruturas Críticas e Como Adaptá-lo
Redação CECyber
PoFoto Eduardo Honorator Eduardo Honorato – OT Cybersecurity Expert | 
Strategic Advisor for Critical Infrastructure |
Cyber Operational Resilience | Author & Speaker

A arquitetura de segurança Zero Trust (ZT) tornou-se a resposta imperativa para um perímetro corporativo que já não existe. O paradigma de “nunca confiar, sempre verificar” é o pilar da proteção contra ameaças modernas no ambiente corporativo (TI). No entanto, quando as organizações tentam estender essa mesma filosofia, de forma inalterada, para as suas Tecnologia Operacional (OT) e Internet das Coisas (IoT), elas frequentemente encontram falhas catastróficas. 

 

O problema não é o conceito de Zero Trust em si, mas o fato de ele ter sido projetado por profissionais de TI, para sistemas operacionais de TI (gerenciados, modernos, baseados em agentes). O “chão de fábrica” das infraestruturas críticas opera sob um conjunto de regras físicas e digitais fundamentalmente diferente. Dispositivos legados não criptografados de 20 anos, requisitos de latência de microssegundos e dispositivos IoT de baixo custo criam um ambiente onde as verificações contínuas e agressivas de identidade e postura do Zero Trust tradicional não são apenas impraticáveis, mas perigosas. 

 

Este artigo realiza um mergulho profundo e técnico nas razões pelas quais o Zero Trust se rompe em IoT/OT, baseando-se em análises da CSO Online e frameworks de maturidade industrial. Discutiremos o conflito fiduciário entre segurança e operação, o dilema da identidade sem agentes, o risco da microssegmentação em redes planas e, crucialmente, como as organizações podem adotar uma abordagem condicional e pragmática de Zero Trust que respeite a realidade industrial. 

Seção 1: O Conflito Fiduciário de Prioridades (CIA vs. SRP)  

A razão fundamental pela qual o Zero Trust tradicional falha em OT/IoT não é técnica, mas filosófica. É uma questão de conflito de prioridades fiduciárias. Na TI corporativa, o objetivo principal é proteger dados sensíveis. Na OT/IoT industrial, o objetivo principal é proteger o processo físico. 

O Triângulo da TI (CIA) 

A TI opera sob o paradigma CIA: Confidencialidade, Integridade e Disponibilidade, nesta ordem. Se houver suspeita de um compromisso em um laptop corporativo, um gateway Zero Trust pode bloquear imediatamente o acesso do usuário enquanto verifica sua identidade. A disponibilidade do funcionário é sacrificada em prol da confidencialidade dos dados corporativos. 

O Triângulo da OT (SRP) 

 Em ambientes industriais, essa hierarquia é invertida ou substituída pelo paradigma SRP: Safety, Reliability, Productivity (Segurança, Confiabilidade, Produtividade). A Confidencialidade dos dados que fluem entre um Controlador Lógico Programável (PLC) e uma Interface Homem-Máquina (HMI) é secundária à Disponibilidade do processo de manufatura. 

 

Um gateway Zero Trust operando agressivamente no “chão de fábrica” que introduz latência excessiva ou gera um falso positivo bloqueando a comunicação de um sensor crítico pode desligar uma subestação de energia, paralisar uma linha de produção ou, em cenários extremos, desativar um sistema de instrumentação de segurança (SIS), colocando vidas em risco. Em OT, o Zero Trust não pode introduzir riscos operacionais maiores do que a ameaça cibernética que ele tenta mitigar. 

Tabela: O Clashe de Prioridades TI vs. OT 
Tabela: O Clashe de Prioridades TI

Seção 2: O Problema da Identidade e o Dilema do “Agentless 

O pilar central do Zero Trust Architecture (NIST SP 800-207) é a identidade. Cada usuário, dispositivo e fluxo de dados deve ser autenticado e autorizado de forma única antes de obter acesso. A TI corporativa resolve isso instalando agentes de Endpoint Detection and Response (EDR) e certificando cada dispositivo via Active Directory (AD). 

OT: O Deserto de Agentes 

Em OT, a maioria dos dispositivos é agentless. Você não pode instalar um agente de identidade AD ou um software de segurança moderno em um PLC da Siemens de 20 anos, em um monitor cardíaco de hospital ou em um sensor IoT de baixo custo projetado com o mínimo de memória e poder de processamento. 

 

Muitos desses dispositivos IoT/OT não possuem capacidade de computação para suportar protocolos de autenticação fortes (como MFA ou certificados digitais). Consequentemente, a “identidade” de um PLC é frequentemente reduzida ao seu endereço IP ou MAC. Esses identificadores são estáticos, facilmente forjados (spoofing) e insuficientes para uma arquitetura de confiança contínua. Sem uma identidade de dispositivo forte, o Zero Trust baseia suas decisões em dados não confiáveis, quebrando o princípio fundamental de “sempre verificar”. 

Seção 3: O Pesadelo dos Sistemas Legados e Protocolos Inseguros 

Sistemas industriais operam em ciclos de vida massivos, muitas vezes de 15 a 30 anos. Quando muitos PLCs e HMIs críticos em operação hoje foram instalados, a cibersegurança e o conceito de redes convergentes eram inexistentes. O modelo de segurança dependia da “segurança por obscuridade” e do isolamento físico (air-gap). 

Protocolos em Texto Claro 

A maioria dos protocolos industriais legados (Modbus, BACnet, Profinet) foram projetados para confiabilidade de engenharia, não para segurança. Eles transmitem dados em texto claro, sem autenticação ou criptografia. Se um invasor obtém acesso a uma rede plana OT, ele pode escutar comandos e, mais perigosamente, injetar comandos falsos para o maquinário físico. 

 

O Zero Trust tradicional, projetado para operar em cima de HTTPS e TLS, não sabe como lidar com tráfego Modbus não autenticado fluindo de um dispositivo que não pode ser atualizado para suportar criptografia sem uma reengenharia multimilionária da planta. Tentativas agressivas de microssegmentação em cima dessas redes legadas planas podem quebrar comunicações proprietárias essenciais. 

 
O Risco da Latência e Falsos Positivos

Seção 4: O Risco da Latência e Falsos Positivos 

Zero Trust Architecture depende da aplicação contínua de políticas no gateway ou proxy de acesso. Para cada fluxo de dados, o sistema deve verificar as credenciais do usuário, a postura do dispositivo e o contexto da solicitação antes de autorizar a conexão. Essa verificação contínua introduz uma penalidade de latência computacional. 

Millissegundos Importam em OT 

Em processos de manufatura de alta velocidade (como robótica ou envase) ou em controles de subestação elétrica, os loops de controle exigem tempos de resposta determinísticos na ordem de millissegundos. Se um gateway Zero Trust operando na borda entre a TI e a OT introduzir uma latência de 5 millissegundos para realizar uma verificação de identidade em um fluxo de dados Modbus/TCP crítico, essa latência pode causar falhas de sincronização no maquinário físico, resultando em defeitos na produção ou shutdowns de emergência que Mirror um ataque cibernético físico. 

Além da latência, os falsos positivos são inaceitáveis. Um modelo de confiança agressivo que bloqueia uma HMI de se conectar a um PLC porque detectou um comportamento de rede “anômalo” (que talvez fosse apenas uma rotina de engenharia não documentada) paralisará a planta. Em OT, o gateway Zero Trust não pode “presumir violação” (Assume Breach) se isso resultar em uma “interrupção presumida” (Assume Shutdown). 

Seção 5: O Perigo da Microssegmentação Mal Planejada 

A microssegmentação é frequentemente apresentada como a “bala de prata” para Zero Trust em OT, visando criar perímetros microscópicos ao redor de cada ativo crítico para impedir a movimentação lateral de atacantes que já comprometeram a rede corporativa (TI). 

Redes OT Planas 

Historicamente, as redes de “chão de fábrica” foram projetadas como redes planas e abertas (Layer 2) para garantir a máxima confiabilidade e facilidade de engenharia. Centenas de PLCs, HMIs e servidores industriais podem residir em uma única sub-rede Modbus plana. 

A introdução repentina e agressiva de firewalls de microssegmentação ou políticas de nanosegmentação baseadas em software em cima dessa infraestrutura frágil é uma receita para o desastre operacional. Se os defensores não possuírem visibilidade passiva absoluta de cada fluxo de dados proprietário e dependência de engenharia entre os ativos antes de implementar as políticas, a microssegmentação quebrará comunicações essenciais de engenharia que mantêm a planta rodando. Em OT, você não pode “quebrar primeiro e consertar depois”, como é comum em TI. 

Seção 6: Como Operacionalizar o Zero Trust Pragmático em IoT/OT 

Diante desses desafios monumentais sistemas legados, falta de identidade, intolerância à latência e redes planas, como as organizações podem proteger suas infraestruturas críticas sem introduzir riscos operacionais inaceitáveis? 

 

A resposta não é rejeitar o Zero Trust, mas rejeitar o Zero Trust tradicional e agressivo baseado em software. As organizações devem adotar uma abordagem condicional, gradual e baseada em engenharia, focada em mitigar as vulnerabilidades do ambiente OT, em vez de tentar forçar a identidade corporativa em cima dele. 

Uma Abordagem Gradual para OT Zero Trust 

Tabela: Framework Gradual para OT Zero Trust (Baseado em Maturidade) 

1. Visibilidade Passiva em Primeiro Lugar

Antes de implementar qualquer política Zero Trust, você deve monitorar passivamente a rede OT. Use soluções agentless projetadas para OT que escutam o tráfego Modbus/DNP3 e mapeiam todas as comunicações existentes. Isso cria uma linha de base operacional da planta. Se você tentar microssegmentar antes de ter essa visibilidade, quebrará comunicações vitais de engenharia.

2. Microssegmentação Baseada em Consequências (Zonas e Conduítes)

Em vez de microssegmentar por usuário (como em TI), microssegmente OT com base nas consequências operacionais e na criticidade. Use a norma ISA/IEC 62443 para criar “Zonas” de ativos semelhantes e “Conduítes” controlados entre elas. Isolate o sistema Safety da rede SCADA primária. Use firewalls industriais com Inspeção Profunda de Pacotes (DPI) de protocolos Modbus/BACnet para permitir apenas comandos autorizados específicos (ex: permitir leitura Modbus, mas bloquear comandos de gravação crítica para PLCs específicos).

3. Acesso Condicional Baseado no SRP

Adapte o modelo de confiança para priorizar SRP. Use proxies de acesso Zero Trust (ZTNA) para acesso remoto à rede OT, exigindo autenticação multifator forte para engenheiros ou fornecedores de manutenção que se conectam aos sistemas SCADA. No entanto, na borda entre a TI e a OT onde fluem loops de controle determinísticos, use controles determinísticos baseados em hardware (como Diodos de Dados unidirecionais físicos) em vez de proxies de software que introduzem latência de millissegundos inaceitável. 

Conclusão: Engenharia de Segurança Cibernética como o Futuro do OT Zero Trust 

A arquitetura Zero Trust tornou-se o padrão-ouro de segurança por uma razão, mas sua transição para o “chão de fábrica” das infraestruturas críticas falhou porque o modelo tradicional foi projetado para sistemas corporativos gerenciados e baseados em agentes. Em ambientes IoT/OT, a intolerância à latência, a proliferação de sistemas legados e a natureza agentless dos ativos PLCs e sensores criam uma realidade onde as verificações agressivas do Zero Trust tradicional não funcionam. 

 

No entanto, o futuro da segurança industrial não é rejeitar o Zero Trust, mas sim rejeitar o Zero Trust tradicional baseado em software. As organizações devem adotar uma abordagem condicional e baseada em engenharia, focada em mitigar as vulnerabilidades do ambiente OT, em vez de tentar forçar a identidade corporativa em cima dele. 

 

Tratar ciberataques industriais como falhas de design de engenharia de segurança operacional exige uma mudança de mentalidade para a Engenharia de Segurança Cibernética (CIE). O verdadeiro Zero Trust condicional em OT começa com visibilidade passiva absoluta de cada fluxo proprietário e segue com o fortalecimento básico e a segmentação gradual baseada em consequências e em hardware determinístico, onde millissegundos importam. O Zero Trust do chão de fábrica não pode presumir violação se isso resultar em uma interrupção da produção. Ele deve sempre presumir a operação contínua e verificar condicionalmente onde for seguro fazê-lo. 

Referências 

  • Apoio Técnico: Framework NIST SP 800-207 (Zero Trust Architecture). 
Rolar para cima