NIS2 em profundidade: gestão de patches e vulnerabilidades em ambiente OT

O engenheiro de manutenção olha para o CLP que controla a estufa de acabamentos e diz o que todos os planos de segurança fingem não ouvir: "Isto não se toca. Está a rodar desde 2011 e o fornecedor já nem existe." O firmware tem uma vulnerabilidade conhecida, publicada, com CVE atribuído. E a fábrica não vai parar para aplicar patch a um controlador que gere uma linha em produção 24/5. Os artigos sobre controlos técnicos NIS2 e sobre arquitetura de rede OT/IT dizem o quê. Neste artigo, o como — gestão de patches e vulnerabilidades em ambiente OT sob NIS2 — é resolvido em detalhe técnico e operacional.

A tese, para quem já leu os anteriores e ainda está a decidir: em OT, a resposta à maioria das vulnerabilidades não é o patch — é a compensação. Quem entra numa fábrica com um calendário de patch Tuesday à IT falha em três meses. A NIS2 não exige que você aplique todos os patches. Exige que você saiba o que tem, meça o risco de cada item e decida com registo auditável quando não aplica. É um sistema de decisão, não um sistema de atualização. Quem inverte esta ordem passa o ano a lutar com a produção — e continua vulnerável.

Há uma segunda razão pela qual este artigo existe. A maioria das fábricas do Norte que caem no âmbito da NIS2 descobriu-o há pouco tempo, e descobriu-o mal — com um consultor de IT genérico a propor um agente de patching em cada máquina. Esse agente não corre no CLP. Não corre no HMI com Windows XP embutido. Não corre no PC industrial cujo fabricante proíbe contratualmente qualquer alteração ao sistema operativo sob pena de perda de garantia. O consultor de IT genérico nunca viu uma estufa de estamparia. Nós vimos dezenas. A diferença entre uma abordagem de IT transplantada para OT e uma abordagem nascida em OT é a diferença entre um relatório de conformidade e uma linha parada.

1. Arquitetura recomendada

Uma linha de acabamentos no Vale do Ave tem, tipicamente, três gerações de tecnologia a coexistir: PCs Windows XP embutidos em máquinas de estamparia, CLPs de meados dos anos 2000 e HMIs recentes com Linux. Nenhum sistema único gere patches nestes três mundos. A arquitetura tem de ser desenhada por camadas — e a decisão fundadora é: o inventário não pode ser ativo em OT durante produção.

Convém enquadrar a escala do problema antes de desenhar a solução. Uma fábrica têxtil média do Vale do Ave, com fiação, tricotagem e acabamentos, chega facilmente a 80–150 ativos com endereço IP na rede de processo — sem contar sensores analógicos e atuadores mudos. Uma unidade de injeção plástica com robots de manipulação e periféricos de controlo de temperatura ultrapassa os 200. E nenhum destes números aparece no inventário contabilístico do ERP MULTI, porque para a contabilidade uma linha de acabamentos é um ativo fixo, uma rubrica. Para a segurança são quarenta pontos de comunicação, cada um com o seu firmware, o seu fornecedor, o seu ciclo de vida.

Descoberta passiva primeiro, ativa em janela

Ferramentas de descoberta de IT fazem varrimento ativo — enviam pacotes, interrogam portas. Num CLP antigo, um simples port scan pode congelar o controlador. Vimos uma linha de injeção plástica parar 40 minutos porque um scan de rotina saturou a pilha TCP/IP de um HMI. A regra é dura:

Em OT, o inventário faz-se a ouvir o tráfego, não a bater à porta. Descoberta ativa só em janela de paragem planeada, e nunca contra o CLP diretamente.

A camada de descoberta passiva liga-se a portas SPAN/mirror dos switches industriais e reconstrói o inventário a partir do tráfego Modbus, PROFINET, EtherNet/IP e S7comm. Extrai fabricante, modelo, versão de firmware e — o mais valioso — o mapa de comunicações. Esse mapa é a base para o zero trust em redes OT: só se pode microssegmentar o que se conhece.

A razão técnica pela qual a descoberta passiva funciona em OT e a ativa não tem a ver com a natureza dos protocolos industriais. Modbus, PROFINET e S7comm foram desenhados nos anos 90 e 2000 para redes fechadas, deterministas, onde ninguém falava fora do guião. Não têm autenticação, não têm cifra, e muitos CLPs têm pilhas TCP/IP minimalistas que assumem que só recebem pacotes bem-formados de um SCADA conhecido. Um scanner de vulnerabilidades moderno envia dezenas de sondas malformadas por segundo para detetar serviços. Para um CLP de 2006, isso é indistinguível de um ataque de negação de serviço — e o resultado é o mesmo: o watchdog dispara e o controlador reinicia. Com a linha em produção.

