Seguridad OT y NIS2: mapeo de ISO 27001 e IEC 62443
A las 02:17 de un lunes, un operador de una planta de tratamiento de agua recibe una alarma de un sistema de dosificación. La dosificación química sigue dentro de los límites seguros, pero un PLC informa de comandos irregulares, la estación de ingeniería muestra inicios de sesión fallidos desde una cuenta VPN de un proveedor y el analista del SOC de guardia plantea una pregunta que nadie quiere responder bajo presión.
¿Es un incidente de TI, un incidente de OT, un evento de seguridad física o un incidente significativo notificable bajo NIS2?
La planta tiene cortafuegos. Tiene documentación ISO. Tiene una hoja de cálculo de proveedores. Incluso tiene un plan de respuesta a incidentes. Pero el plan se redactó para cuentas de correo comprometidas e indisponibilidad de servicios en la nube, no para un controlador heredado que no puede parchearse durante la producción, un proveedor que necesita acceso remoto para restablecer el servicio y una autoridad reguladora que espera evidencias dentro de los plazos de notificación de NIS2.
El mismo problema aparece en los consejos de administración. Un CISO de un proveedor regional de energía puede disponer de un sistema de gestión de la seguridad de la información certificado conforme a ISO/IEC 27001:2022 para la TI corporativa, mientras que el parque de tecnología operativa sigue siendo un entramado de PLC, RTU, HMI, historiadores de datos, estaciones de ingeniería, conmutadores industriales y vías de acceso de proveedores. La pregunta del director general es sencilla: «¿Estamos cubiertos? ¿Puedes demostrarlo?»
Para muchas entidades esenciales e importantes, la respuesta honesta es incómoda. Están cubiertas parcialmente. Pueden demostrarlo parcialmente. Pero la seguridad OT conforme a NIS2 exige algo más que cumplimiento genérico de TI.
Exige un modelo operativo unificado que conecte la gobernanza de ISO/IEC 27001:2022, el lenguaje de controles de ISO/IEC 27002:2022, las prácticas de ingeniería industrial de IEC 62443, las medidas de gestión del riesgo de ciberseguridad del Artículo 21 de NIS2 y las evidencias de notificación de incidentes del Artículo 23 de NIS2.
Ese es el puente que construye esta guía.
Por qué la seguridad OT en NIS2 es diferente del cumplimiento ordinario de TI
NIS2 se aplica a muchas entidades públicas y privadas que prestan servicios dentro del ámbito de aplicación en la UE, incluidas entidades esenciales e importantes de sectores como energía, transporte, banca, infraestructuras de los mercados financieros, salud, agua potable, aguas residuales, infraestructura digital, gestión de servicios TIC, administración pública, espacio, servicios postales, gestión de residuos, fabricación, productos químicos, alimentación, proveedores digitales e investigación.
La Directiva exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos de ciberseguridad, prevenir o minimizar el impacto de los incidentes y proteger la continuidad de los servicios. El Artículo 21 incluye un enfoque frente a todos los riesgos que abarca análisis de riesgos, políticas de seguridad, gestión de incidentes, continuidad del negocio, gestión de crisis, seguridad de la cadena de suministro, adquisición y mantenimiento seguros, gestión y divulgación de vulnerabilidades, evaluación de la eficacia, higiene cibernética, formación, criptografía, seguridad de los recursos humanos, control de acceso, gestión de activos, MFA o autenticación continua, comunicaciones seguras y comunicaciones de emergencia cuando proceda.
Estos requisitos resultan familiares para un equipo de ISO/IEC 27001:2022. En OT, cada uno de ellos se comporta de forma distinta.
Una vulnerabilidad en un servidor web a menudo puede parchearse en cuestión de días. Una vulnerabilidad en un controlador de turbina puede requerir validación del proveedor, una ventana de mantenimiento, una revisión de seguridad funcional y procedimientos operativos alternativos. Un portátil puede reinstalarse. Una HMI de producción puede depender de un sistema operativo heredado porque la aplicación industrial no ha sido certificada para una plataforma más reciente. Un procedimiento de respuesta del SOC puede indicar «aislar el host», mientras el ingeniero de OT responde: «no hasta que sepamos si el aislamiento afecta al control de presión».
La diferencia no es solo técnica. TI suele priorizar confidencialidad, integridad y disponibilidad. OT prioriza disponibilidad, integridad del proceso y seguridad funcional. Un control de seguridad que introduce latencia, requiere un reinicio o interrumpe un proceso físico puede ser inaceptable sin aprobación de ingeniería.
NIS2 no exime a OT de la gestión del riesgo de ciberseguridad. Espera que la organización demuestre que los controles son adecuados al riesgo y proporcionados a la realidad operativa.
La pila de controles: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 e IEC 62443
Un programa de seguridad OT conforme a NIS2 y defendible ante auditoría empieza con una pila de controles por capas.
ISO/IEC 27001:2022 proporciona el sistema de gestión. Exige que la organización defina el contexto, las partes interesadas, las obligaciones reglamentarias, el alcance del SGSI, las interfaces y las dependencias. También exige liderazgo, una política de seguridad de la información, evaluación de riesgos, tratamiento de riesgos, una Declaración de Aplicabilidad, información documentada, auditoría interna, revisión por la dirección y mejora continua.
ISO/IEC 27002:2022 proporciona el vocabulario de controles. Para OT, los controles más importantes suelen incluir seguridad de proveedores, gestión del riesgo de la cadena de suministro TIC, planificación de incidentes, preparación para la continuidad del negocio, requisitos legales y contractuales, gestión de activos, control de acceso, gestión de vulnerabilidades, copias de seguridad, registro de eventos, supervisión, seguridad de redes y segregación de redes.
IEC 62443 proporciona el modelo de ingeniería de seguridad industrial. Ayuda a traducir los requisitos del sistema de gestión en prácticas OT como zonas, conductos, niveles de seguridad, responsabilidades del propietario del activo, responsabilidades del integrador de sistemas, expectativas sobre proveedores de producto, restricciones de acceso remoto, funcionalidad mínima, gestión de cuentas, bastionado y controles del ciclo de vida.
Clarysec utiliza esta pila porque evita dos fallos habituales. Primero, impide que la implantación ISO sea demasiado genérica para OT. Segundo, evita que el trabajo de ingeniería IEC 62443 quede desconectado de la rendición de cuentas del consejo de administración, las obligaciones de notificación de NIS2 y las evidencias de auditoría.
La Política de Seguridad de IoT / OT de Clarysec establece el puente de forma directa:
Garantizar que todos los despliegues estén alineados con los controles ISO/IEC 27001 y la orientación sectorial aplicable (p. ej., IEC 62443, ISO 27019, NIST SP 800-82).
Esa frase importa. La política no es solo una lista de verificación de bastionado de dispositivos. Conecta la gobernanza ISO, la orientación sectorial OT y la seguridad operativa.
Empezar por el alcance: ¿qué servicio OT debe protegerse?
Antes de mapear controles, defina el servicio OT en términos operativos y regulatorios.
Un responsable de planta puede decir: «Operamos la línea de envasado». Una evaluación NIS2 debería decir: «Este proceso de producción sustenta un servicio esencial o importante y depende de PLC, HMI, estaciones de ingeniería, historiadores de datos, conmutadores industriales, acceso remoto de proveedores, un contratista de mantenimiento, una alimentación de analítica en la nube y un servicio corporativo de identidad».
Las cláusulas 4.1 a 4.4 de ISO/IEC 27001:2022 son útiles porque obligan a la organización a identificar cuestiones internas y externas, partes interesadas, requisitos legales y contractuales, límites del SGSI, interfaces y dependencias. Para la seguridad OT conforme a NIS2, esto significa mapear no solo la red de la sede central, sino también los sistemas industriales y las dependencias de servicio que afectan a la continuidad, la seguridad funcional y la prestación regulada.
NIST CSF 2.0 refuerza la misma lógica. Su función GOVERN exige comprender la misión, las partes interesadas, las dependencias, las obligaciones legales y reglamentarias, los servicios críticos y los servicios de los que depende la organización. Los perfiles organizativos ofrecen un método práctico para delimitar el estado actual, definir un estado objetivo, analizar brechas y generar un plan de acción priorizado.
Para un entorno OT, Clarysec suele empezar con cinco preguntas:
- ¿Qué servicio regulado o crítico sustenta este entorno OT?
- ¿Qué activos OT, redes, flujos de datos y terceros son necesarios para ese servicio?
- ¿Qué restricciones de seguridad funcional, disponibilidad y operación afectan a los controles de seguridad?
- ¿Qué obligaciones legales, contractuales y sectoriales se aplican, incluidas NIS2, RGPD de la UE, DORA cuando corresponda, contratos con clientes y normas nacionales?
- ¿Qué partes del entorno están dentro del SGSI y cuáles son dependencias externas que requieren controles de proveedores?
Muchos programas NIS2 fallan aquí. Definen el alcance alrededor de la TI corporativa porque es más fácil inventariarla. Los auditores y reguladores no quedarán satisfechos si la dependencia de servicio más crítica aparece solo como una línea imprecisa denominada «red de fábrica».
Un mapa práctico de controles OT para NIS2
La tabla siguiente muestra cómo convertir los temas del Artículo 21 de NIS2 en evidencias de ISO/IEC 27001:2022, ISO/IEC 27002:2022 e IEC 62443. No sustituye a una evaluación de riesgos formal, pero ofrece a CISO, responsables OT y equipos de cumplimiento un punto de partida práctico.
| Preocupación de seguridad OT | Tema del Artículo 21 de NIS2 | Anclaje en ISO/IEC 27001:2022 e ISO/IEC 27002:2022 | Lógica de implantación IEC 62443 | Evidencia típica |
|---|---|---|---|---|
| PLC, HMI, sensores y estaciones de ingeniería desconocidos | Análisis de riesgos, gestión de activos | Alcance del SGSI, evaluación de riesgos, controles de activos y configuración del Anexo A | Inventario de activos por zona, criticidad del sistema y estado del ciclo de vida | Registro de activos OT, diagramas de red, asignación de propietarios, lista de activos sin soporte |
| Red de planta plana | Prevención o minimización del impacto de incidentes | Seguridad de redes y segregación de redes | Zonas y conductos que separan TI corporativa, OT, seguridad física y vías de proveedores | Arquitectura de red, reglas de cortafuegos, VLAN, aprobaciones de flujos de datos |
| Acceso remoto de proveedores | Control de acceso, MFA, comunicaciones seguras, cadena de suministro | Acuerdos con proveedores, control de acceso, registro de eventos, supervisión | Conductos de acceso remoto controlados, acceso limitado en el tiempo, servidores de salto, grabación de sesiones | Aprobaciones de acceso de proveedores, registros MFA, registros de sesión, cláusulas de proveedores |
| Sistemas heredados que no pueden parchearse | Gestión de vulnerabilidades, mantenimiento seguro | Gestión de vulnerabilidades técnicas, tratamiento de riesgos | Controles compensatorios, aislamiento, validación del proveedor, ventanas de mantenimiento | Registro de vulnerabilidades, aprobaciones de excepciones, evidencias de controles compensatorios |
| Anomalías OT y comandos sospechosos | Gestión de incidentes, detección | Registro de eventos, supervisión, evaluación de eventos y respuesta a incidentes | Supervisión específica de OT sobre protocolos, comandos, cambios de ingeniería y flujos anómalos | Alertas IDS, registros del historiador de datos, tickets SIEM, registros de triaje |
| Interrupción de producción o parada insegura | Continuidad del negocio y gestión de crisis | Preparación TIC para la continuidad del negocio, copias de seguridad y controles frente a interrupciones | Procedimientos de recuperación alineados con prioridades de seguridad funcional y del proceso | Pruebas de restauración, copias de seguridad offline, procedimientos operativos, informes de ejercicios de mesa |
| Adquisición industrial insegura | Adquisición segura y cadena de suministro | Riesgo de proveedores, requisitos de seguridad en acuerdos, cadena de suministro TIC | Requisitos de seguridad desde el diseño para integradores y proveedores de producto | Lista de verificación de adquisición, revisión de arquitectura, requisitos de seguridad |
Este mapa está deliberadamente centrado en evidencias. Bajo NIS2, decir «tenemos segmentación» no basta. Debe demostrarse por qué la segmentación es adecuada, cómo está implantada, cómo se aprueban las excepciones y cómo el diseño reduce el impacto sobre el servicio regulado.
Segmentación: el primer control OT que probarán los auditores
Si el incidente de las 02:17 implicó que un atacante se moviera desde un portátil de oficina hasta una estación de ingeniería, la primera pregunta de auditoría sería obvia: ¿por qué podía existir esa ruta?
La Política de Seguridad de IoT / OT es explícita:
Los sistemas OT deben operar dentro de redes dedicadas aisladas de la TI corporativa y de los sistemas expuestos a internet.
Para entornos más pequeños, la Política de seguridad de Internet de las Cosas (IoT) / Tecnología Operativa (OT) - pyme ofrece una configuración de referencia práctica:
Todos los dispositivos de Internet de las Cosas (IoT) y de Tecnología Operativa (OT) deben ubicarse en una red Wi-Fi o VLAN separada
Para un operador maduro de infraestructuras críticas, la segmentación debe diseñarse alrededor de zonas y conductos OT. Los usuarios corporativos no deben acceder directamente a redes de PLC. Las conexiones de proveedores deben terminar en zonas de acceso controladas. La replicación del historiador de datos debe usar rutas aprobadas. Los sistemas de seguridad física deben aislarse conforme al riesgo y a los requisitos de ingeniería. Las redes OT inalámbricas deben estar justificadas, bastionadas y supervisadas.
Zenith Blueprint: hoja de ruta de 30 pasos para auditores, en la fase Controles en acción, paso 20, explica el principio detrás de la seguridad de redes de ISO/IEC 27002:2022:
Los sistemas de control industrial deben aislarse del tráfico de oficina.
También advierte que la seguridad de redes requiere arquitectura segura, segmentación, control de acceso, cifrado en tránsito, supervisión y defensa en profundidad.
En Zenith Controls: la guía de cumplimiento transversal, el control 8.22 de ISO/IEC 27002:2022, Segregación de redes, se trata como un control preventivo que soporta confidencialidad, integridad y disponibilidad, alineado con el concepto de ciberseguridad Protect, con la seguridad de sistemas y redes como capacidad operativa y Protección como dominio de seguridad.
Esa clasificación es útil para las evidencias NIS2 porque la segmentación no es un diagrama decorativo. Es un control preventivo diseñado para reducir el radio de impacto y preservar la continuidad de los servicios esenciales.
Gestión de vulnerabilidades cuando los sistemas OT no pueden simplemente parchearse
NIS2 exige adquisición, desarrollo y mantenimiento seguros de sistemas de redes y de información, incluida la gestión y divulgación de vulnerabilidades. En TI, la gestión de vulnerabilidades suele significar identificar, priorizar, parchear y verificar. OT añade restricciones.
Una HMI crítica quizá solo pueda parchearse durante una parada planificada. Una actualización de firmware de PLC puede requerir intervención del proveedor. Un sistema certificado para seguridad funcional puede perder la certificación si se modifica incorrectamente. Algunos dispositivos heredados pueden no tener soporte del proveedor en absoluto.
Zenith Blueprint, fase Controles en acción, paso 19, proporciona la lógica de auditoría correcta para vulnerabilidades técnicas:
Para los sistemas que no puedan parchearse de inmediato, quizá por software heredado o restricciones de indisponibilidad, implante controles compensatorios. Esto puede incluir aislar el sistema detrás de un cortafuegos, limitar el acceso o aumentar la supervisión. Y, en todos los casos, registre y acepte formalmente el riesgo residual, demostrando que el problema no se ha olvidado.
La configuración de referencia de la política para pymes es igualmente práctica:
El inventario debe revisarse trimestralmente para identificar dispositivos obsoletos, no soportados o sin parchear
En Zenith Controls, el control 8.8 de ISO/IEC 27002:2022, Gestión de vulnerabilidades técnicas, se mapea como un control preventivo que soporta confidencialidad, integridad y disponibilidad, alineado con Identify y Protect, con la gestión de amenazas y vulnerabilidades como capacidad operativa en los dominios de Gobernanza, Ecosistema, Protección y Defensa.
Un expediente sólido de vulnerabilidades OT debe incluir:
- Identificador del activo, propietario, zona y criticidad
- Fuente de la vulnerabilidad, como aviso del proveedor, escáner, notificación del integrador o inteligencia de amenazas
- Restricciones de seguridad funcional y disponibilidad
- Viabilidad del parche y ventana de mantenimiento planificada
- Controles compensatorios, como aislamiento, listas de control de acceso, servicios deshabilitados o mayor supervisión
- Aprobación del propietario del riesgo y aceptación del riesgo residual
- Evidencia de verificación tras la remediación o la implantación del control compensatorio
Esto convierte «no podemos parchear» de una excusa en un tratamiento de riesgos auditable.
Acceso remoto de proveedores: el punto crítico entre NIS2 e IEC 62443
La mayoría de los incidentes OT tienen en algún punto una dimensión de tercero. Una cuenta de proveedor. Un portátil de integrador. Una herramienta de mantenimiento remoto. Una credencial compartida. Una excepción de cortafuegos que era temporal hace tres años.
El Artículo 21 de NIS2 incluye expresamente seguridad de la cadena de suministro, vulnerabilidades específicas de proveedores, prácticas de ciberseguridad de proveedores y procedimientos de desarrollo seguro. NIST CSF 2.0 también desarrolla este punto mediante criticidad de proveedores, requisitos contractuales, diligencia debida, supervisión continua, coordinación de incidentes y disposiciones de salida.
La Política de Seguridad de Terceros y Proveedores - pyme de Clarysec expresa el principio en lenguaje directo:
A los proveedores solo se les debe conceder acceso a los sistemas y datos mínimos necesarios para desempeñar su función.
Para OT, acceso mínimo significa algo más que acceso basado en roles en una aplicación. El acceso de proveedores debe estar:
- Preaprobado para una finalidad de mantenimiento definida
- Limitado en el tiempo y deshabilitado por defecto
- Protegido por MFA o autenticación continua cuando proceda
- Enrutado a través de un bastión de acceso seguro o una plataforma de acceso remoto controlado
- Limitado a la zona o activo OT pertinente
- Registrado, supervisado y, para accesos de alto riesgo, grabado a nivel de sesión
- Revisado tras su finalización
- Cubierto por obligaciones contractuales de seguridad y notificación de incidentes
La Política de Seguridad de IoT / OT corporativa incluye un requisito específico de acceso remoto:
El acceso remoto (para gestión o servicio por parte de proveedores) debe:
Esa cláusula ancla el punto de gobernanza, mientras que los requisitos detallados deben implantarse en procedimientos de acceso, acuerdos con proveedores, configuración técnica y flujos de trabajo de supervisión.
En Zenith Controls, el control 5.21 de ISO/IEC 27002:2022, Gestión de la seguridad de la información en la cadena de suministro TIC, se clasifica como un control preventivo que soporta confidencialidad, integridad y disponibilidad, alineado con el concepto Identify, con la seguridad de las relaciones con proveedores como capacidad operativa y Gobernanza, Ecosistema y Protección como dominios.
Para OT, ese mapeo ayuda a explicar por qué las evidencias de acceso remoto pertenecen al mismo tiempo a los expedientes de riesgo de proveedores, gobernanza de identidades, seguridad de redes, respuesta a incidentes y continuidad.
Respuesta a incidentes: el reloj de NIS2 se encuentra con la sala de control
Volvamos a la alarma de las 02:17. La organización debe decidir si el evento es significativo bajo NIS2. El Artículo 23 exige notificar sin dilación indebida los incidentes significativos que afecten a la prestación del servicio. La secuencia incluye una alerta temprana dentro de las 24 horas desde que se tenga conocimiento, una notificación del incidente dentro de las 72 horas, actualizaciones intermedias si se solicitan y un informe final a más tardar un mes después de la notificación del incidente, o un informe de progreso si el incidente sigue en curso.
En OT, la respuesta a incidentes debe responder preguntas que los procedimientos de respuesta de TI suelen ignorar:
- ¿Puede aislarse el dispositivo afectado sin crear un riesgo de seguridad funcional?
- ¿Quién tiene autoridad para detener la producción o cambiar a modo manual?
- ¿Qué registros son volátiles y requieren preservación inmediata?
- ¿Con qué proveedor o integrador debe contactarse?
- ¿El evento es malicioso, accidental, ambiental o causado por una configuración incorrecta?
- ¿Podría existir impacto transfronterizo o impacto sobre destinatarios del servicio?
- ¿Hay datos personales involucrados, como registros de tarjetas de acceso, CCTV, datos de empleados o registros de atención al cliente?
La política OT para pymes proporciona una regla sencilla de escalado de anomalías:
Toda anomalía debe notificarse inmediatamente al Director General para que adopte medidas adicionales
También incluye un principio de contención sensible a la seguridad funcional:
El dispositivo debe desconectarse de la red inmediatamente, siempre que sea seguro hacerlo
Esas últimas cinco palabras son críticas. La respuesta OT no puede copiar ciegamente las acciones de contención de TI. «Siempre que sea seguro hacerlo» debe reflejarse en procedimientos operativos, matrices de escalado, formación y ejercicios de mesa.
| Fase del incidente | Decisión específica de OT | Evidencia a conservar |
|---|---|---|
| Detección | ¿La alerta es una anomalía operativa, un evento cibernético, un evento de seguridad física o un evento combinado? | Registro de alerta, nota del operador, datos de supervisión, triaje inicial |
| Clasificación | ¿La interrupción del servicio, la pérdida financiera o el impacto en terceros podrían hacerlo significativo? | Evaluación de severidad, lista de servicios afectados, estimación de impacto |
| Contención | ¿Puede realizarse el aislamiento de forma segura o se requiere contención compensatoria? | Aprobación de ingeniería, registro de acciones de contención, evaluación de seguridad funcional |
| Notificación | ¿Se requiere alerta temprana en 24 horas y notificación en 72 horas? | Decisión de notificación, comunicación con la autoridad, aprobaciones con marca temporal |
| Recuperación | ¿Qué sistemas deben restaurarse primero para mantener un servicio seguro? | Procedimiento de recuperación, validación de copias de seguridad, verificación de activos restaurados |
| Lecciones aprendidas | ¿Qué controles fallaron o requieren mejora? | Análisis de causa raíz, plan de acciones correctivas, actualización del registro de riesgos |
NIST CSF 2.0 encaja bien aquí. Sus resultados Respond y Recover cubren triaje, categorización, escalado, análisis de causa raíz, integridad de evidencias, notificación a partes interesadas, contención, erradicación, restauración, comprobaciones de integridad de copias de seguridad y comunicaciones de recuperación.
Construir una línea de evidencias de riesgo a control
Una forma práctica de evitar el cumplimiento fragmentado es construir una línea única de evidencias desde el riesgo hasta la regulación, el control y la prueba.
Escenario: un proveedor remoto de compresores requiere acceso a una estación de ingeniería en la red OT. La estación puede modificar la lógica de PLC. La cuenta del proveedor está siempre habilitada, es compartida por varios ingenieros del proveedor y solo está protegida por contraseña. La estación ejecuta software que no puede actualizarse hasta la próxima parada de mantenimiento.
Escriba el escenario de riesgo en el registro de riesgos:
«El acceso remoto no autorizado o comprometido de un proveedor a una estación de ingeniería OT podría provocar cambios no autorizados en la lógica de PLC, interrupción de la producción, impacto en la seguridad funcional e interrupción de servicio notificable bajo NIS2.»
A continuación, mapee los controles y obligaciones.
| Elemento de tratamiento de riesgos | Mapeo seleccionado |
|---|---|
| NIS2 | Artículo 21 seguridad de la cadena de suministro, control de acceso, MFA, gestión de incidentes, continuidad del negocio, gestión de vulnerabilidades |
| ISO/IEC 27001:2022 | Evaluación de riesgos, tratamiento de riesgos, Declaración de Aplicabilidad, supervisión por el liderazgo, información documentada |
| ISO/IEC 27002:2022 | Seguridad de proveedores, cadena de suministro TIC, control de acceso, seguridad de redes, segregación, registro de eventos, supervisión, gestión de vulnerabilidades, respuesta a incidentes |
| IEC 62443 | Acceso de proveedores mediante conducto controlado, gestión de cuentas, privilegio mínimo, aislamiento de zonas, objetivo de nivel de seguridad para la ruta de acceso remoto |
| NIST CSF 2.0 | GV.SC gobernanza de proveedores, PR.AA identidad y acceso, DE.CM supervisión, RS.MA gestión de incidentes, RC.RP recuperación |
| Evidencia | Procedimiento de acceso de proveedores, registros MFA, configuración de servidor de salto, reglas de cortafuegos, grabaciones de sesión, cláusulas contractuales de proveedor, excepción de vulnerabilidad, prueba de ejercicio de mesa |
El plan de tratamiento debe deshabilitar el acceso permanente del proveedor, exigir identidades nominativas del proveedor, aplicar MFA, enrutar el acceso a través de un servidor de salto controlado, limitar el acceso a la estación de ingeniería, exigir aprobación mediante ticket de mantenimiento, grabar sesiones privilegiadas, supervisar comandos y tráfico anómalo, documentar la estación sin parchear como excepción de vulnerabilidad y probar la respuesta a incidentes ante actividad sospechosa del proveedor.
Zenith Blueprint, fase de Gestión de riesgos, paso 13, proporciona la lógica de trazabilidad de la SoA:
Referencias cruzadas regulatorias: si determinados controles se implantan específicamente para cumplir con el RGPD de la UE, NIS2 o DORA, puede indicarse en el Registro de Riesgos (como parte de la justificación del impacto del riesgo) o en las notas de la SoA.
La lección práctica es sencilla. No mantenga las evidencias de NIS2, ISO e ingeniería OT en silos separados. Añada columnas en el registro de riesgos y en la SoA para el tema del Artículo 21 de NIS2, el control de ISO/IEC 27002:2022, la familia de requisitos IEC 62443, el propietario de la evidencia y el estado de auditoría.
Dónde encajan el RGPD de la UE y DORA en la seguridad OT
La seguridad OT no trata siempre solo de máquinas. Los entornos de infraestructuras críticas suelen tratar datos personales mediante CCTV, sistemas de control de acceso, registros de tarjetas de acceso, sistemas de seguridad de la plantilla, tickets de mantenimiento, seguimiento de vehículos, sistemas de visitantes y plataformas de atención al cliente.
El RGPD de la UE exige que los datos personales se traten de forma lícita, leal y transparente, se recopilen con fines específicos, se limiten a lo necesario, se mantengan exactos, se conserven solo durante el tiempo necesario y se protejan con medidas técnicas y organizativas adecuadas. También exige responsabilidad proactiva, lo que significa que el responsable del tratamiento debe poder demostrar el cumplimiento.
Para OT, esto significa que los registros de acceso y los registros de supervisión no deben convertirse en almacenes de datos de vigilancia no controlados. La conservación, los derechos de acceso, la limitación de finalidad y la evaluación de brechas deben diseñarse dentro del registro de eventos y la supervisión.
DORA puede aplicarse cuando intervienen entidades financieras o cuando un proveedor tercero de servicios TIC sustenta la resiliencia operativa del sector financiero. DORA cubre gestión del riesgo de las TIC, notificación de incidentes, pruebas de resiliencia y riesgo de terceros TIC. Para entidades financieras que también sean entidades esenciales o importantes bajo las normas de transposición de NIS2, DORA puede actuar como régimen sectorial específico para obligaciones solapadas, aunque la coordinación con las autoridades NIS2 puede seguir siendo relevante.
Se aplican las mismas disciplinas de evidencias: identificación de activos, protección, detección, continuidad, copia de seguridad, riesgo de terceros, pruebas, formación y supervisión por la dirección.
La perspectiva de auditoría: un control, múltiples perspectivas de aseguramiento
Una implantación sólida de seguridad OT conforme a NIS2 debe resistir múltiples perspectivas de auditoría.
| Perspectiva del auditor | Pregunta probable | Evidencia válida |
|---|---|---|
| ISO/IEC 27001:2022 | ¿OT está dentro del alcance y los riesgos OT se evalúan, tratan y reflejan en la SoA? | Alcance del SGSI, registro de riesgos, SoA, procedimientos documentados, muestra de auditoría interna |
| Autoridad competente NIS2 | ¿Las medidas previenen o minimizan el impacto sobre servicios esenciales o importantes? | Mapa de dependencias del servicio, mapeo del Artículo 21, análisis de impacto de incidentes, aprobaciones de la dirección |
| Especialista IEC 62443 | ¿Las zonas, conductos y prácticas de mantenimiento seguro están definidos y aplicados? | Modelo de zonas, diagramas de conductos, reglas de cortafuegos, rutas de acceso remoto, controles del ciclo de vida |
| Evaluador NIST CSF 2.0 | ¿El programa soporta resultados GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER? | Perfil CSF, plan de brechas, registros de supervisión, evidencias de respuesta y recuperación |
| Auditor COBIT 2019 o ISACA | ¿Están gobernados la propiedad, el desempeño y el aseguramiento? | RACI, KPI, aprobaciones de cambios, hallazgos de auditoría, seguimiento de remediación |
Por eso Clarysec trata Zenith Controls como una brújula de cumplimiento transversal. Sus atributos de control ayudan a explicar el propósito de los controles oficiales de ISO/IEC 27002:2022, mientras que el enfoque de mapeo conecta esos controles con NIS2, NIST CSF, gobernanza de proveedores, continuidad y evidencias de auditoría.
Errores comunes de implantación de NIS2 en OT
Los fallos más comunes de seguridad OT rara vez se deben a falta de documentos. Se deben a documentos que no reflejan la planta.
Error 1: TI es propietaria del programa NIS2, pero OT es propietaria del riesgo. Operaciones, ingeniería, seguridad física y mantenimiento deben participar.
Error 2: El inventario de activos se detiene en los servidores. Un inventario OT debe incluir PLC, RTU, HMI, historiadores de datos, estaciones de ingeniería, conmutadores industriales, sensores, pasarelas, dispositivos de acceso remoto y componentes gestionados por proveedores.
Error 3: La segmentación existe en un diagrama, pero no en las reglas de cortafuegos. Los auditores solicitarán evidencias de aplicación, control de cambios y supervisión.
Error 4: Las excepciones de vulnerabilidades son informales. Las restricciones heredadas solo son aceptables cuando están documentadas, aprobadas, supervisadas y revisadas periódicamente.
Error 5: El acceso de proveedores se trata solo como un asunto de proveedores. También es un asunto de control de acceso, registro de eventos, supervisión, seguridad de redes, respuesta a incidentes y continuidad.
Error 6: La respuesta a incidentes ignora la seguridad funcional. Los procedimientos de respuesta OT deben definir quién puede aislar dispositivos, detener procesos, cambiar modos o contactar con reguladores.
Error 7: La notificación NIS2 no se ensaya. El proceso de decisión de 24 y 72 horas debe probarse antes de un evento real.
La ruta de implantación de Clarysec: de la responsabilidad del consejo de administración a las evidencias OT
Una implantación práctica de seguridad OT conforme a NIS2 puede seguir esta secuencia:
- Confirmar el alcance NIS2, la clasificación de la entidad y la criticidad del servicio.
- Definir el alcance OT dentro del SGSI, incluidas interfaces y dependencias.
- Construir un inventario de activos OT y flujos de datos.
- Identificar obligaciones legales, contractuales, de seguridad funcional, privacidad y sectoriales.
- Ejecutar talleres de evaluación de riesgos específicos de OT con ingeniería, operaciones, TI, SOC, compras y dirección.
- Mapear el tratamiento de riesgos a controles ISO/IEC 27002:2022, temas NIS2 y patrones de implantación IEC 62443.
- Actualizar la Declaración de Aplicabilidad con justificación OT y propietarios de evidencias.
- Implantar controles prioritarios: segmentación, acceso de proveedores, gestión de vulnerabilidades, supervisión, copias de seguridad y respuesta a incidentes.
- Actualizar políticas y procedimientos, incluida seguridad OT, seguridad de proveedores, acceso remoto, respuesta a incidentes y continuidad del negocio.
- Ejecutar ejercicios de mesa y validación técnica.
- Preparar paquetes de auditoría para NIS2, ISO/IEC 27001:2022, aseguramiento de clientes y gobernanza interna.
- Incorporar los hallazgos a la revisión por la dirección y a la mejora continua.
Esto refleja el modelo operativo de Zenith Blueprint, especialmente el paso 13 para tratamiento de riesgos y trazabilidad de la SoA, el paso 14 para desarrollo de políticas y referencias cruzadas regulatorias, el paso 19 para gestión de vulnerabilidades y el paso 20 para seguridad de redes.
El mismo enfoque utiliza las políticas de Clarysec para convertir el lenguaje de frameworks en reglas operativas. La Política de Seguridad de IoT / OT corporativa exige una revisión de arquitectura de seguridad antes del despliegue:
Todos los nuevos dispositivos IoT/OT deben someterse a una Revisión de Arquitectura de Seguridad antes del despliegue. Esta revisión debe validar:
También establece:
Todo el tráfico dentro de las redes IoT/OT y entre ellas debe supervisarse de forma continua mediante:
Esas cláusulas crean anclajes de gobernanza. Las evidencias de implantación pueden incluir alertas IDS OT, registros de cortafuegos, correlación SIEM, perfiles de tráfico de referencia, tickets de anomalías y registros de respuesta.
Cómo son unas buenas evidencias OT para NIS2
Un paquete de evidencias OT para NIS2 debe ser lo bastante práctico para los ingenieros y lo bastante estructurado para los auditores.
Para segmentación, incluya arquitectura aprobada, diagramas de zonas y conductos, exportaciones de reglas de cortafuegos, registros de cambios, revisiones periódicas de reglas, registros de excepciones y alertas de supervisión.
Para acceso de proveedores, incluya evaluación de criticidad del proveedor, cláusulas contractuales, procedimiento de acceso aprobado, cuentas nominativas, evidencias MFA, registros de acceso, grabaciones de sesión, revisión periódica de accesos y registros de baja.
Para gestión de vulnerabilidades, incluya inventario, fuentes de avisos, resultados de descubrimiento pasivo, tickets de vulnerabilidades, planes de parcheado, controles compensatorios, aceptación del riesgo y evidencias de cierre.
Para respuesta a incidentes, incluya procedimientos de respuesta, contactos de escalado, árbol de decisión de notificación NIS2, resultados de ejercicios de mesa, tickets de incidentes, borradores de notificación a autoridades, reglas de manejo de evidencias y lecciones aprendidas.
Para continuidad, incluya estrategia de copias de seguridad OT, copias de seguridad offline o protegidas, resultados de pruebas de restauración, lista de repuestos críticos, procedimientos operativos manuales, prioridades de recuperación y planes de comunicación de crisis.
Para gobernanza, incluya aprobación del consejo de administración o de la dirección, asignación de roles, registros de formación, resultados de auditoría interna, KPI, actas de revisión de riesgos y decisiones de revisión por la dirección.
Este modelo de evidencias se alinea con ISO/IEC 27001:2022 porque soporta el tratamiento de riesgos, la información documentada, la evaluación del desempeño y la mejora continua. Se alinea con NIS2 porque demuestra medidas adecuadas y proporcionadas. Se alinea con IEC 62443 porque puede trazarse hasta la arquitectura OT y los controles de ingeniería.
Convierta su programa de seguridad OT en preparación auditable para NIS2
Si su entorno OT sustenta un servicio crítico o regulado, esperar a que un regulador, un cliente o un incidente exponga las brechas es la estrategia equivocada.
Empiece con un caso de uso de alto impacto: acceso remoto de proveedores a una zona OT crítica, gestión de vulnerabilidades para activos industriales sin soporte o segmentación entre TI corporativa y OT. Construya el escenario de riesgo, mapéelo al Artículo 21 de NIS2, seleccione controles ISO/IEC 27002:2022, tradúzcalos a patrones de implantación IEC 62443 y recopile las evidencias.
Clarysec puede ayudarle a acelerar ese trabajo con Zenith Blueprint, Zenith Controls, la Política de Seguridad de IoT / OT, la Política de seguridad de Internet de las Cosas (IoT) / Tecnología Operativa (OT) - pyme y la Política de Seguridad de Terceros y Proveedores - pyme.
Su siguiente acción: elija un servicio OT, mapee sus activos y dependencias, y cree esta semana una línea de evidencias de riesgo a control. Si desea una ruta de implantación estructurada, la hoja de ruta de 30 pasos y el kit de herramientas de cumplimiento transversal de Clarysec pueden convertir esa primera línea en un programa completo de seguridad OT conforme a NIS2.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
