Segurança OT no âmbito da NIS2: mapa ISO 27001 e IEC 62443

Às 02:17 de uma segunda-feira, um operador de tratamento de água recebe um alarme de um sistema de dosagem. A dosagem química continua dentro dos limites de segurança, mas um PLC reporta comandos irregulares, o posto de trabalho de engenharia apresenta falhas de autenticação provenientes de uma conta VPN de fornecedor, e o analista do SOC de serviço faz uma pergunta a que ninguém quer responder sob pressão.

Isto é um incidente de TI, um incidente OT, um evento de segurança operacional ou um incidente significativo notificável ao abrigo da NIS2?

A instalação tem firewalls. Tem documentação ISO. Tem uma folha de cálculo de fornecedores. Tem até um Plano de Resposta a Incidentes (IRP). Mas o plano foi escrito para comprometimento de correio eletrónico e indisponibilidade de serviços na nuvem, não para um controlador legado que não pode receber patches durante a produção, um fornecedor que precisa de acesso remoto para restaurar o serviço e uma autoridade reguladora que espera evidência dentro dos prazos de reporte da NIS2.

O mesmo problema surge nas salas de administração. Um Diretor de Segurança da Informação (CISO) de um fornecedor regional de energia pode ter um Sistema de Gestão de Segurança da Informação (SGSI) certificado segundo a ISO/IEC 27001:2022 para a TI corporativa, enquanto o parque de Tecnologia Operacional (OT) continua a ser um emaranhado de PLCs, RTUs, HMIs, historiadores, postos de trabalho de engenharia, switches industriais e vias de acesso de fornecedores. A pergunta do Diretor Executivo é simples: “Estamos cobertos? Consegue prová-lo?”

Para muitas entidades essenciais e importantes, a resposta honesta é desconfortável. Estão parcialmente cobertas. Conseguem prová-lo parcialmente. Mas a segurança OT no âmbito da NIS2 exige mais do que conformidade genérica de TI.

Exige um modelo operacional unificado que ligue a governação da ISO/IEC 27001:2022, a linguagem de controlos da ISO/IEC 27002:2022, as práticas de engenharia industrial da IEC 62443, as medidas de gestão de riscos de cibersegurança do NIS2 Article 21 e a evidência de notificação de incidentes do NIS2 Article 23.

É essa ponte que este guia constrói.

Porque é que a segurança OT no âmbito da NIS2 é diferente da conformidade comum de TI

A NIS2 aplica-se a muitas entidades públicas e privadas que prestam serviços abrangidos no âmbito da UE, incluindo entidades essenciais e importantes em setores como energia, transportes, banca, infraestruturas dos mercados financeiros, saúde, água potável, águas residuais, infraestrutura digital, gestão de serviços TIC, administração pública, espaço, serviços postais, gestão de resíduos, indústria transformadora, produtos químicos, alimentação, prestadores digitais e investigação.

A Diretiva exige medidas técnicas, operacionais e organizativas adequadas e proporcionais para gerir riscos de cibersegurança, prevenir ou minimizar o impacto de incidentes e proteger a continuidade dos serviços. O Article 21 inclui uma abordagem baseada em todos os riscos que abrange análise de riscos, políticas de segurança, tratamento de incidentes, continuidade de negócio, gestão de crises, segurança da cadeia de fornecimento, aquisição e manutenção seguras, tratamento e divulgação de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, formação, criptografia, segurança de Recursos Humanos, controlo de acesso, gestão de ativos, MFA ou autenticação contínua, comunicações seguras e comunicações de emergência, quando aplicável.

Estes requisitos são familiares para uma equipa ISO/IEC 27001:2022. Em OT, cada um deles comporta-se de forma diferente.

Uma vulnerabilidade num servidor web pode, muitas vezes, ser corrigida com patches em poucos dias. Uma vulnerabilidade num controlador de turbina pode exigir validação do fornecedor, uma janela de manutenção, uma revisão de segurança operacional e procedimentos de operação de contingência. Um computador portátil pode ser reconstruído. Uma HMI de produção pode depender de um sistema operativo legado porque a aplicação industrial não foi certificada para uma plataforma mais recente. Um playbook do SOC pode indicar “isolar o host”, enquanto o engenheiro OT responde: “não antes de sabermos se o isolamento afeta o controlo de pressão”.