As quatro camadas

• Descoberta OT passiva — sensor por célula/linha, ligado a SPAN, sem endereço IP na rede de processo (interface de gestão isolada).
• Correlação de vulnerabilidades — cruza inventário com bases CVE/ICS-CERT e avisos de fornecedor (Siemens ProductCERT, Rockwell, Schneider).
• Gestão de patches IT — WSUS/servidor de atualizações para os PCs e HMIs Windows/Linux que a segurança do fornecedor permita atualizar.
• Registo de decisão — onde vive a compensação: cada CVE não corrigido tem uma entrada com controlo compensatório e aprovação. É isto que a autoridade competente pede numa auditoria NIS2.

O erro clássico é comprar a plataforma de descoberta e nunca construir a quarta camada. Fica-se com uma lista bonita de 400 vulnerabilidades e zero decisões documentadas. A auditoria não pergunta quantas vulnerabilidades tem — pergunta o que decidiu sobre cada uma.

O modelo Purdue e onde as camadas assentam

Quem desenha esta arquitetura sem referência ao modelo Purdue (a norma de facto para segmentação de redes industriais, base da ISA/IEC 62443) acaba com sensores no sítio errado. O modelo estratifica a fábrica em níveis: nível 0 são os sensores e atuadores físicos; nível 1 os controladores (CLP, DCS); nível 2 a supervisão local (SCADA, HMI); nível 3 as operações de fábrica (MES, historian); e o nível 4/5 a IT corporativa. A descoberta passiva vive nos níveis 1 e 2 — é aí que passa o tráfego de processo que interessa observar. O servidor de patches convencional só toca legitimamente nos níveis 2 (parte Windows/Linux) e 3. Confundir estes limites é a raiz da maioria dos incidentes que descrevemos na secção 5.

A pergunta certa não é "que ferramenta de patching compro?". É "que tráfego atravessa a fronteira entre o nível 3 e o nível 2, e quem autorizou cada fluxo?". Responda a isso e metade do trabalho de conformidade está feito.

Zona desmilitarizada industrial: o buffer que a NIS2 pressupõe

Entre o nível 3 e a IT corporativa deve existir uma zona desmilitarizada industrial (IDMZ). Nenhum fluxo atravessa diretamente da rede de escritórios para a rede de processo — passa sempre por um sistema intermédio nesta zona-tampão. É aqui que assentam o servidor de patches (que descarrega atualizações da internet e as serve internamente sem que o CLP toque na internet), o servidor de saltos (jump host) para acesso de manutenção remota, e o coletor que exporta a postura de risco para o Qlik Sense. A IDMZ não é opcional numa arquitetura NIS2 credível. É o ponto onde a compensação por segmentação — que veremos ser a resposta dominante em OT — deixa de ser uma regra de firewall isolada e passa a ser uma decisão arquitetural.

2. Parâmetros, métricas e thresholds

A NIS2 (Diretiva (UE) 2022/2555, transposta pelo Decreto-Lei n.º 65/2025) não fixa SLAs de patching. Fixa a obrigação de gerir risco de forma proporcional. Os números seguintes são os que usamos como referência operacional em OT industrial — não são de IT genérico e não devem ser.

Porque 90 dias e não 30

Uma linha de acabamentos que só para no domingo à noite, uma vez por mês, tem uma janela de paragem real de talvez seis horas mensais — partilhadas com manutenção mecânica, limpeza e TPM. Exigir patch de OT em 30 dias é ignorar a física da fábrica. Os 90 dias reconhecem a realidade e, crucialmente, obrigam à compensação no intervalo. O patch pode esperar; a mitigação não.

Vale a pena fazer as contas de forma explícita, porque é o argumento que convence o plant manager. Se a linha para seis horas por mês, e dessas seis horas a manutenção mecânica preventiva absorve três, a limpeza técnica uma, e a validação de qualidade do primeiro lote pós-arranque outra, sobra uma hora para atividades de TI/OT. Aplicar um patch de firmware a um CLP, com o teste de comunicação subsequente e o rollback preparado, raramente cabe em menos de noventa minutos por controlador. Ou seja: numa fábrica típica, você consegue aplicar patch a talvez um controlador por mês sem perturbar produção. Com trinta CLPs, um ciclo completo demora dois anos e meio. É por isto que a compensação não é preguiça — é aritmética.

