El proceso de « USB » a «OT»: por qué el plazo de notificación de la CRA comienza en la puerta de la planta

A partir del 11 de septiembre de 2026, la Ley de Resiliencia Cibernética (CRA) de la UE concede a los fabricantes 24 horas para notificar cualquier vulnerabilidad que esté siendo explotada activamente. En los entornos de tecnología operativa (OT), los incidentes que con mayor probabilidad activan ese plazo llegan en una unidad de almacenamiento « USB », y la mayoría de los operadores siguen sin saber adónde va a parar esa unidad después.

A partir del 11 de septiembre de 2026, los fabricantes de productos con elementos digitales que se comercialicen en la UE deberán notificar las vulnerabilidades que estén siendo explotadas activamente y los incidentes de seguridad graves. El plazo es estricto: una alerta temprana en un plazo de 24 horas desde que se tenga conocimiento del hecho, una notificación completa en un plazo de 72 horas y un informe final en un plazo de 14 días desde que se disponga de una medida correctiva para las vulnerabilidades que estén siendo explotadas activamente, o en el plazo de un mes en el caso de los incidentes graves.

Fíjate en qué se basa todo esto: en la toma de conciencia. Cada plazo establecido en el reglamento parte de la base de que se puede detectar el incidente, reconstruir cómo ocurrió y describir la medida correctiva. Se trata de un problema de documentación y telemetría mucho antes de que se convierta en un problema jurídico. Y la obligación se extiende tanto hacia el pasado como hacia el futuro, ya que abarca los productos ya comercializados en el mercado de la UE, no solo los que se comercialicen después de que el CRA entre plenamente en vigor en diciembre de 2027.

Para cualquiera que gestione o suministre entornos industriales y de tecnología operativa (OT), esto pone de manifiesto una brecha preocupante. La vía con mayor probabilidad de provocar un incidente notificable en OT es también aquella que cuenta con menos instrumentación: los soportes extraíbles. La buena noticia es que se trata de un problema de ingeniería abordable con tres medidas de control bien conocidas: un punto de inspección obligatorio en el perímetro, una transferencia unidireccional entre zonas impuesta por el hardware y una transferencia gestionada que registra cada movimiento. Las tres son necesarias, y el orden es importante.

La investigación sobre ciberseguridad industrial de Honeywell reveló que el 51 % del malware analizado estaba diseñado para propagarse a través de dispositivos « USB », lo que supone un aumento respecto al 9 % registrado cinco años antes. Su informe sobre amenazas para 2025 reveló que uno de cada cuatro incidentes gestionados por su equipo de respuesta estaba relacionado con un evento «plug-and-play» de « USB », normalmente cuando alguien conectaba una unidad de almacenamiento que, a su vez, propagaba el malware por el entorno. Los soportes extraíbles se han convertido en uno de los vectores de acceso inicial más fiables a los entornos de sistemas de control de procesos industriales (ICS, por sus siglas en inglés:Industrial Control Systems), precisamente porque eluden todos los controles de red en los que ha invertido un operador.

Los organismos de normalización ya lo señalaron hace años. La norma NIST SP 800-82 Rev. 3, «Guía para la seguridad de la tecnología operativa (OT)», trata la protección de los soportes como una familia de controles diferenciada precisamente por este motivo, y los modelos de zonas y conductos de la norma IEC 62443 dan por hecho que los soportes que entran en una zona han sido inspeccionados. La política rara vez es el punto débil. La mayoría de las plantas cuentan con una política sobre soportes extraíbles guardada en alguna carpeta. El problema está en su aplicación: una política que depende de que un contratista se acerque voluntariamente a una estación de escaneo no genera ninguna prueba el día en que, en lugar de ello, pasa de largo.

El primer control, por tanto, es un punto de control obligatorio en el perímetro físico: una estación de escaneo por la que deben pasar todos los portátiles de los proveedores, las unidades de los técnicos y las actualizaciones de firmware, donde los archivos se inspeccionan con múltiples motores, se reconstruyen para eliminar las amenazas incrustadas y se registran. Hay dos resultados igualmente importantes: que ningún soporte infectado entre nunca y que todo soporte que haya entrado quede registrado. El segundo resultado es la base sobre la que se establece la notificación en un plazo de 72 horas.

La desinfección de los soportes a la entrada resuelve una cuestión: qué entra. La trayectoria que siguen los datos a partir de ahí es un problema aparte.