A diferença não é apenas técnica. A TI normalmente prioriza confidencialidade, integridade e disponibilidade. A OT prioriza disponibilidade, integridade do processo e segurança operacional. Um controlo de segurança que introduza latência, exija reinício ou interrompa um processo físico pode ser inaceitável sem aprovação da engenharia.

A NIS2 não isenta a OT da gestão de riscos de cibersegurança. Espera que a organização demonstre que os controlos são adequados ao risco e proporcionais à realidade operacional.

A pilha de controlos: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 e IEC 62443

Um programa defensável de segurança OT no âmbito da NIS2 começa com uma pilha de controlos em camadas.

A ISO/IEC 27001:2022 fornece o sistema de gestão. Exige que a organização defina o contexto, as partes interessadas, as obrigações regulamentares, o âmbito do SGSI, as interfaces e as dependências. Também exige compromisso da liderança, uma Política de Segurança da Informação, avaliação de riscos, tratamento de riscos, Declaração de Aplicabilidade, informação documentada, auditoria interna, revisão pela gestão e melhoria contínua.

A ISO/IEC 27002:2022 fornece o vocabulário de controlos. Para OT, os controlos mais importantes incluem frequentemente segurança de fornecedores, gestão do risco da cadeia de fornecimento TIC, planeamento de incidentes, preparação para a continuidade de negócio, requisitos legais e contratuais, gestão de ativos, controlo de acesso, gestão de vulnerabilidades, cópias de segurança, registo de eventos, monitorização, segurança de redes e segregação de redes.

A IEC 62443 fornece o modelo de engenharia de segurança industrial. Ajuda a traduzir requisitos do sistema de gestão em práticas OT, como zonas, condutas, níveis de segurança, responsabilidades do proprietário do ativo, responsabilidades do integrador de sistemas, expectativas para fornecedores de produtos, restrições de acesso remoto, funcionalidade mínima, gestão de contas, endurecimento e controlos de ciclo de vida.

A Clarysec utiliza esta pilha porque evita duas falhas comuns. Primeiro, impede que a implementação ISO se torne demasiado genérica para OT. Segundo, impede que o trabalho de engenharia IEC 62443 fique desligado da responsabilização do órgão de administração, das obrigações de reporte NIS2 e da evidência de auditoria.

A IoT / OT Security Policy da Clarysec estabelece diretamente esta ponte:

Garantir que todas as implementações estão alinhadas com os controlos ISO/IEC 27001 e com orientações setoriais aplicáveis (por exemplo, IEC 62443, ISO 27019, NIST SP 800-82).

Esta frase é importante. A política não é apenas uma lista de verificação de endurecimento de dispositivos. Liga a governação ISO, a orientação setorial OT e a segurança operacional.

Começar pelo âmbito: que serviço OT deve ser protegido?

Antes de mapear controlos, defina o serviço OT em linguagem de negócio e regulamentar.

Um gestor de fábrica pode dizer: “Operamos a linha de embalagem.” Uma avaliação NIS2 deve dizer: “Este processo de produção suporta um serviço essencial ou importante e depende de PLCs, HMIs, postos de trabalho de engenharia, historiadores, switches industriais, acesso remoto de fornecedores, um prestador de manutenção, um fluxo de análise na nuvem e um serviço empresarial de identidade.”

As cláusulas 4.1 a 4.4 da ISO/IEC 27001:2022 são úteis porque obrigam a organização a identificar questões internas e externas, partes interessadas, requisitos legais e contratuais, limites do SGSI, interfaces e dependências. Para segurança OT no âmbito da NIS2, isto significa mapear não apenas a rede da sede, mas também os sistemas industriais e as dependências de serviço que afetam continuidade, segurança operacional e prestação regulada.

O NIST CSF 2.0 reforça a mesma lógica. A sua função GOVERN exige compreender a missão, as partes interessadas, as dependências, as obrigações legais e regulamentares, os serviços críticos e os serviços dos quais a organização depende. Os Perfis Organizacionais fornecem um método prático para delimitar o estado atual, definir um estado-alvo, analisar lacunas e produzir um plano de ação priorizado.

Para um ambiente OT, a Clarysec começa normalmente com cinco perguntas:

1. Que serviço regulado ou crítico é suportado por este ambiente OT?
2. Que ativos OT, redes, fluxos de dados e terceiros são necessários para esse serviço?
3. Que restrições de segurança operacional, disponibilidade e operação afetam os controlos de segurança?
4. Que obrigações legais, contratuais e setoriais se aplicam, incluindo NIS2, RGPD da UE, DORA, quando relevante, contratos com clientes e regras nacionais?
5. Que partes do ambiente estão dentro do SGSI e que partes são dependências externas que exigem controlos de fornecedores?

