Normativa, ciberseguridad, innovación e industria 4.0

octubre 15, 2026 on 6:20 am | In ciberseguridad, descarga textos pdf, innovación, m2m, iot | Comentarios desactivados en Normativa, ciberseguridad, innovación e industria 4.0

Adolfo García Yagüe | Ayer, y tras un ligero cambio del título previsto inicialmente, impartí una pequeña charla en las jornadas Digital Innovation Hub Industry 4.0 de Burgos. En ella analicé un aspecto que está adquiriendo una importancia creciente en el desarrollo de nuevas soluciones para la industria: la relación entre innovación, ciberseguridad y normativa.

Como sabéis, vivimos inmersos en una transformación digital que se extiende a todos los rincones de nuestra sociedad. La industria no es ajena a este proceso y dispositivos, máquinas, sensores, sistemas de control y plataformas de gestión están cada vez más conectados. Esta evolución abre enormes posibilidades para desarrollar nuevos productos y servicios, pero también introduce nuevos riesgos y responsabilidades para fabricantes, desarrolladores, integradores y usuarios de estas tecnologías.

Por esta y otras razones, la Unión Europea está impulsando un conjunto cada vez más amplio de directivas y reglamentaciones -entre ellos NIS2, Cyber Resilience Act (CRA) o AI Act– que afectan, desde diferentes perspectivas, a la forma en que se diseñan, fabrican, despliegan y gestionan las soluciones digitales.

La presentación partió precisamente de esta realidad para plantear una pregunta sencilla, pero importante: ¿Hasta qué punto debemos incorporar la ciberseguridad y la normativa al propio proceso de innovación?

La respuesta tiene especial relevancia cuando se pasa del prototipo al producto. Un dispositivo industrial puede necesitar identidad digital propia, certificados X.509, firmware firmado, Secure Boot, protección de interfaces de depuración, gestión de vulnerabilidades y CVEs, mecanismos seguros de actualización OTA, provisioning, revocación de dispositivos o comunicaciones mTLS…

Pero alrededor del dispositivo aparece además todo un ecosistema de plataformas: PKI, gestión de identidades, almacenamiento, telemetría, gestión remota y operación segura. Es decir, la ciberseguridad deja de ser un elemento que podemos añadir al final del proceso y debe considerarse desde el inicio del diseño de una solución.

Durante la presentación también abordé la perspectiva de quienes operan y administran infraestructuras OT. Para ellos, la cuestión no se limita al dispositivo: entran en juego aspectos como el inventario y la visibilidad de activos, el acceso remoto y privilegiado, MFA, la segmentación IT/OT, zonas y conduits, la gestión de vulnerabilidades, la monitorización, la respuesta ante incidentes, la continuidad y la gestión de terceros y de la cadena de suministro…

El objetivo no fue hacer un recorrido jurídico por las diferentes normativas, sino ponerlas en relación con el proceso real de innovación y con la operación de los sistemas industriales.

Quizás, uno de los cambios más importantes que estamos viviendo es precisamente este: innovar ya no consiste únicamente en conseguir que una tecnología funcione. También debemos pensar, desde el principio, cómo vamos a identificarla, protegerla, actualizarla, gestionarla y mantenerla segura durante todo su ciclo de vida.

La Normativa como guía y herramienta de ciberseguridad
Para ilustrar las ideas planteadas anteriormente, imaginé un hipotético ataque siguiendo las tácticas y técnicas de la matriz MITRE ATT&CK para ICS. Con él pretendía ilustrar cómo podría progresar un adversario desde el acceso inicial hasta comprometer un proceso industrial. Me interesaba que los asistentes entendieran cómo la aplicación de los marcos normativos NIS2, IEC 62443 y Cyber Resilience Act (CRA) introduce controles técnicos y organizativos que dificultan o impiden el avance del atacante en cada fase. Visto desde esta perspectiva, la normativa deja de ser un mero requisito de cumplimiento para convertirse en una guía de referencia que nos permite evaluar la idoneidad de una arquitectura. Además, la correcta interpretación de estas normas nos permite seleccionar adecuadamente las herramientas de ciberseguridad que necesitamos: NGFW, VPN, ZTNA, MFA, PAM, IPS, NDR, gestión de vulnerabilidades…

Imaginemos que un adversario selecciona como objetivo una compañía industrial debido al valor de sus activos, la importancia de sus procesos productivos o el impacto que podría provocar una interrupción de su actividad. Antes de intentar acceder a sus sistemas, inicia una fase de reconocimiento destinada a conocer tanto la organización como su superficie tecnológica.

Por un lado, recopila información sobre empleados y colaboradores a través de fuentes abiertas, redes sociales y otras fuentes de información pública. Esta inteligencia le permite identificar, entre otros perfiles, a un técnico de mantenimiento que dispone de acceso remoto a los sistemas de la compañía. Con esta información puede diseñar posteriormente un phishing dirigido y suficientemente creíble como para aumentar las probabilidades de que la víctima muerda el anzuelo.

En paralelo, el adversario estudia la superficie tecnológica expuesta a Internet: dominios, direcciones IP, servicios publicados, certificados, tecnologías utilizadas y dispositivos accesibles desde el exterior. En esta fase puede apoyarse en motores de búsqueda especializados en servicios y dispositivos expuestos en Internet, además de otras fuentes y técnicas de reconocimiento. Como resultado, identifica un dispositivo IoT utilizado por la organización que presenta debilidades de seguridad, bien por su diseño, por su configuración o por la existencia de vulnerabilidades conocidas.

