O fluxo « USB » para o OT: Por que razão o prazo de comunicação da CRA começa no portão da fábrica

A partir de 11 de setembro de 2026, a Lei de Resiliência Cibernética (CRA) da UE concede aos fabricantes 24 horas para comunicarem uma vulnerabilidade que esteja a ser ativamente explorada. Em ambientes de OT (Tecnologia Operacional), os incidentes mais suscetíveis de acionar esse prazo chegam numa unidade de armazenamento « USB », e a maioria dos operadores ainda não consegue dizer para onde essa unidade foi a seguir.

A partir de 11 de setembro de 2026, os fabricantes de produtos com elementos digitais vendidos na UE terão de comunicar vulnerabilidades ativamente exploradas e incidentes de segurança graves. O prazo é rigoroso: um aviso prévio no prazo de 24 horas após a deteção, uma notificação completa no prazo de 72 horas e um relatório final no prazo de 14 dias após a disponibilização de uma medida corretiva para as vulnerabilidades ativamente exploradas, ou no prazo de um mês no caso de incidentes graves.

Repare no que está na base de tudo isto: a tomada de consciência. Todos os prazos previstos no regulamento pressupõem que é possível detetar o incidente, reconstruir o que aconteceu e descrever a medida corretiva. Trata-se de um problema de documentação e telemetria muito antes de se tornar uma questão jurídica. E a obrigação abrange tanto o passado como o futuro, uma vez que se aplica a produtos já colocados no mercado da UE, e não apenas aos que forem comercializados após a CRA entrar plenamente em vigor, em dezembro de 2027.

Para quem gere ou forneça ambientes industriais e de OT, isto revela uma lacuna preocupante. A via mais provável de dar origem a um incidente passível de notificação na OT é também a que apresenta menos instrumentação: os suportes removíveis. A boa notícia é que se trata de um problema de engenharia solucionável, com três medidas de controlo bem conhecidas: um ponto de inspeção obrigatório no perímetro, a transferência unidirecional entre zonas imposta pelo hardware e a transferência gerida que regista todos os movimentos. As três são necessárias, e a ordem em que são aplicadas é importante.

A investigação da Honeywell sobre cibersegurança industrial revelou que 51% do malware analisado foi concebido para se propagar através de dispositivos « USB », um aumento em relação aos 9% registados cinco anos antes. O seu relatório sobre ameaças para 2025 revelou que um em cada quatro incidentes tratados pela sua equipa de resposta envolveu um evento «plug-and-play» de « USB », normalmente quando alguém liga uma unidade de armazenamento que, por sua vez, propaga malware no ambiente. Os suportes removíveis tornaram-se um dos vetores de acesso inicial mais fiáveis para ambientes ICS (Industrial Control Systems — Sistemas de Controlo de Infraestruturas Críticas), precisamente porque contornam todos os controlos de rede em que um operador tenha investido.

Os organismos de normalização alertaram para isto há anos. A norma NIST SP 800-82 Rev. 3, o «Guia para a Segurança da Tecnologia Operacional (OT)», trata a proteção dos suportes como uma família de controlos distinta precisamente por esta razão, e os modelos de zonas e condutas da norma IEC 62443 partem do princípio de que os suportes que entram numa zona foram inspecionados. A política raramente é o problema. A maioria das instalações tem uma política relativa a suportes removíveis guardada algures numa pasta. É na aplicação que tudo se desmorona: uma política que depende de um prestador de serviços se deslocar voluntariamente até uma estação de digitalização não gera qualquer prova no dia em que este, em vez disso, passa por ela sem parar.

O primeiro controlo, portanto, é um ponto de verificação obrigatório no perímetro físico: uma estação de análise pela qual todos os portáteis de fornecedores, unidades de disco de técnicos e atualizações de firmware têm de passar, onde os ficheiros são inspecionados com vários motores de análise, reconstruídos para remover ameaças incorporadas e registados. Dois resultados são igualmente importantes: os suportes infetados nunca entram e todos os suportes que entraram ficam registados. O segundo resultado é a base sobre a qual se fundamenta a notificação de 72 horas.

A verificação dos meios de comunicação à entrada responde a uma questão: o que entra. A forma como os dados circulam posteriormente é um problema à parte.