Muitos programas NIS2 falham aqui. Definem o âmbito em torno da TI corporativa porque é mais fácil de inventariar. Auditores e reguladores não ficarão convencidos se a dependência mais crítica do serviço surgir apenas como uma linha vaga chamada “rede da fábrica”.

Um mapa prático de controlos OT no âmbito da NIS2

A tabela abaixo mostra como transformar temas do NIS2 Article 21 em evidência ISO/IEC 27001:2022, ISO/IEC 27002:2022 e IEC 62443. Não substitui uma avaliação de riscos formal, mas dá a CISO, gestores OT e equipas de conformidade um ponto de partida prático.

Este mapa é deliberadamente orientado para evidência. Ao abrigo da NIS2, dizer “temos segmentação” não é suficiente. É necessário demonstrar por que motivo a segmentação é adequada, como está implementada, como as exceções são aprovadas e como o desenho reduz o impacto sobre o serviço regulado.

Segmentação: o primeiro controlo OT que os auditores irão testar

Se o incidente das 02:17 envolvesse um atacante a mover-se de um computador portátil de escritório para um posto de trabalho de engenharia, a primeira pergunta de auditoria seria óbvia: porque é que esse caminho podia existir?

A IoT / OT Security Policy é explícita:

Os sistemas OT devem operar em redes dedicadas, isoladas da TI empresarial e de sistemas expostos à Internet.

Para ambientes mais pequenos, a Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME fornece uma linha de base prática:

Todos os dispositivos Internet das Coisas (IoT) e Tecnologia Operacional (OT) devem ser colocados numa rede Wi‑Fi ou VLAN separada

Para um operador maduro de infraestruturas críticas, a segmentação deve ser concebida em torno de zonas e condutas OT. Utilizadores empresariais não devem aceder diretamente a redes PLC. As ligações de fornecedores devem terminar em zonas de acesso controlado. A replicação de historiadores deve utilizar vias aprovadas. Os sistemas de segurança operacional devem ser isolados de acordo com o risco e os requisitos de engenharia. Redes OT sem fios devem ser justificadas, endurecidas e monitorizadas.

Zenith Blueprint: An Auditor’s 30-Step Roadmap, na fase Controls in Action, Step 20, explica o princípio por trás da segurança de redes da ISO/IEC 27002:2022:

Os sistemas de controlo industrial devem ser isolados do tráfego de escritório.

Também alerta que a segurança de redes exige arquitetura segura, segmentação, controlo de acesso, cifragem em trânsito, monitorização e defesa em profundidade.

Em Zenith Controls: The Cross-Compliance Guide, o controlo 8.22 da ISO/IEC 27002:2022, Segregação de Redes, é tratado como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, alinhado com o conceito de cibersegurança Protect, tendo a segurança de sistemas e redes como capacidade operacional e Protection como domínio de segurança.

Essa classificação é útil para evidência NIS2 porque a segmentação não é um diagrama decorativo. É um controlo preventivo concebido para reduzir o raio de impacto e preservar a continuidade de serviços essenciais.

Gestão de vulnerabilidades quando os sistemas OT não podem simplesmente receber patches

A NIS2 exige aquisição, desenvolvimento e manutenção seguros de sistemas de rede e informação, incluindo tratamento e divulgação de vulnerabilidades. Em TI, gestão de vulnerabilidades significa muitas vezes detetar, priorizar, aplicar patches e verificar. A OT acrescenta restrições.

Uma HMI crítica pode só poder receber patches durante uma paragem planeada. Uma atualização de firmware de PLC pode exigir envolvimento do fornecedor. Um sistema certificado para segurança operacional pode perder a certificação se for modificado incorretamente. Alguns dispositivos legados podem não ter qualquer suporte do fornecedor.

Zenith Blueprint, na fase Controls in Action, Step 19, fornece a lógica de auditoria correta para vulnerabilidades técnicas:

Para sistemas que não podem receber patches imediatamente, talvez devido a software legado ou restrições de indisponibilidade, implemente controlos compensatórios. Isto pode incluir isolar o sistema atrás de uma firewall, limitar o acesso ou aumentar a monitorização. Em todos os casos, registe e aceite formalmente o risco residual, demonstrando que a questão não foi esquecida.