De esta forma, el atacante dispone de dos piezas de información que inicialmente parecen independientes pero que forman parte de una misma estrategia: conoce a una persona que puede proporcionarle una vía de acceso legítima al entorno de la planta y, al mismo tiempo, conoce un activo tecnológico concreto que puede convertirse posteriormente en un punto de apoyo dentro de la infraestructura industrial.

Antes de proseguir, es necesario recordar que ningún marco normativo impedirá que un atacante recopile información pública o analice los servicios expuestos en Internet. Sin embargo, NIS2, IEC 62443 y, cuando resulte aplicable, CRA establecen medidas destinadas a reducir la superficie de ataque, gestionar las vulnerabilidades y evitar configuraciones inseguras, dificultando que la información obtenida pueda convertirse en un punto de entrada a la organización.

Volvamos al ataque: la intrusión se inicia con un phishing dirigido hacia el técnico de mantenimiento. Este cae en la trampa y es, sigilosamente, infectado con un malware que sustrae sus credenciales de acceso remoto al entorno corporativo. Este vector podría mitigarse mediante los requisitos de NIS2 relativos a la gestión de riesgos y control de accesos, así como mediante los principios de IEC 62443 relacionados con la segmentación entre IT y OT.

Una vez dentro, el atacante intentará pasar desapercibido empleando protocolos, comandos legítimos y scripts para desplegar herramientas especializadas en ejecutar acciones maliciosas. La aplicación de IEC 62443 permite restringir privilegios y controlar la ejecución de software autorizado, mientras que NIS2 exige capacidades de monitorización y detección temprana de actividades anómalas.

Una vez dentro del entorno, el atacante se dirige hacia el dispositivo IoT que había identificado durante su reconocimiento previo. Aprovechando sus debilidades de seguridad, consigue comprometerlo y modificar su firmware o realizar un rollback a una versión previa en la que existen vulnerabilidades conocidas que sabe cómo aprovechar. De esta forma puede conseguir persistencia incluso tras el reinicio del sistema. CRA, cuando resulta aplicable al producto, y IEC 62443 contemplan medidas relacionadas con la integridad del software y firmware, las actualizaciones seguras y la gestión de vulnerabilidades, dificultando este tipo de manipulación.

Antes de continuar, el atacante intentará reducir las capacidades de supervisión, registro de logs y otros mecanismos de seguridad del sistema bajo su control para disminuir las posibilidades de detección. Una vez más, la aplicación de IEC 62443 proporciona requisitos y capacidades orientadas a la monitorización y detección de anomalías, dificultando que estas acciones pasen inadvertidas.

Posteriormente, una vez consolidada su posición, el adversario realizará acciones de reconocimiento, identificando los equipos industriales a su alcance. Para ello, empleará técnicas de descubrimiento a través de las conexiones de red, así como mediante la identificación de puertos y servicios accesibles, con el objetivo de determinar los activos disponibles, sus características y posibles vectores de ataque. Las arquitecturas recomendadas por IEC 62443, basadas en zonas y conduits, limitan la visibilidad de la red y reducen la capacidad de exploración del atacante.

Tras formarse una imagen de los activos que están a su alcance, intentará moverse lateralmente explotando credenciales por defecto, credenciales embebidas y servicios remotos vulnerables presentes en los sistemas descubiertos. De esta forma el atacante logra avanzar hasta su objetivo: los PLCs, estaciones de ingeniería o el SCADA. Tanto CRA, cuando resulta aplicable, como IEC 62443 contemplan medidas relacionadas con la autenticación, la gestión de credenciales, las vulnerabilidades y las actualizaciones de seguridad, dificultando este tipo de accesos.

Una vez alcanzados los sistemas críticos, el atacante recopila información sobre el proceso industrial, obteniendo configuraciones, programas de control y parámetros operativos. La aplicación del principio de mínimo privilegio, junto con controles de acceso basados en roles definidos por IEC 62443 y las medidas de gestión de riesgos y control de acceso de NIS2, limita el acceso a esta información sensible.

A continuación, el atacante establece un canal de comando y control utilizando puertos comúnmente permitidos, intentando ocultar sus comunicaciones entre el tráfico legítimo. Las capacidades de monitorización continua, inspección de tráfico y detección de anomalías promovidas por NIS2 e IEC 62443 permiten identificar comportamientos anómalos incluso cuando utilizan protocolos habituales.

Con las técnicas de inhibición de la respuesta, el atacante busca impedir la respuesta operativa mediante supresión de alarmas, bloqueo de mensajes, parada de servicios o incluso destrucción de datos. IEC 62443 incorpora requisitos y medidas relacionadas con la disponibilidad, trazabilidad y protección de funciones críticas que dificultan estas acciones y facilitan su detección.

Finalmente, el adversario enviará comandos no autorizados al proceso industrial, provocando alteraciones operativas que pueden desembocar en pérdida de control, parada de producción, daños materiales o riesgos para la seguridad física. La combinación de NIS2 e IEC 62443 establece controles técnicos y organizativos destinados precisamente a evitar que un incidente de ciberseguridad alcance el proceso físico, reduciendo significativamente la probabilidad y el impacto de este tipo de ataques.

Usé unas pocas diapositivas para apoyar mi participación y ayudar a poner en contexto algunos de los temas que comentamos. Os las dejo aquí por si os resultan de utilidad.