Gobierno y riesgo: NIS2 y ciberseguridad OT en planta

La directiva NIS2 convierte la ciberseguridad en una obligación de gobierno corporativo para miles de empresas industriales europeas: la dirección responde de la gestión del riesgo, no solo el departamento de informática. En planta, además, el problema tiene una capa propia: los sistemas OT (autómatas, SCADA, redes de célula) no se protegen con las mismas herramientas ni los mismos supuestos que la ofimática. Esta guía explica qué exige NIS2 a nivel conceptual, por qué el entorno OT es distinto, y por dónde empezar: inventario de activos y segmentación antes que cualquier compra de tecnología.

Qué es NIS2 y a quién aplica

NIS2 es la Directiva (UE) 2022/2555, la segunda directiva europea sobre seguridad de las redes y sistemas de información. Sustituye a la NIS original de 2016 y amplía de forma notable su alcance: donde la primera directiva se centraba en operadores de servicios esenciales designados uno a uno por cada Estado, NIS2 define categorías enteras de sectores y aplica por defecto a las empresas que superan ciertos umbrales de tamaño dentro de ellos. Al ser una directiva y no un reglamento, necesita transposición nacional, y los detalles finos (plazos concretos, régimen sancionador exacto, autoridad supervisora) dependen de cómo la incorpore cada país. Lo que sigue es el marco conceptual común, que sí es estable.

La directiva distingue dos niveles de sujetos: entidades esenciales y entidades importantes. La diferencia práctica está sobre todo en la intensidad de la supervisión y en el régimen sancionador, no en las obligaciones de fondo, que son en esencia las mismas para ambas. Entre los sectores cubiertos figuran la energía, el transporte, el agua, la sanidad, la infraestructura digital y, en el anexo de sectores importantes, la fabricación de determinadas categorías de productos, la industria química y la alimentaria, entre otros. El criterio general de tamaño apunta a medianas y grandes empresas: como regla orientativa, a partir de 50 empleados o 10 millones de euros de facturación dentro de un sector cubierto conviene analizar si se está dentro del ámbito. Ese análisis debe hacerse con la transposición nacional en la mano, no con la directiva a secas.

Hay un matiz que muchas empresas industriales pasan por alto: aunque una planta no esté formalmente dentro del ámbito de NIS2, es muy probable que sus clientes sí lo estén. La directiva obliga a los sujetos a gestionar el riesgo de su cadena de suministro, lo que en la práctica significa que un fabricante mediano puede recibir cuestionarios de seguridad, cláusulas contractuales y auditorías de sus clientes esenciales aunque a él la norma no le aplique directamente. La presión regulatoria se propaga aguas arriba por la cadena de valor.

Qué exige NIS2 en gobierno del riesgo

El núcleo de NIS2 no es una lista de productos de seguridad que comprar. Es una obligación de gestionar el riesgo de forma demostrable. El artículo 21 de la directiva enumera las medidas mínimas que todo sujeto debe adoptar, siempre bajo un criterio de proporcionalidad al riesgo. Resumidas a nivel conceptual:

• Análisis de riesgos y políticas de seguridad de los sistemas de información: saber qué se tiene, qué amenazas le afectan y qué se ha decidido hacer al respecto, por escrito.
• Gestión de incidentes: capacidad de detectar, responder y notificar. NIS2 introduce plazos de notificación escalonados a la autoridad competente, con una alerta temprana en las primeras 24 horas desde que se conoce un incidente significativo.
• Continuidad de negocio: copias de seguridad, recuperación ante desastres y gestión de crisis. En una planta, esto incluye la pregunta incómoda de cuánto tiempo se puede producir sin los sistemas afectados.
• Seguridad de la cadena de suministro: evaluar el riesgo que introducen proveedores y prestadores de servicios, incluidos los integradores y mantenedores que se conectan a los equipos de planta.
• Seguridad en la adquisición, desarrollo y mantenimiento de sistemas, incluida la gestión de vulnerabilidades.
• Ciberhigiene y formación, también para la dirección.
• Criptografía, control de acceso, gestión de activos y autenticación multifactor donde proceda.

El cambio más profundo respecto a la práctica anterior está en la responsabilidad. NIS2 establece que los órganos de dirección deben aprobar las medidas de gestión del riesgo, supervisar su aplicación y pueden responder por los incumplimientos. Además deben formarse en la materia. Esto saca la ciberseguridad del sótano técnico y la coloca en el mismo plano que el riesgo financiero o el laboral: un asunto de consejo, con evidencia documental de que se trata como tal.

Por qué la seguridad OT no es seguridad IT