A linha de base da política para PME é igualmente prática:

O inventário deve ser revisto trimestralmente para identificar dispositivos desatualizados, não suportados ou sem patches

Em Zenith Controls, o controlo 8.8 da ISO/IEC 27002:2022, Gestão de Vulnerabilidades Técnicas, é mapeado como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, alinhado com Identify e Protect, tendo a gestão de ameaças e vulnerabilidades como capacidade operacional nos domínios Governance, Ecosystem, Protection e Defense.

Um ficheiro sólido de vulnerabilidades OT deve incluir:

• Identificador do ativo, proprietário, zona e criticidade
• Fonte da vulnerabilidade, como aviso do fornecedor, scanner, notificação do integrador ou informações sobre ameaças
• Restrições de segurança operacional e disponibilidade
• Viabilidade de aplicação de patch e janela de manutenção planeada
• Controlos compensatórios, como isolamento, Listas de Controlo de Acesso (ACLs), serviços desativados ou monitorização reforçada
• Aprovação do proprietário do risco e aceitação do risco residual
• Evidência de verificação após remediação ou implementação de controlo compensatório

Isto transforma “não conseguimos aplicar patches” de uma desculpa em tratamento de riscos auditável.

Acesso remoto de fornecedores: o ponto crítico entre NIS2 e IEC 62443

A maioria dos incidentes OT tem uma dimensão de terceiros em algum ponto. Uma conta de fornecedor. Um computador portátil de integrador. Uma ferramenta de manutenção remota. Uma credencial partilhada. Uma exceção de firewall que era temporária há três anos.

O NIS2 Article 21 inclui explicitamente segurança da cadeia de fornecimento, vulnerabilidades específicas de fornecedores, práticas de cibersegurança de fornecedores e procedimentos de desenvolvimento seguro. O NIST CSF 2.0 também é detalhado neste ponto, através da criticidade de fornecedores, requisitos contratuais, diligência prévia, monitorização contínua, coordenação de incidentes e disposições de saída.

A Third-Party and Supplier Security Policy - SME da Clarysec estabelece o princípio em linguagem simples:

Deve ser concedido aos fornecedores acesso apenas aos sistemas e dados mínimos necessários para executar a sua função.

Para OT, acesso mínimo significa mais do que acesso baseado em funções numa aplicação. O acesso de fornecedores deve ser:

• Pré-aprovado para uma finalidade de manutenção definida
• Limitado no tempo e desativado por defeito
• Protegido por MFA ou autenticação contínua, quando apropriado
• Encaminhado através de um servidor bastião seguro ou de uma plataforma de acesso remoto controlado
• Limitado à zona ou ativo OT relevante
• Registado em logs, monitorizado e, para acessos de alto risco, com gravação de sessões
• Revisto após a conclusão
• Coberto por obrigações contratuais de segurança e notificação de incidentes

A IoT / OT Security Policy empresarial inclui um requisito dedicado de acesso remoto:

O acesso remoto (para gestão ou assistência por fornecedores) deve:

Esta cláusula fixa o ponto de governação, enquanto os requisitos detalhados devem ser implementados em procedimentos de acesso, acordos com fornecedores, configuração técnica e fluxos de monitorização.

Em Zenith Controls, o controlo 5.21 da ISO/IEC 27002:2022, Gestão da segurança da informação na cadeia de fornecimento TIC, é classificado como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, alinhado com o conceito Identify, tendo a segurança das relações com fornecedores como capacidade operacional e Governance, Ecosystem e Protection como domínios.

Para OT, esse mapeamento ajuda a explicar por que motivo a evidência de acesso remoto pertence simultaneamente aos ficheiros de risco de fornecedor, governação de identidades, segurança de redes, resposta a incidentes e continuidade.

Resposta a incidentes: o relógio da NIS2 chega à sala de controlo

Regressemos ao alarme das 02:17. A organização tem de decidir se o evento é significativo ao abrigo da NIS2. O Article 23 exige notificação sem demora indevida de incidentes significativos que afetem a prestação de serviços. A sequência inclui um alerta inicial no prazo de 24 horas após a tomada de conhecimento, uma notificação de incidente no prazo de 72 horas, atualizações intermédias se solicitadas e um relatório final o mais tardar um mês após a notificação do incidente, ou um relatório de progresso se o incidente ainda estiver em curso.