CVSS mente em OT

O custo total de tratar cada CVE pela sua pontuação CVSS é insustentável. O CVSS assume exploração pela rede — mas um CLP numa célula microssegmentada, sem rota para a rede corporativa, tem risco efetivo muito abaixo do CVSS nominal. Reordene por exploitabilidade real no seu ambiente: existe rota de rede? há exploit público? o ativo controla segurança de pessoas? Um CVSS 9.8 num controlador isolado atrás de duas firewalls é menos urgente do que um CVSS 6.5 num HMI acessível a partir da rede de escritórios.

Priorizar por CVSS puro em OT é como priorizar manutenção por ordem alfabética da máquina. Tecnicamente é uma ordem. Operacionalmente é um disparate.

Um modelo de risco efetivo que sobrevive à auditoria

O auditor NIS2 vai perguntar como é que você chega de um CVSS nominal a uma decisão. Precisa de um modelo defensável, escrito, aplicado consistentemente. O que usamos combina quatro fatores multiplicativos sobre a base CVSS: rota de rede (o atacante consegue alcançar o ativo a partir de uma zona menos confiável?), disponibilidade de exploit (existe código público ou está em kits ativos?), consequência de segurança física (o ativo controla um processo que, comprometido, pode ferir pessoas — uma prensa, uma estufa a 200 °C?), e capacidade de deteção (se for explorado, você dá por isso?). O resultado não é um número mais preciso — é uma priorização honesta que separa os cinco CVE que interessam dos quatrocentos que não interessam esta semana.

Métricas que o trio CEO+CFO+IT entende

O responsável de IT self-made da fábrica não quer um relatório de 400 páginas. Quer três indicadores que caibam num ecrã de Qlik Sense e que respondam à pergunta do CEO: "estamos protegidos ou não?". Os que funcionam: percentagem de ativos OT com decisão documentada (meta 100% dos críticos); número de compensações vencidas por reavaliar (meta zero); e idade média da última reconciliação de inventário por célula. Estes três dizem, sem jargão, se o sistema está vivo ou se é documentação de gaveta. Um CFO percebe a segunda métrica em cinco segundos — cada compensação vencida é um risco aceito por ninguém, o pior tipo de risco.

3. Configuração prática

Três exemplos ilustrativos. Não são credenciais nem topologias reais — são padrões que aplicamos.

Regra de firewall como controlo compensatório

Quando um CLP tem CVE crítico sem patch disponível, a compensação típica é reduzir a superfície de comunicação ao estritamente necessário. Numa firewall industrial, a regra explícita — default deny, permitir só o par SCADA↔CLP no porto do protocolo:

# Compensação para CVE-XXXX-YYYY no CLP da linha 3 (sem patch do fornecedor)
Só o servidor SCADA fala com o CLP, só em Modbus/TCP (502). Tudo o resto bloqueado.
set rule "compensa-clp-linha3" from zone OT-SCADA to zone OT-CELULA-3 \
    source 10.20.10.5 destination 10.20.30.11 \
    service tcp/502 action allow log enabled
set rule "deny-celula-3-default" from zone any to zone OT-CELULA-3 \
    action deny log enabled
Referência ao registo de decisão: ticket NIS2-2025-0142

Repare no log enabled em ambas as regras. Não é decoração. O log da regra allow confirma que o SCADA está mesmo a falar com o CLP como esperado — se parar de gerar entradas, algo mudou. O log da regra deny é o seu sistema de deteção: qualquer entrada aqui significa que algo tentou alcançar a célula fora do fluxo autorizado. Numa arquitetura sem monitorização passiva dedicada, estes dois logs são o mínimo viável de deteção, e a autoridade competente vai querer ver que são recolhidos e revistos.

Deep packet inspection do protocolo industrial

A firewall industrial moderna faz mais do que filtrar por IP e porto — inspeciona o conteúdo do protocolo. Uma regra de compensação mais forte não permite apenas Modbus/TCP para o CLP; permite apenas funções de leitura de Modbus, bloqueando escritas não autorizadas. Se o SCADA só precisa de ler estados e o CLP não deve receber comandos daquela origem, restringir aos function codes de leitura reduz drasticamente a superfície mesmo com o CVE por corrigir:

# Compensação reforçada: permitir só leituras Modbus do coletor de dados
Function codes 3 (Read Holding Registers) e 4 (Read Input Registers)
set rule "leitura-clp-linha3" from zone OT-HISTORIAN to zone OT-CELULA-3 \
    source 10.20.10.9 destination 10.20.30.11 \
    service modbus modbus-function 3,4 action allow log enabled
Escritas (function 5,6,15,16) implicitamente negadas pelo default deny

Descoberta passiva — configuração do espelhamento de porta

# Switch industrial gerido: espelhar tráfego da célula para o sensor de descoberta
O sensor NÃO tem IP na VLAN de processo — só recebe cópia do tráfego
monitor session 1 source interface Gi1/0/1 - 8 rx
monitor session 1 destination interface Gi1/0/24
Gi1/0/24 liga ao sensor de descoberta OT (interface de captura, sem TX)

Entrada no registo de decisão (esquema)

O registo de decisão é o artefacto que a auditoria NIS2 quer ver. Mantenha-o versionado e imutável — idealmente no fluxo de aprovação da sua Gestão Documental, com assinatura qualificada eIDAS de quem aprova o risco residual.

{
  "cve": "CVE-XXXX-YYYY",
  "ativo": "CLP-LINHA3-ESTUFA",
  "cvss_nominal": 9.1,
  "risco_efetivo": "MEDIO",         // reavaliado por exploitabilidade real
  "patch_disponivel": false,
  "decisao": "COMPENSAR",           // PATCH | COMPENSAR | ACEITAR
  "compensacao": "segmentacao + regra firewall NIS2-2025-0142",
  "reavaliar_em": "2025-09-30",
  "aprovado_por": "responsavel_seguranca",
  "assinatura_eidas": "presente"
}

Porque a assinatura eIDAS não é burocracia

Um responsável de segurança que aceita risco residual sobre um CLP que controla uma estufa a 200 °C está a assumir uma responsabilidade pessoal e organizacional concreta. A NIS2 responsabiliza o órgão de gestão — no artigo relativo à governação, a diretiva torna a administração diretamente responsável pela supervisão das medidas de gestão de risco, com possibilidade de responsabilização pessoal. A assinatura qualificada eIDAS na entrada do registo de decisão faz duas coisas: prova quando a decisão foi tomada (carimbo temporal) e por quem, com valor legal equivalente a assinatura manuscrita. Numa auditoria ou, pior, num pós-incidente, a diferença entre "decidimos compensar em março, assinado pelo responsável" e "está algalgures numa folha de cálculo" é a diferença entre demonstrar diligência e não a conseguir provar.

4. Integrações e dependências

Nenhuma destas peças funciona isolada. O valor está na cadeia — e a cadeia tem pontos de falha específicos.

A dependência que ninguém antecipa: o calendário de paragens de produção. Se o sistema de patches não conhece a janela de paragem real, agenda atualizações que a produção cancela na véspera. Integrar o plano de manutenção — o mesmo que alimenta o TPM — com o calendário de patching elimina 80% do atrito entre segurança e chão-de-fábrica. Sem esta ligação, o CISO e o plant manager passam o ano a discutir por email.

A dependência do fornecedor de máquina — e da sua cláusula de garantia

Há uma dependência contratual que raramente aparece nos diagramas de arquitetura e que faz descarrilar projetos inteiros: o contrato de fornecimento da máquina. Muitos fabricantes de equipamento industrial — em estamparia, injeção plástica, corte automático de calçado — vendem a máquina com o PC de controlo como caixa fechada. Qualquer alteração ao sistema operativo, incluindo patches de segurança da Microsoft, invalida a garantia e, pior, o contrato de manutenção. O responsável de segurança quer aplicar o patch; o diretor de produção lembra que se a máquina avariar, o fornecedor recusa a intervenção porque "mexeram no sistema". Esta tensão resolve-se de uma de três formas: negociar com o fornecedor uma lista de patches autorizados (o melhor caso, cada vez mais comum sob pressão da NIS2 no cliente); compensar por rede quando o fornecedor não colabora; ou substituir o equipamento no próximo ciclo de investimento, exigindo no caderno de encargos suporte a atualizações de segurança. Escreva esta cláusula em todos os novos contratos de máquina. É a decisão mais barata que vai tomar.