Mesmo depois de um ficheiro estar limpo, ainda tem de passar do lado da empresa para a rede de controlo e, na maioria das instalações, esse caminho passa por uma regra de firewall. As firewalls são software; são bidirecionais por natureza e configuráveis, o que significa que também podem ser mal configuradas. Uma firewall que permita a transferência de ficheiros de entrada é, por definição, um caminho de retorno que um adversário pode tentar utilizar.

A solução arquitetónica consiste em eliminar fisicamente o caminho de retorno, em vez de o fazer logicamente. Os gateways unidirecionais e os díodos de dados impõem um fluxo de dados unidirecional ao nível do hardware: os dados podem passar do lado de baixa confiança para o lado de alta confiança (ou sair para a empresa, para casos de utilização relacionados com registos históricos e análises), e nenhum protocolo, nenhuma alteração de regra nem nenhuma credencial comprometida pode reverter esse fluxo. Não há nada que se possa configurar incorretamente, porque, para começar, não há nada para configurar.

Isto é importante tanto do ponto de vista regulamentar como em termos de segurança. O Anexo I da CRA exige que os produtos protejam a confidencialidade e a integridade dos dados em trânsito e resistam à manipulação não autorizada de comandos, programas e configurações. A direcionalidade imposta pela Hardware é uma das poucas características que um fornecedor pode demonstrar num ambiente de laboratório, em vez de apenas afirmar numa ficha técnica, o que tem o seu peso quando se está a elaborar um dossiê técnico ou a reunir-se com um auditor.

É aqui que a maioria dos projetos de transferência segura fica paralisada. Um ponto de controlo de sanitização e um gateway unidirecional definem um limite. Não descrevem um fluxo de trabalho, e as equipas de aquisições colocam logo a questão prática: «Tudo bem, mas como é que um engenheiro em Roterdão consegue enviar uma configuração validada de um PLC (Controlador Lógico Programável) para uma fábrica na Polónia num dia qualquer?»

Se a resposta implicar que alguém tenha de percorrer um trajeto de USB até um quiosque, a arquitetura acabou, na verdade, por reintroduzir o problema que se pretendia resolver.

A transferência gerida de ficheiros contorna este problema. Mecanismos padrão, como SFTP, APIs REST e fluxos de trabalho mediados, permitem que os ficheiros sejam transferidos entre zonas sem intervenção humana, e cada transferência é submetida à mesma verificação múltipla e ao tratamento da tecnologia Deep CDR™ que o ficheiro receberia no quiosque. Cada transferência gera também um registo da sessão: quem a iniciou, o que foi enviado, o resultado da verificação, onde foi guardado e quando. Esse registo de auditoria é a resposta operacional ao prazo de comunicação exigido pela CRA. Quando algo corre mal, a diferença entre apresentar o aviso precoce no prazo de 24 horas e perder esse prazo reside, normalmente, no facto de o registo já existir ou de ter de ser reconstruído a partir de entrevistas.

Os fornecedores comercializam o ponto de controlo, o gateway e a camada de transferência como três aquisições distintas. Estes ocupam três pontos num único percurso:

Se resolver apenas a entrada, ficará com um ficheiro limpo, sem qualquer via segura de acesso. Se resolver apenas o cruzamento, ficará com uma fronteira reforçada que as pessoas contornam. Se resolver apenas as operações, ficará com excelentes registos da movimentação de ficheiros não verificados. O valor reside na sequência completa.

Vale a pena ser preciso quanto ao que o prazo de setembro abrange e do que não abrange. A CRA é legislação relativa a produtos: as suas obrigações de comunicação recaem sobre os fabricantes, importadores e distribuidores de produtos com elementos digitais, e não sobre os operadores de instalações enquanto tais. Os operadores de infraestruturas críticas na UE são regulados mais diretamente pela NIS2, que prevê as suas próprias obrigações de notificação de incidentes.

Na prática, porém, ambas as normas convergem para a mesma capacidade. Quer a obrigação lhe seja imposta enquanto fabricante ao abrigo da CRA ou enquanto entidade essencial ao abrigo da NIS2, é-lhe pedido que detete rapidamente um incidente, explique como os dados foram transferidos e demonstre os controlos que estavam em vigor. Um pipeline de dados instrumentado responde a estas três exigências. Um documento de política, por mais cuidadosamente que seja redigido, não responde a nenhuma delas.