Em OT, a resposta a incidentes deve responder a perguntas que os playbooks de TI frequentemente ignoram:

• O dispositivo afetado pode ser isolado sem criar risco de segurança operacional?
• Quem tem autoridade para parar a produção ou mudar para modo manual?
• Que logs são voláteis e precisam de preservação imediata?
• Que fornecedor ou integrador deve ser contactado?
• O evento é malicioso, acidental, ambiental ou causado por configuração incorreta?
• Poderá haver impacto transfronteiriço ou impacto em destinatários do serviço?
• Estão envolvidos dados pessoais, como logs de crachás, CCTV, dados de trabalhadores ou registos de atendimento a clientes?

A política OT para PME fornece uma regra simples de escalonamento de anomalias:

Quaisquer anomalias devem ser comunicadas imediatamente ao Diretor-Geral para ação adicional

Inclui também um princípio de contenção sensível à segurança operacional:

O dispositivo deve ser desligado da rede imediatamente, quando for seguro fazê-lo

Essas últimas cinco palavras são críticas. A resposta OT não pode copiar cegamente ações de contenção de TI. “Quando for seguro fazê-lo” deve refletir-se em runbooks, matrizes de escalonamento, formação e exercícios de simulação.

O NIST CSF 2.0 encaixa bem aqui. Os seus resultados Respond e Recover abrangem triagem, categorização, escalonamento, análise de causa raiz, integridade da evidência, notificação de partes interessadas, contenção, erradicação, restauro, verificações de integridade de cópias de segurança e comunicações de recuperação.

Construir uma linha de evidência do risco ao controlo

Uma forma prática de evitar conformidade fragmentada é construir uma linha única de evidência, do risco à regulamentação, ao controlo e à prova.

Cenário: um fornecedor remoto de compressores precisa de acesso a um posto de trabalho de engenharia na rede OT. O posto de trabalho pode modificar lógica PLC. A conta do fornecedor está sempre ativa, é partilhada por vários engenheiros do fornecedor e é protegida apenas por palavra-passe. O posto de trabalho executa software que não pode ser atualizado até à próxima paragem de manutenção.

Escreva o cenário de risco no registo de riscos:

“Um acesso remoto de fornecedor não autorizado ou comprometido ao posto de trabalho de engenharia OT pode levar a alterações não autorizadas de lógica PLC, interrupção de produção, impacto na segurança operacional e interrupção de serviço notificável ao abrigo da NIS2.”

Depois, mapeie os controlos e obrigações.

O plano de tratamento deve desativar o acesso permanente de fornecedores, exigir identidades nominativas de fornecedores, impor MFA, encaminhar o acesso através de um servidor bastião controlado, limitar o acesso ao posto de trabalho de engenharia, exigir aprovação por ticket de manutenção, gravar sessões privilegiadas, monitorizar comandos e tráfego anómalo, documentar o posto de trabalho sem patches como exceção de vulnerabilidade e testar a resposta a incidentes para atividade suspeita de fornecedor.

Zenith Blueprint, na fase Risk Management, Step 13, fornece a lógica de rastreabilidade da SoA:

Referencie regulamentos de forma cruzada: se determinados controlos forem implementados especificamente para cumprir o RGPD da UE, NIS2 ou DORA, pode assinalá-lo no Registo de Riscos (como parte da justificação do impacto do risco) ou nas notas da SoA.

A lição prática é simples. Não mantenha a evidência NIS2, ISO e de engenharia OT em silos separados. Acrescente colunas no registo de riscos e na SoA para tema do NIS2 Article 21, controlo ISO/IEC 27002:2022, família de requisitos IEC 62443, proprietário da evidência e estado de auditoria.

Onde entram o RGPD da UE e DORA na segurança OT

A segurança OT nem sempre se limita a máquinas. Ambientes de infraestruturas críticas tratam frequentemente dados pessoais através de CCTV, sistemas de controlo de acesso, logs de crachás, sistemas de segurança da força de trabalho, tickets de manutenção, rastreio de veículos, sistemas de visitantes e plataformas de atendimento a clientes.

O RGPD da UE exige que os dados pessoais sejam tratados de forma lícita, leal e transparente, recolhidos para finalidades específicas, limitados ao necessário, mantidos exatos, retidos apenas pelo tempo necessário e protegidos com medidas técnicas e organizativas adequadas. Exige também responsabilização, o que significa que o responsável pelo tratamento deve ser capaz de demonstrar conformidade.