Manutenção remota do fornecedor: a porta que fica escancarada

A via de comprometimento mais comum em OT industrial não é o CVE exótico — é o acesso remoto de manutenção do fornecedor da máquina. O técnico da marca liga-se de outro país para diagnosticar uma avaria, e para isso alguém abriu um túnel VPN há três anos que nunca mais se fechou. Muitas vezes com credenciais partilhadas, sem MFA, sem log de sessão. Esta é uma vulnerabilidade que não tem CVE e não aparece em nenhuma base de dados — mas é a que os relatórios de incidentes em sistemas de controlo industrial associam repetidamente às intrusões mais graves. A compensação: todo o acesso remoto passa por um jump host na IDMZ, com MFA, sessão gravada, e ativado apenas por pedido, janela temporal fechada. Sem exceções para "o fornecedor precisa de acesso permanente". Não precisa.

A firewall industrial mais bem configurada do Norte foi contornada por um técnico que se ligou por TeamViewer instalado num PC de controlo "para ser mais rápido no próximo problema". A superfície de ataque que interessa raramente é a que está no relatório de vulnerabilidades.

5. Armadilhas operacionais

O que vimos partir em produção, anonimizado, com a correção.

• Scan ativo contra CLP em produção. Uma fábrica de moldes fez varrimento de vulnerabilidades "de rotina" às 15h. Dois controladores reiniciaram. Correção: descoberta passiva sempre; ativa só em paragem e nunca contra o controlador — contra a rede à volta dele.
• Patch Windows automático em HMI validado. Uma atualização cumulativa da Microsoft quebrou o driver de comunicação de um HMI de estamparia; a linha ficou cega ao processo. Correção: excluir HMIs do WSUS automático, testar em ambiente espelho, aplicar em janela.
• Inventário feito uma vez e nunca reconciliado. Passados oito meses, 30% dos ativos tinham firmware diferente do registado — manutenção trocou peças. Correção: reconciliação contínua passiva, não um Excel de projeto.
• Lista de CVE sem registo de decisão. Auditoria pediu a decisão sobre um CVE específico; a resposta foi "está na lista". Não chega. Correção: cada item crítico tem decisão datada, assinada e reavaliável.
• Firewall industrial em modo allow-all "temporário". O "temporário" durou três anos porque ninguém sabia que regras a produção precisava. Correção: derivar as regras do mapa de comunicações da descoberta passiva — o próprio sistema diz o que é legítimo.
• Compensação sem data de reavaliação. Uma regra de firewall como mitigação ficou eterna; o fornecedor lançou patch e ninguém o aplicou. Correção: toda a compensação tem reavaliar_em obrigatório.
• Sensor de descoberta com IP na rede de processo. Instalado "para ser mais fácil de gerir", tornou-se ele próprio superfície de ataque na VLAN mais crítica. Correção: interface de captura sem TX, gestão numa VLAN separada.

Duas armadilhas menos óbvias

Há duas falhas que só aparecem em fábricas mais maduras, já com plataforma de descoberta instalada, e que por isso enganam quem se julga a salvo. A primeira: o sensor de descoberta que não vê a VLAN toda porque o SPAN foi mal configurado. O switch espelha oito portas, mas a célula tem doze dispositivos e quatro estão noutro switch em cascata sem mirror configurado. O inventário parece completo — cobre 100% do que o sensor vê — mas há um terço da célula invisível. Correção: validar a cobertura do SPAN contra o número de dispositivos físicos contados no chão, não contra o que o sensor reporta.

A segunda: o firmware que o fornecedor "corrigiu" mas nunca comunicou por CVE. Muitos fabricantes de CLP corrigem vulnerabilidades silenciosamente numa nova revisão de firmware, sem publicar aviso nem atribuir CVE. A sua base de vulnerabilidades cruza inventário com CVE conhecidos e nada assinala — mas você está a correr firmware vulnerável para o qual já existe correção há dois anos. Correção: subscrever diretamente os boletins dos ProductCERT dos seus fornecedores principais (Siemens, Rockwell, Schneider) e reconciliar as versões de firmware do inventário com as últimas revisões disponíveis, independentemente de haver CVE.

A pior vulnerabilidade de OT que encontrámos não estava no CLP. Estava na convicção de que o inventário do projeto de 2022 ainda descrevia a fábrica de 2025.

6. Decisão técnica final

Sem hedging. A escolha muda com a dimensão e o setor.