Cuando una empresa industrial aborda NIS2, el reflejo habitual es extender a la planta las prácticas del departamento de sistemas: antivirus, parches mensuales, escaneos de vulnerabilidades. Ese reflejo falla porque el entorno OT (tecnología de operaciones: PLC, SCADA, HMI, variadores, robots, redes de célula) invierte las prioridades clásicas de la seguridad de la información. En IT el orden es confidencialidad, integridad, disponibilidad. En OT el orden se da la vuelta: primero la disponibilidad y la seguridad física del proceso, después la integridad de las señales, y la confidencialidad en último lugar. Un dato de temperatura no es secreto; que llegue tarde o manipulado sí es un problema.

Las diferencias prácticas que se derivan de esa inversión merecen una tabla:

Por eso el marco de referencia en planta no es solo ISO/IEC 27001, pensada para sistemas de gestión de seguridad de la información en general, sino la familia IEC 62443, escrita específicamente para sistemas de automatización y control industrial. IEC 62443 aporta dos ideas que NIS2 no detalla pero que encajan de forma natural con sus exigencias: los conceptos de zonas y conductos para segmentar la red por función y criticidad, y los niveles de seguridad (SL) para graduar las medidas según el riesgo de cada zona en lugar de aplicar un café para todos. Un programa OT serio usa NIS2 como mandato de gobierno e IEC 62443 como manual técnico.

Imaginemos, como hilo conductor, una planta de inyección de plástico con 25 máquinas, un ERP en la nube y dos integradores externos que se conectan por escritorio remoto para mantenimiento. Es un perfil corriente. Su riesgo real no suele ser un ataque dirigido de manual: es el ransomware que entra por el correo de oficina, cruza a la red de planta porque nunca se separaron, y cifra el equipo donde corre el SCADA. La producción se para no porque los PLC estén comprometidos, sino porque nadie puede supervisarla ni cargar programas. Ese escenario, mucho más frecuente que el sabotaje sofisticado, es exactamente el que las medidas básicas de esta guía reducen.

Primer paso: inventario de activos OT

No se puede gobernar el riesgo de lo que no se sabe que existe, y NIS2 exige explícitamente la gestión de activos. En la práctica, la mayoría de las plantas no tiene un inventario fiable de su parque OT: hay autómatas instalados hace quince años por un integrador que ya no trabaja con la empresa, tarjetas de red añadidas en una ampliación, routers 4G que un proveedor dejó conectados a una máquina para dar soporte remoto y de los que nadie se acuerda. Cada uno de esos elementos es superficie de ataque.

Un inventario OT útil recoge, como mínimo, por cada activo:

• Identificación: fabricante, modelo, versión de firmware o sistema operativo.
• Función de proceso: qué máquina o línea controla y qué pasa si se para.
• Conectividad: direcciones de red, protocolos que habla, con quién se comunica.
• Accesos: quién puede tocarlo, local y remotamente, y con qué credenciales.
• Estado de soporte: si el fabricante aún publica actualizaciones.
• Criticidad: una clasificación simple (alta, media, baja) basada en el impacto.

El método importa tanto como el resultado. En OT el descubrimiento activo (escanear la red como haría una herramienta de IT) es arriesgado: hay controladores antiguos que se reinician ante un paquete inesperado. La práctica correcta combina descubrimiento pasivo (escuchar el tráfico en los conmutadores de planta), revisión documental de esquemas eléctricos y proyectos de automatización, y recorrido físico de armarios. En la planta de inyección del ejemplo, el recorrido físico es el que encuentra el router 4G olvidado; la escucha pasiva es la que revela que una máquina habla con una IP externa que nadie sabía explicar.

Este trabajo de levantamiento casa de forma natural con un diagnóstico operacional más amplio: la misma visita que mapea flujos de producción y captura de datos puede mapear el parque de activos conectados y sus accesos. Hacer los dos ejercicios por separado suele duplicar esfuerzo y producir dos fotos incompatibles de la misma planta.

Segundo paso: segmentación de red

Con el inventario en la mano, la medida de mayor impacto por euro invertido es la segmentación. La situación de partida típica es una red plana: oficinas, wifi de visitas, SCADA y PLC en el mismo dominio de difusión, de modo que cualquier equipo comprometido puede alcanzar cualquier controlador. La segmentación rompe esa continuidad y convierte un incidente de oficina en un incidente de oficina, no de producción.

El modelo conceptual clásico es el de niveles de Purdue, y su traducción operativa moderna son las zonas y conductos de IEC 62443. Sin entrar en arquitecturas complejas, tres movimientos concentran la mayor parte del beneficio:

1. Separar IT de OT con un cortafuegos que solo permita los flujos identificados en el inventario. Todo lo que no esté justificado, cerrado. Si el ERP necesita datos de planta, ese flujo se documenta y se permite; el resto no.
2. Crear una zona intermedia (DMZ industrial) para los servicios que ambos mundos necesitan: historiadores, servidores de intercambio de ficheros, brokers de datos. Ni IT habla directamente con los PLC ni los PLC salen a internet.
3. Segmentar dentro de OT por células o líneas, de modo que un problema en una línea no se propague a las demás. En la planta de inyección, cada grupo de máquinas con su HMI puede ser una zona; el SCADA central, otra.