Para OT, isto significa que logs de acesso e registos de monitorização não devem tornar-se repositórios de dados de vigilância sem controlo. A retenção, os direitos de acesso, a limitação da finalidade e a avaliação de violação devem ser concebidos no registo de eventos e na monitorização.

DORA pode aplicar-se quando estão envolvidas entidades financeiras ou quando um prestador terceiro de serviços TIC suporta a resiliência operacional do setor financeiro. DORA abrange gestão do risco TIC, notificação de incidentes, testes de resiliência e risco de terceiros TIC. Para entidades financeiras que também sejam entidades essenciais ou importantes ao abrigo das regras de transposição da NIS2, DORA pode atuar como regime setorial específico para obrigações sobrepostas, embora a coordenação com autoridades NIS2 possa continuar a ser relevante.

Aplicam-se as mesmas disciplinas de evidência: identificação de ativos, proteção, deteção, continuidade, cópias de segurança, risco de terceiros, testes, formação e supervisão pela gestão.

A perspetiva de auditoria: um controlo, várias perspetivas de garantia

Uma implementação forte de segurança OT no âmbito da NIS2 deve resistir a várias perspetivas de auditoria.

É por isso que a Clarysec trata Zenith Controls como uma bússola de conformidade cruzada. Os seus atributos de controlo ajudam a explicar a finalidade dos controlos oficiais da ISO/IEC 27002:2022, enquanto a abordagem de mapeamento liga esses controlos à NIS2, ao NIST CSF, à governação de fornecedores, à continuidade e à evidência de auditoria.

Armadilhas comuns na implementação OT NIS2

As falhas mais comuns de segurança OT raramente resultam da falta de documentos. Resultam de documentos que não correspondem à instalação.

Armadilha 1: a TI é proprietária do programa NIS2, mas a OT é proprietária do risco. Operações, engenharia, segurança operacional e manutenção devem estar envolvidas.

Armadilha 2: o inventário de ativos termina nos servidores. Um inventário OT deve incluir PLCs, RTUs, HMIs, historiadores, postos de trabalho de engenharia, switches industriais, sensores, gateways, appliances de acesso remoto e componentes geridos por fornecedores.

Armadilha 3: a segmentação existe num diagrama, mas não nas regras de firewall. Os auditores pedirão evidência de aplicação, controlo de alterações e monitorização.

Armadilha 4: as exceções de vulnerabilidades são informais. Restrições legadas só são aceitáveis quando documentadas, aprovadas, monitorizadas e revistas.

Armadilha 5: o acesso de fornecedores é tratado apenas como uma questão de fornecedor. Também é uma questão de controlo de acesso, registo de eventos, monitorização, segurança de redes, resposta a incidentes e continuidade.

Armadilha 6: a resposta a incidentes ignora a segurança operacional. Os playbooks OT devem definir quem pode isolar dispositivos, parar processos, mudar modos ou contactar reguladores.

Armadilha 7: o reporte NIS2 não é ensaiado. O processo de decisão de 24 horas e 72 horas deve ser testado antes de um evento real.

O caminho de implementação da Clarysec, da responsabilização do órgão de administração à evidência OT

Uma implementação prática de segurança OT no âmbito da NIS2 pode seguir esta sequência:

1. Confirmar o âmbito NIS2, a classificação da entidade e a criticidade do serviço.
2. Definir o âmbito OT dentro do SGSI, incluindo interfaces e dependências.
3. Construir um inventário de ativos OT e fluxos de dados.
4. Identificar obrigações legais, contratuais, de segurança operacional, privacidade e setoriais.
5. Realizar workshops de avaliação de riscos específicos de OT com engenharia, operações, TI, SOC, aquisição e gestão.
6. Mapear o tratamento de riscos para controlos ISO/IEC 27002:2022, temas NIS2 e padrões de implementação IEC 62443.
7. Atualizar a Declaração de Aplicabilidade com justificação OT e proprietários da evidência.
8. Implementar controlos prioritários: segmentação, acesso de fornecedores, tratamento de vulnerabilidades, monitorização, cópias de segurança e resposta a incidentes.
9. Atualizar políticas e procedimentos, incluindo segurança OT, segurança de fornecedores, acesso remoto, resposta a incidentes e continuidade de negócio.
10. Realizar exercícios de simulação e validação técnica.
11. Preparar pacotes de auditoria para NIS2, ISO/IEC 27001:2022, garantia para clientes e governação interna.
12. Integrar constatações na revisão pela gestão e na melhoria contínua.