A regra que atravessa a tabela: abaixo de 30 ativos, invista em arquitetura de rede antes de comprar ferramenta; acima de 200, o processo manual falha e precisa de SIEM. No meio — a maioria das fábricas do Norte — a combinação de descoberta passiva, compensação por firewall e registo de decisão assinado é o ponto ótimo entre custo e defensabilidade em auditoria. Ligue tudo à sua estratégia de Business Continuity e teste-a como descrevemos no disaster recovery em fábrica: um sistema de gestão de vulnerabilidades que nunca foi exercitado é documentação, não defesa.

A questão do enquadramento: é você entidade essencial ou importante?

Antes de dimensionar qualquer investimento, resolva uma pergunta prévia que muitos saltam: em que categoria NIS2 cai a sua empresa? A diretiva distingue entidades essenciais de entidades importantes, com regimes de supervisão e coimas diferentes, e o enquadramento depende do setor e da dimensão. Uma boa parte da indústria transformadora — incluindo fabrico de certos produtos — entra no âmbito consoante o critério de dimensão (o limiar geral situa-se em empresas com pelo menos 50 trabalhadores ou volume de negócios/balanço acima de 10 milhões de euros). Muitas fábricas do Norte, que sempre se viram como "demasiado pequenas para isto", estão dentro. Confirme o seu enquadramento com o CNCS ou com apoio jurídico especializado antes de decidir o nível de investimento — porque a categoria determina o rigor das obrigações e o peso das coimas em caso de incumprimento.

A ordem de investimento que evita desperdício

Se orçamento é limitado — e em PME industrial é sempre — a ordem importa mais do que o total. Primeiro: segmentação de rede e fecho dos acessos remotos permanentes. É a intervenção com maior redução de risco por euro, e não depende de comprar plataforma nenhuma. Segundo: inventário passivo, nem que seja com um sensor por linha crítica, para saber o que tem. Terceiro: o registo de decisão, mesmo que comece estruturado em Gestão Documental com assinatura eIDAS antes de haver plataforma automática. Só depois, quando o volume justificar, a plataforma de descoberta OT dedicada e o SIEM. Inverter esta ordem — comprar a plataforma cara primeiro, com a rede ainda plana e os acessos remotos abertos — é o erro que vemos financiado por candidaturas mal desenhadas: gasta-se o subsídio na ferramenta visível e deixa-se a arquitetura, que é o que realmente protege, para "a fase 2" que nunca chega.

Financiamento: o que passa e o que fica preso no relatório técnico

A cibersegurança industrial é elegível em vários instrumentos do PT2030 e do PRR, sobretudo quando enquadrada em projetos de transição digital da indústria (Indústria 4.0) e não como despesa de IT isolada. O que costuma passar: investimento em equipamento de rede segmentada, plataformas de monitorização OT e serviços de implementação, quando ligados a um objetivo produtivo mensurável — reduzir paragens não planeadas, garantir continuidade, cumprir requisitos de cliente internacional. O que fica preso no relatório técnico: candidaturas que descrevem "melhorar a segurança" sem indicador de impacto, sem baseline, sem ligação ao processo produtivo. Escreva a candidatura à volta do OEE e da continuidade de produção, com o KORA Productivity a fornecer a linha de base, e a componente de cibersegurança entra como habilitadora — não como fim em si. É esta a diferença entre aprovação e o eterno pedido de esclarecimentos adicionais.

7. Como a INFOS implementa

Trabalhamos a gestão de patches e vulnerabilidades OT dentro do serviço de cibersegurança e da arquitetura de rede, ancorados no que já conhecemos da fábrica através do ERP MULTI e do KORA Productivity no chão-de-fábrica — o que nos dá o calendário de paragens real para agendar sem parar produção. O registo de decisão vive na Gestão Documental com assinatura eIDAS, e a postura de risco fica visível em Qlik Sense para o trio CEO+CFO+IT que decide. Não vendemos uma lista de vulnerabilidades. Entregamos um sistema de decisão auditável para o setor industrial português.