Mención aparte merece el acceso remoto de terceros, que en el ejemplo eran dos integradores con escritorio remoto. Es la puerta de entrada más citada en incidentes industriales reales: credenciales compartidas, accesos permanentes que deberían ser puntuales, sin registro de sesiones. El objetivo razonable es un único punto de entrada, con cuentas nominales, autenticación multifactor, acceso limitado en tiempo y alcance, y registro de lo que se hace. La arquitectura de referencia hacia la que evolucionar, con verificación explícita de cada acceso en lugar de confianza por ubicación de red, se desarrolla en el pilar de zero trust aplicado a entornos OT industriales, que trata la parte de arquitectura de red y conectividad con la profundidad que aquí no corresponde.

El riesgo ciber en la agenda de dirección

Todo lo anterior es técnica. NIS2, sin embargo, es sobre todo una norma de gobierno, y el error más común es tratarla como un proyecto del responsable de informática. La directiva pide que la dirección apruebe y supervise; para poder hacerlo con conocimiento de causa, el riesgo ciber tiene que entrar en los órganos de decisión con el mismo tratamiento que cualquier otro riesgo empresarial.

En una empresa industrial mediana, eso se concreta en pocas piezas, pero estables:

• Un responsable con nombre y apellidos para la seguridad OT, aunque no sea dedicado a tiempo completo. Sin propietario, las medidas se degradan.
• Un registro de riesgos que la dirección revise de forma periódica: qué escenarios preocupan (parada de SCADA por ransomware, pérdida del acceso remoto de mantenimiento, manipulación de recetas), qué probabilidad e impacto se les asigna y qué se está haciendo con cada uno.
• Decisiones documentadas. Aceptar un riesgo es legítimo; lo que NIS2 no tolera es no haberlo considerado. Si la dirección decide no segmentar una línea antigua porque se retira en dos años, esa decisión escrita vale más que una medida técnica improvisada.
• Un plan de respuesta ensayado: a quién se llama, cómo se aísla la planta de la red corporativa, cómo se produce en modo degradado y quién notifica a la autoridad dentro del plazo. Un ejercicio de mesa de dos horas al año descubre más carencias que muchos informes.
• Indicadores simples que suban a dirección: porcentaje de activos inventariados, accesos remotos activos frente a autorizados, incidentes y cuasi-incidentes del periodo, avance del plan.

La formación de la dirección que exige la directiva no busca convertir al consejo en expertos técnicos. Busca que sepan hacer las preguntas correctas: qué pasaría si mañana no arrancan los sistemas de planta, cuánto tardaríamos en volver a producir, de qué proveedores dependemos para responder y quién tiene acceso a qué. Una dirección que sabe preguntar eso gobierna el riesgo; una que delega la conversación entera en el proveedor de turno, no.

Una hoja de ruta razonable

Cumplir NIS2 en planta no es un proyecto de seis semanas ni requiere empezar comprando tecnología. Una secuencia sensata para una empresa industrial mediana, siguiendo el orden de esta guía:

1. Determinar el ámbito: verificar con la transposición nacional si la empresa es sujeto esencial, importante o queda fuera, y qué exigen ya los clientes por contrato.
2. Inventariar el parque OT con métodos pasivos y recorrido físico, y clasificar los activos por criticidad.
3. Evaluar el riesgo sobre ese inventario y llevar el resultado a dirección para que priorice y apruebe.
4. Segmentar: frontera IT/OT, DMZ industrial y control del acceso remoto de terceros antes que ninguna otra inversión.
5. Preparar la respuesta: plan de incidentes con los plazos de notificación integrados, copias de seguridad de programas de PLC y proyectos SCADA verificadas con una restauración real, y un ejercicio de mesa anual.
6. Consolidar el gobierno: responsable, registro de riesgos, indicadores y revisión periódica en dirección. Es lo que convierte un proyecto puntual en un sistema que sobrevive al paso del tiempo.

La planta de inyección del ejemplo, tras ese recorrido, no es invulnerable. Pero un ransomware en oficinas ya no para la producción, los integradores entran por una puerta vigilada, la dirección sabe qué riesgos ha aceptado y por qué, y ante un incidente hay un plan en lugar de una improvisación. Eso, y no un certificado en la pared, es lo que NIS2 pide en el fondo: que el riesgo ciber esté gobernado.

Preguntas frecuentes

Si su empresa está evaluando qué le exige NIS2 y en qué estado se encuentra su planta, un buen punto de partida es un diagnóstico operacional que incluya el levantamiento del parque OT y sus accesos. El equipo de Captia Consulting trabaja este tipo de programas de gobierno y riesgo junto con la vertiente de arquitectura de red que desarrolla el pilar de zero trust OT.