Isto reflete o modelo operacional do Zenith Blueprint, especialmente o Step 13 para tratamento de riscos e rastreabilidade da SoA, o Step 14 para desenvolvimento de políticas e referências cruzadas regulamentares, o Step 19 para gestão de vulnerabilidades e o Step 20 para segurança de redes.

A mesma abordagem utiliza políticas da Clarysec para transformar linguagem de referenciais em regras operacionais. A IoT / OT Security Policy empresarial exige revisão da arquitetura de segurança antes da implementação:

Todos os novos dispositivos IoT/OT devem passar por uma Revisão da Arquitetura de Segurança antes da implementação. Esta revisão deve validar:

Também estabelece:

Todo o tráfego dentro e entre redes IoT/OT deve ser continuamente monitorizado utilizando:

Estas cláusulas criam âncoras de governação. A evidência de implementação pode incluir alertas IDS OT, logs de firewall, correlação SIEM, perfis de tráfego de referência, tickets de anomalias e registos de resposta.

Como é uma boa evidência OT NIS2

Um pacote de evidência OT NIS2 deve ser suficientemente prático para engenheiros e suficientemente estruturado para auditores.

Para segmentação, inclua arquitetura aprovada, diagramas de zonas e condutas, exportações de regras de firewall, registos de alteração, revisões periódicas de regras, registos de exceções e alertas de monitorização.

Para acesso de fornecedores, inclua avaliação da criticidade do fornecedor, cláusulas contratuais, procedimento de acesso aprovado, contas nominativas, evidência de MFA, logs de acesso, gravações de sessão, revisão periódica de acesso e registos de offboarding.

Para gestão de vulnerabilidades, inclua inventário, fontes de avisos, resultados de descoberta passiva, tickets de vulnerabilidades, planos de aplicação de patches, controlos compensatórios, aceitação do risco e evidência de encerramento.

Para resposta a incidentes, inclua playbooks, contactos de escalonamento, árvore de decisão de reporte NIS2, resultados de exercícios de simulação, tickets de incidentes, minutas de notificação à autoridade, regras de tratamento de evidência e lições aprendidas.

Para continuidade, inclua estratégia de cópias de segurança OT, cópias de segurança offline ou protegidas, resultados de testes de restauro, lista de peças sobresselentes críticas, procedimentos operacionais manuais, prioridades de recuperação e planos de comunicação de crise.

Para governação, inclua aprovação do órgão de administração ou da gestão, atribuições de funções, registos de formação, resultados de auditoria interna, KPIs, atas de revisão de risco e decisões de revisão pela gestão.

Este modelo de evidência está alinhado com a ISO/IEC 27001:2022 porque suporta tratamento de riscos, informação documentada, avaliação de desempenho e melhoria contínua. Está alinhado com a NIS2 porque demonstra medidas adequadas e proporcionais. Está alinhado com a IEC 62443 porque pode ser rastreado até à arquitetura OT e aos controlos de engenharia.

Transforme o seu programa de segurança OT em preparação auditável para a NIS2

Se o seu ambiente OT suporta um serviço crítico ou regulado, esperar que um regulador, cliente ou incidente exponha as lacunas é a estratégia errada.

Comece por um caso de utilização de alto impacto: acesso remoto de fornecedor a uma zona OT crítica, tratamento de vulnerabilidades em ativos industriais não suportados ou segmentação entre TI empresarial e OT. Construa o cenário de risco, mapeie-o para o NIS2 Article 21, selecione controlos ISO/IEC 27002:2022, traduza-os em padrões de implementação IEC 62443 e recolha a evidência.

A Clarysec pode ajudar a acelerar esse trabalho com Zenith Blueprint, Zenith Controls, a IoT / OT Security Policy, a Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME e a Third-Party and Supplier Security Policy - SME.

A sua próxima ação: escolha um serviço OT, mapeie os respetivos ativos e dependências, e crie esta semana uma linha de evidência do risco ao controlo. Se pretende um caminho de implementação estruturado, o roteiro de 30 passos e o conjunto de ferramentas de conformidade cruzada da Clarysec podem transformar essa primeira linha num programa completo de segurança OT no âmbito da NIS2.