O que nos distingue de um integrador de segurança genérico é o ponto de partida. Chegamos à sua fábrica já sabendo o que é uma coleção de 800 SKUs em calçado, o que significa "fim de mês" numa confeção perto de Famalicão, e porque é que o chefe de armazém não sai do rádio duas horas para um rollout. Essa fluência industrial faz com que a compensação que propomos respeite a física da produção — em vez de a combater. A NIS2 não é um projeto de conformidade que se despacha e arquiva. É um sistema vivo de decisão que tem de conviver com estufas de 2011, HMIs com XP embutido e uma janela de paragem de seis horas por mês. Quem desenha ignorando isto entrega um relatório. Quem desenha respeitando isto entrega defesa que se mantém no dia em que ninguém está a olhar.

Fontes

• Diretiva (UE) 2022/2555 (NIS2), Jornal Oficial da União Europeia; transposição nacional pelo Decreto-Lei n.º 65/2025, Diário da República.
• CNCS — Centro Nacional de Cibersegurança / CERT.PT, Relatório de incidentes 2024.
• IBM, Cost of a Data Breach Report 2024.
• Verizon, Data Breach Investigations Report (DBIR) 2025.
• ISC2, Cybersecurity Workforce Study 2024.
• ENISA / ICS-CERT (CISA), avisos de vulnerabilidades em sistemas de controlo industrial.
• ISA/IEC 62443, série de normas para segurança de sistemas de automação e controlo industrial.

Perguntas frequentes

O que é descoberta passiva em OT e por que é preferível à descoberta ativa?

Descoberta passiva observa o tráfego existente na rede industrial sem enviar sondas. Ferramentas ativas enviam pacotes que podem congelar CLPs antigos ou saturar a pilha TCP/IP, parando linhas de produção. Em OT, o inventário reconstrói-se a partir do tráfego Modbus, PROFINET e S7comm, extraindo fabricante, modelo e versão de firmware sem risco operacional.

Por que razão um port scan pode parar uma linha de produção?

CLPs antigos têm pilhas TCP/IP minimalistas que assumem apenas pacotes bem-formados de fontes conhecidas. Um scanner moderno envia dezenas de sondas malformadas por segundo. Para o CLP, isto é indistinguível de ataque de negação de serviço, acionando o watchdog que reinicia o controlador — parando a produção.

A NIS2 obriga a aplicar todos os patches em ambiente OT?

Não. A NIS2 exige que você saiba o que tem, meça o risco de cada vulnerabilidade e decida com registo auditável quando não aplica. A maioria das vulnerabilidades em OT é resolvida por compensação, não por patch. O regulador avalia as decisões documentadas, não o número de patches aplicados.

O que é um controlo compensatório na gestão de vulnerabilidades OT?

É uma medida alternativa ao patch quando a atualização não é viável operacionalmente. Exemplos: microssegmentação de rede, monitorização comportamental, restrição de acesso. Cada CVE não corrigido deve ter uma entrada documentada com o controlo compensatório e aprovação — isto é o que a auditoria NIS2 verifica.

Qual é a escala típica de ativos IP numa fábrica do Vale do Ave?

Uma fábrica têxtil média com fiação, tricotagem e acabamentos atinge 80–150 ativos com endereço IP na rede de processo, sem contar sensores analógicos. Uma unidade de injeção plástica ultrapassa os 200. Estes números não aparecem no ERP contabilístico porque a contabilidade vê a linha como um ativo fixo, a segurança como quarenta pontos de comunicação distintos.

Como se estrutura a arquitetura de gestão de patches em OT?

Em quatro camadas: descoberta passiva por célula/linha; correlação de vulnerabilidades com bases CVE/ICS-CERT; gestão de patches para sistemas Windows/Linux que o fornecedor permite atualizar; registo de decisão documentando cada CVE não corrigido com controlos compensatórios. O erro clássico é parar na primeira camada, deixando vulnerabilidades sem decisão auditável.

Por que um agente de patching genérico de IT não funciona em OT?

Agentes não correm em CLPs, HMIs com Windows XP embutido ou PCs industriais cujos fabricantes proíbem alterações ao SO sob pena de perda de garantia. Uma abordagem nascida em OT, desenhada por camadas e respeitando as limitações operacionais, evita paragens de linha e mantém a conformidade regulatória.

O que é o modelo Purdue e qual é a sua relevância para descoberta de vulnerabilidades?

O modelo Purdue estratifica a fábrica em níveis: sensores/atuadores (0), controladores (1), supervisão local (2), operações (3) e IT corporativa (4/5). A descoberta passiva opera nos níveis 1 e 2, onde passa o tráfego de processo relevante. Desenhar a arquitetura sem esta referência coloca sensores no sítio errado e compromete a segmentação.