Una vez que un archivo está limpio, aún tiene que pasar del entorno empresarial a la red de control, y en la mayoría de las plantas esa ruta pasa por una regla del cortafuegos. Los cortafuegos son programas informáticos; por diseño, son bidireccionales y configurables, lo que significa que también pueden configurarse incorrectamente. Un cortafuegos que permita la transferencia de archivos entrantes es, por su propia naturaleza, una vía de retorno que un atacante podría intentar utilizar.

La solución arquitectónica consiste en eliminar físicamente la ruta de retorno, en lugar de hacerlo de forma lógica. Las pasarelas unidireccionales y los diodos de datos imponen un flujo de datos unidireccional a nivel de hardware: los datos pueden pasar del lado de baja confianza al de alta confianza (o salir hacia la empresa para casos de uso relacionados con el historial y el análisis), y ningún protocolo, ningún cambio de reglas ni ninguna credencial comprometida puede revertir este flujo. No hay nada que se pueda configurar incorrectamente porque, para empezar, no hay nada que configurar.

Esto es tan importante para el cumplimiento normativo como para la seguridad. El anexo I de la CRA exige que los productos protejan la confidencialidad y la integridad de los datos en tránsito y que resistan la manipulación no autorizada de comandos, programas y configuraciones. La direccionalidad garantizada por el Hardware es una de las pocas características que un proveedor puede demostrar en un banco de pruebas en lugar de limitarse a afirmarla en una ficha técnica, lo cual tiene su importancia a la hora de elaborar un expediente técnico o de reunirse con un auditor.

Aquí es donde se estancan la mayoría de los proyectos de transferencia segura. Un punto de control de saneamiento y una pasarela unidireccional definen un límite. No describen un flujo de trabajo, y los equipos de compras plantean pronto una pregunta práctica: «Vale, pero ¿cómo consigue un ingeniero de Róterdam enviar una configuración validada de un PLC (controlador lógico programable) a una planta de Polonia en un día cualquiera?»

Si la respuesta implica que alguien tenga que recorrer un trayecto de USB hasta un quiosco, la arquitectura ha vuelto a plantear, de hecho, el problema que se pretendía resolver con su creación.

La transferencia gestionada de archivos evita este problema. Los mecanismos estándar —SFTP, API REST y flujos de trabajo gestionados— permiten que los archivos se transfieran entre zonas sin que sea necesario que una persona los transporte, y cada traspaso se somete al mismo proceso de escaneo múltiple y a la tecnología Deep CDR™ que recibiría el archivo en el quiosco. Además, cada transferencia genera un registro de sesión: quién la inició, qué se envió, qué resultados arrojó el análisis, dónde se almacenó y cuándo. Ese registro de auditoría es la respuesta operativa al plazo de notificación de la CRA. Cuando surge algún problema, la diferencia entre presentar la alerta temprana en un plazo de 24 horas y dejar pasar ese plazo suele radicar en si el registro ya existe o si hay que reconstruirlo a partir de entrevistas.

Los proveedores comercializan el punto de control, la pasarela y la capa de transferencia como tres compras distintas. Ocupan tres puntos en una misma ruta:

Si solo te centras en la entrada, obtendrás un archivo limpio sin ninguna vía segura de acceso. Si solo te centras en el cruce, obtendrás un perímetro reforzado que la gente tendrá que rodear. Si solo te centras en las operaciones, obtendrás excelentes registros de movimiento de archivos no verificados. El valor reside en la secuencia completa.

Conviene precisar qué abarca y qué no abarca el plazo de septiembre. La CRA es una normativa sobre productos: sus obligaciones de notificación recaen sobre los fabricantes, importadores y distribuidores de productos con elementos digitales, no sobre los operadores de instalaciones como tales. Los operadores de infraestructuras críticas en la UE se rigen más directamente por la NIS2, que establece sus propias obligaciones en materia de notificación de incidentes.

Sin embargo, en la práctica, ambas normativas convergen en la misma capacidad. Tanto si la obligación te incumbe como fabricante en virtud de la CRA como si te incumbe como entidad esencial en virtud de la NIS2, se te pide que detectes un incidente con rapidez, que expliques cómo se movieron los datos y que demuestres qué controles estaban implantados. Un canal de datos instrumentado da respuesta a estas tres exigencias. Un documento de políticas, por muy cuidadosamente que esté redactado, no da respuesta a ninguna de ellas.