Por qué la discusión sobre el marco de ciberseguridad de OT ha cambiado

En 2021, un actor de amenazas accedió a la planta de tratamiento de agua en Oldsmar, Florida, e intentó aumentar los niveles de hidróxido de sodio a concentraciones potencialmente letales. La intrusión duró solo unos minutos. Las consecuencias, si un operador no hubiera notado que el cursor se movía en su pantalla, podrían haber afectado a más de 15,000 residentes. El vector de ataque fue una herramienta de acceso remoto heredada. El sistema de control industrial no tenía segmentación de red ni monitoreo específico para OT.

Antes de continuar, no olvide consultar nuestra publicación de blog anterior sobre el descifrado del último aviso de CISA sobre Zero Trust para tecnología operativa aquí.

Este no fue un incidente aislado. El malware Industroyer2 en 2022, diseñado para interactuar directamente con subestaciones que utilizan el protocolo IEC 104 en Ucrania, demostró que los adversarios ahora están construyendo herramientas diseñadas específicamente para entornos de tecnología operativa. Cuando Mandiant y CISA publicaron su aviso conjunto, se destacó un hallazgo: muchas de las organizaciones objetivo no tenían una postura base de seguridad de OT a la cual regresar.

Este es el entorno en el que debe entenderse el Marco de Ciberseguridad de NIST para OT. No como una casilla de verificación de cumplimiento, sino como una base estructural para organizaciones cuyos sistemas, en caso de interrupción, pueden afectar la seguridad pública, la seguridad nacional o la continuidad económica.

El Marco de Ciberseguridad (CSF) 2.0 de NIST, publicado en febrero de 2024, marca la primera vez que el NIST amplió explícitamente el alcance del marco más allá de la infraestructura crítica a todas las organizaciones, introduciendo simultáneamente la gobernanza como una función de primer nivel. Para los profesionales de la seguridad de OT, esta transición es de gran trascendencia.

Entendiendo el NIST CSF en el contexto de la seguridad de ICS y SCADA

La tensión principal: la lógica de seguridad de TI en entornos de OT

El modo de falla más común cuando las organizaciones aplican un marco de ciberseguridad a entornos de OT es la suposición de que los principios de seguridad de TI se traducen directamente. No es así. En TI, la confidencialidad es la principal preocupación de seguridad. En OT, predominan la disponibilidad y la integridad; un comando de escritura Modbus que falsea los datos de los sensores es mucho más peligroso que una hoja de cálculo filtrada.

Los sistemas SCADA que gestionan líneas de transmisión de alta tensión, los Sistemas de Control Distribuido (DCS) en plantas de procesamiento químico y los PLC en las líneas de ensamblaje automotriz operan con protocolos de comunicación en tiempo real (DNP3, Modbus, PROFINET, EtherNet/IP) que preceden al pensamiento de ciberseguridad moderno. Muchos de estos sistemas no pueden tolerar la latencia introducida por los dispositivos de seguridad en línea. Algunos no se pueden actualizar. Las actualizaciones de firmware en sistemas instrumentados de seguridad (SIS) pueden requerir paros completos del proceso que duren días.

Aplicar el NIST CSF a la seguridad de ICS y SCADA, por lo tanto, requiere una capa de traducción deliberada: una que preserve la continuidad del proceso mientras construye arquitecturas defendibles.

NIST CSF 2.0: Qué cambió y por qué es importante para OT

La actualización de 2024 al marco introdujo seis funciones principales: Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar. Para las organizaciones que protegen entornos industriales, la adición de Gobernar (GV) es particularmente significativa. Formaliza lo que muchos programas maduros de seguridad de OT ya entendían intuitivamente: la seguridad sostenible requiere compromiso organizacional, no solo controles técnicos.

NIST CSF 2.0 también introdujo perfiles de implementación escalonados más adaptables a las limitaciones de OT, y sus recursos asociados ahora hacen referencia explícita a NIST SP 800-82 Rev.3 como la guía complementaria para sistemas de control industrial. Esta integración señala el reconocimiento de NIST de que la seguridad de OT no se puede abordar a través de un único documento generalista.

Las seis funciones principales del CSF aplicadas a entornos industriales

1. Gobernar (GV): Construyendo la base organizacional

La función Gobernar establece las políticas, los roles y las estrategias de gestión de riesgos que dan dirección a todas las demás actividades de seguridad. En entornos de OT/ICS, esto significa formalizar la intersección entre el riesgo operativo y el riesgo cibernético, un diálogo que históricamente ha sido difícil porque los equipos de ingeniería y los de TI/seguridad a menudo hablan diferentes lenguajes de riesgo.

La implementación práctica aquí implica la creación de una Política de Ciberseguridad de OT que considere explícitamente los requisitos de disponibilidad del proceso, la definición de la propiedad de los activos de OT (a menudo dividida entre TI, ingeniería de OT y operaciones de planta), y el establecimiento de una estrategia de gestión de riesgos alineada con los marcos de cumplimiento pertinentes como NERC CIP para empresas eléctricas, IEC 62443 para automatización industrial o las Directivas de Seguridad de la TSA para operadores de tuberías.

• Establecer un comité de gobernanza de riesgos específico para OT con representación de operaciones, ingeniería y seguridad.

• Definir umbrales de riesgo aceptables para las interrupciones operativas, no solo escenarios de brechas de datos.

• Alinear la gobernanza de ciberseguridad con los requisitos regulatorios específicos del sector desde el principio.

2. Identificar (ID): Saber qué está protegiendo

No se puede asegurar lo que no se puede ver. En entornos de OT, el inventario de activos es notoriamente difícil. A diferencia de los entornos de TI donde Active Directory proporciona un punto de partida, las redes de OT a menudo contienen activos que nunca se han documentado formalmente: RTU heredadas instaladas hace una década, estaciones de trabajo de ingeniería con Windows XP, dispositivos de campo agregados durante proyectos de capital sin revisión de seguridad.

La función Identificar, aplicada a ICS, requiere catalogar PLC, RTU, HMI, estaciones de trabajo de ingeniería, servidores historiadores y toda la infraestructura de red en el entorno de OT. De manera crítica, este inventario debe capturar los patrones de comunicación: qué se comunica con qué, utilizando qué protocolo y en qué segmento de red.

Las herramientas de monitoreo pasivo de red como Claroty, Nozomi Networks, Dragos Platform y Microsoft Defender para IoT pueden descubrir activos sin enviar paquetes que puedan interrumpir las comunicaciones del proceso. El escaneo activo, práctica estándar en TI, puede causar estados de falla en los PLC y debe evitarse o limitarse cuidadosamente en entornos de OT.

Una importante empresa eléctrica norteamericana descubrió más de 2,400 activos de OT que antes no se rastreaban durante su primer proyecto de descubrimiento pasivo de red. La mayoría estaba en la red de tecnología operativa, pero nunca habían aparecido en ningún registro de CMDB.

3. Proteger (PR): Implementación de defensas en capas

La función Proteger abarca el control de acceso, la gestión de identidades, la seguridad de datos, la tecnología de protección y la capacitación en seguridad. En entornos de OT, esta función requiere un enfoque en capas basado en el Modelo Purdue o en la arquitectura de zonas y conductos ISA/IEC 62443.

La segmentación de red sigue siendo el único control de protección de mayor valor en entornos industriales. Una implementación adecuada significa zonas DMZ entre las redes de TI y OT, filtrado estricto del tráfico en cada límite de nivel Purdue y firewalls con capacidad para inspeccionar protocolos industriales en lugar de simplemente dejarlos pasar basándose únicamente en números de puerto.

El acceso remoto se ha convertido en un vector de ataque crítico. Los proveedores de ingeniería, los integradores y los servicios de monitoreo remoto requieren conectividad a los sistemas de OT. Las mejores prácticas exigen servidores de salto dedicados en las DMZ de OT, MFA para todas las sesiones de acceso remoto, registro de sesiones y aprovisionamiento de acceso justo a tiempo, eliminando los túneles VPN siempre activos hacia las redes operativas.

• Implementar pasarelas de seguridad unidireccionales (diodos de datos) donde no se requiera comunicación bidireccional en tiempo real.

• Reforzar las configuraciones de HMI y estaciones de trabajo de ingeniería: deshabilitar puertos USB, restringir listas de aplicaciones permitidas, eliminar servicios innecesarios.

• Aplicar MFA a todas las rutas de acceso con privilegios y de acceso remoto en las redes de OT.

• Realizar capacitaciones periódicas de concientización sobre seguridad diseñadas para operadores de OT, no simulaciones genéricas de phishing.

4. Detectar (DE): Reconocimiento de amenazas en contextos específicos de OT

La detección en entornos de OT requiere un enfoque fundamentalmente diferente al monitoreo de seguridad de TI. Las implementaciones estándar de SIEM que buscan registros de eventos de Windows e intentos fallidos de autenticación pasan por alto los comportamientos específicos de ICS más peligrosos: reprogramación no autorizada de PLC, cambios inesperados en los puntos de ajuste del proceso, comunicación anómala entre componentes que no deberían comunicarse.

Los sistemas de detección de intrusiones con reconocimiento de ICS, plataformas que entienden las comunicaciones DNP3, Modbus, EtherNet/IP y OPC a nivel de protocolo, son esenciales. Estos sistemas establecen líneas base de comunicación normal del proceso y generan alertas sobre desviaciones. Dragos, Claroty y Nozomi Networks han desarrollado lógicas de detección que consideran los comportamientos específicos asociados con familias de malware de ICS, incluidos TRITON/TRISIS (dirigido a sistemas instrumentados de seguridad), Industroyer y BlackEnergy.

Los programas de detección eficaces en entornos de OT también requieren la integración entre los historiadores de procesos y el monitoreo de seguridad, correlacionando los datos del sistema de control con los eventos de red para identificar escenarios en los que un ciberataque pueda manifestarse como una anomalía en el proceso en lugar de una alarma de red.

En el ataque TRITON/TRISIS contra una planta petroquímica de Oriente Medio, el malware se dirigió específicamente al Sistema Instrumentado de Seguridad Triconex, la última línea de defensa antes de una catástrofe física. La detección se logró a través de un intento fallido de redistribución, no a través de una herramienta de seguridad.

5. Responder (RS): Planificación de respuesta a incidentes específica de OT

La respuesta a incidentes en entornos de OT conlleva limitaciones que no existen en TI. Un equipo de seguridad no puede simplemente aislar un servidor comprometido que ejecuta un proceso químico por lotes sin desencadenar potencialmente una condición de peligro. Los procedimientos de respuesta deben desarrollarse en estrecha colaboración con los equipos de operaciones e ingeniería de seguridad, y deben tener en cuenta el impacto operativo de cada acción de respuesta.

Los planes de respuesta a incidentes de OT deben definir una autoridad clara para la toma de decisiones: quién puede autorizar el aislamiento de la red, a quién se debe notificar antes de apagar un sistema de control y cuáles son los procedimientos operativos manuales si los sistemas automatizados no están disponibles. Los simulacros teóricos de mesa que simulan escenarios de ataques específicos de ICS (ransomware que cifra servidores historiadores, modificación no autorizada de la lógica de PLC, compromiso de HMI) son esenciales para validar estos planes antes de que sean necesarios.

Las organizaciones cubiertas por NERC CIP, avisos de CISA o marcos específicos de sector también deben comprender sus obligaciones de notificación regulatoria: los plazos para reportar incidentes cibernéticos a CISA, ISAC sectoriales y reguladores varían según la industria y el tipo de incidente.

6. Recuperar (RC): Restaurar operaciones de forma segura

La función Recuperar se enfoca en mantener la resiliencia y restaurar las capacidades después de un incidente. Para los entornos de OT, la planificación de la recuperación debe abordar tres requisitos distintos: restaurar los controles de ciberseguridad, restaurar la integridad de los datos del proceso y restaurar la continuidad operativa, en un orden que garantice que la seguridad nunca se vea comprometida.

Los respaldos seguros y fuera de línea de la lógica de PLC, las configuraciones de HMI, los datos de historiadores y las configuraciones de dispositivos de red son activos fundamentales para la recuperación. Estos respaldos deben almacenarse en entornos aislados de las redes de producción y probarse regularmente mediante ejercicios de restauración. Muchas organizaciones descubren durante un incidente real que sus respaldos están incompletos, desactualizados o son incompatibles con las versiones de hardware actuales.

La recuperación también incluye el análisis posterior al incidente: comprender cómo el adversario obtuvo acceso, qué hizo dentro del entorno y qué cambios se realizaron en las configuraciones del proceso durante el periodo de intrusión.

Ruta de implementación en 7 pasos para equipos de seguridad de OT

Traducir el NIST CSF en un programa de seguridad de OT ejecutable requiere un enfoque estructurado de implementación. La siguiente ruta de siete pasos, adaptada de la propia guía de implementación del NIST y alineada con los requisitos de ISA/IEC 62443, proporciona un camino práctico desde la evaluación inicial hasta la mejora medible de la seguridad.

Paso 1: Priorizar y definir el alcance de los sistemas críticos de OT

Antes de realizar cualquier inversión en seguridad, las organizaciones deben establecer qué sistemas de OT están dentro del alcance y por qué. Esto no es simplemente un ejercicio técnico: requiere la participación de operaciones, ingeniería, área legal y el liderazgo ejecutivo. Los sistemas que respaldan funciones de seguridad, la continuidad de la producción o el cumplimiento regulatorio deben recibir la máxima prioridad.

El alcance del proyecto debe alinearse con las definiciones de zona de ISA/IEC 62443. Defina qué sistemas constituyen la Zona 0 (dispositivos de campo), Zona 1 (control básico), Zona 2 (control de supervisión) y Zona 3 (operaciones de manufactura), y establezca qué zonas están dentro del alcance inmediato del programa de seguridad frente a las fases diferidas.

Paso 2: Comprender los sistemas y requisitos de cumplimiento

Comprender el panorama de amenazas para su sector específico es esencial. Una estación de compresión de gas natural enfrenta diferentes perfiles de actores de amenazas que una planta de fabricación de automóviles. Los avisos de ICS-CERT de CISA, los ISAC específicos del sector (E-ISAC para electricidad, WaterISAC para empresas de agua, A-ISAC para aviación) y el informe anual Year in Review de Dragos proporcionan inteligencia de amenazas específica del sector que debe fundamentar sus requisitos de seguridad.

ISA/IEC 62443 define Niveles de Seguridad (SL 1-4) que describen la resistencia ante el aumento de la capacidad de los adversarios, desde atacantes casuales hasta actores estatales con conocimiento interno. Establecer a qué nivel SL deben apuntar sus sistemas críticos es un requisito fundamental de este paso.

Paso 3: Crear el perfil de ciberseguridad actual

Un perfil actual es una instantánea de la implementación actual de la organización en las categorías y subcategorías de CSF. En entornos de OT, esta evaluación debe realizarse con un contexto específico de OT, no simplemente importada de una evaluación de seguridad de TI. Un equipo de TI que nunca ha trabajado en un entorno de sistemas de control subestimará sistemáticamente los riesgos y recomendará controles que operativamente resultan poco prácticos.

Las evaluaciones realizadas con respecto a los controles de NIST SP 800-82 Rev.3 proporcionan una base de referencia estructurada que se mapea directamente con las funciones de CSF y es reconocida por los reguladores, incluidos CISA, la EPA (para empresas de servicios de agua) y FERC (para empresas eléctricas).

Paso 4: Realizar la evaluación de riesgos de OT

La metodología de evaluación de riesgos de OT debe incorporar un análisis de consecuencias que refleje la realidad operativa. Un modelo de riesgo que trata todos los compromisos de los sistemas de control como iguales pasa por alto la distinción crítica entre, por ejemplo, el acceso no autorizado a un servidor historiador frente al acceso no autorizado a un PLC de seguridad que gestiona la lógica de control de quemadores.

La metodología Consequence-Driven Cyber-Informed Engineering (CCE) de CISA proporciona un marco excelente para el análisis de consecuencias en infraestructuras críticas. Al comenzar con los escenarios de mayor consecuencia (qué acciones de un adversario podrían causar el mayor daño) y trabajar hacia atrás para identificar las rutas cibernéticas que podrían habilitar esos escenarios, las organizaciones construyen evaluaciones de riesgos que reflejan consecuencias del mundo físico en lugar de matrices de puntuación abstractas.

Pasos 5-7: Del perfil objetivo a la implementación

Definir un perfil objetivo requiere el reconocimiento honesto de las limitaciones operativas. En entornos donde aplicar un parche de firmware a un PLC específico requiere un paro programado de 72 horas, los equipos de seguridad deben diseñar controles de compensación (monitoreo de red, control de acceso estricto, listas de aplicaciones permitidas en sistemas HMI adyacentes) en lugar de simplemente registrar la vulnerabilidad como no mitigada.

El análisis de brechas transforma la diferencia entre el estado actual y el objetivo en una ruta de remediación priorizada. La priorización debe ponderar significativamente el potencial de reducción de riesgos: una mejora de segmentación de bajo costo que elimine una ruta de ataque de alta gravedad ofrece más valor de seguridad que el despliegue de una costosa solución de seguridad de terminales en sistemas con baja exposición.

Mejores prácticas de ciberseguridad industrial por sector

Empresas eléctricas: Alineación de NERC CIP y CSF

Las empresas de electricidad que gestionan activos del Bulk Electric System (BES) en América del Norte están sujetas a los estándares de confiabilidad NERC CIP, uno de los marcos regulatorios de seguridad de OT más maduros y prescriptivos que existen. Para estas organizaciones, el NIST CSF sirve como un marco de nivel superior que demuestra la madurez del programa de seguridad más allá de los mínimos de cumplimiento de NERC CIP, algo que los reguladores y las juntas directivas esperan cada vez más.

NERC CIP-007 (Gestión de la seguridad de los sistemas), CIP-010 (Gestión de cambios de configuración y vulnerabilidades) y CIP-013 (Gestión de riesgos de la cadena de suministro) se mapean directamente con las funciones Proteger e Identificar del CSF. Sin embargo, NERC CIP tradicionalmente ha sido binario: o bien se cumple la norma o no se cumple. El modelo de madurez escalonado del CSF ayuda a las empresas eléctricas a comprender su postura de seguridad en un continuo en lugar de limitarse a un mero estatus de cumplimiento.

Petróleo y Gas: Protección de operaciones de campo distribuidas

Las operaciones de petróleo y gas presentan desafíos únicos: activos distribuidos geográficamente, amplia dependencia de RTU heredadas en estaciones remotas de monitoreo de tuberías, comunicaciones satelitales y celulares con ancho de banda limitado para herramientas de seguridad, y complejas relaciones con contratistas y proveedores. La función Identificar del CSF (particularmente el inventario de activos y la evaluación de riesgos) suele ser el área de menor madurez en este sector.

Las Directivas de Seguridad de 2021 y 2022 de la TSA para operadores de tuberías ordenaron medidas específicas de ciberseguridad para OT tras el incidente de ransomware de Colonial Pipeline, que aunque fue principalmente un compromiso de TI, demostró el impacto operativo de la interconexión de TI y OT. Las organizaciones cubiertas por estas directivas consideran que los programas alineados con el CSF proporcionan una estructura práctica para cumplir con los requisitos directivos mientras construyen una postura de seguridad sostenible a largo plazo.

Agua y Aguas Residuales: Seguridad de OT con recursos limitados

El sector del agua se encuentra entre los de infraestructura crítica con mayores limitaciones de recursos desde la perspectiva de ciberseguridad. La mayoría de los organismos operadores de agua son sistemas públicos pequeños con personal y presupuestos limitados para la seguridad de TI/OT. WaterISAC de CISA y las Mejores Prácticas de Ciberseguridad de la EPA de 2024 brindan orientación específica del sector alineada con las funciones de CSF.

El incidente de Oldsmar destacó una vulnerabilidad recurrente en el sector: el acceso remoto a través de herramientas de tipo comercial (TeamViewer en ese caso), credenciales compartidas y nula segmentación de red en OT. La implementación de la función Proteger del CSF, específicamente el control de acceso (PR.AC) y la tecnología de protección (PR.PT), aborda estas brechas más críticas incluso dentro de presupuestos limitados.

Manufactura: Expansión de IIoT y la evolución de la superficie de ataque

Las iniciativas de manufactura inteligente (gemelos digitales, redes de sensores IIoT, plataformas de mantenimiento predictivo) están expandiendo la superficie de ataque de OT más rápido de lo que los programas de seguridad logran adaptarse. Cada nuevo dispositivo conectado representa un punto de entrada potencial, y los entornos de manufactura a menudo carecen de los procesos maduros de gestión de cambios que someterían las nuevas conexiones de OT a una revisión de seguridad.

La función Gobernar del CSF es particularmente relevante aquí: las organizaciones que cuentan con políticas de ciberseguridad claras que dictan la adquisición de dispositivos IIoT, el despliegue y las revisiones de configuración de seguridad antes de habilitar su conectividad en producción, están sustancialmente mejor posicionadas que aquellas que tratan al IIoT como una decisión puramente de ingeniería.

Errores comunes de implementación y cómo evitarlos

Construyendo un programa de seguridad de OT sostenible

El Marco de Ciberseguridad de NIST, aplicado con disciplina específica para OT, proporciona a las organizaciones industriales un camino estructurado para transitar de medidas de seguridad reactivas y fragmentadas hacia una postura de seguridad proactiva y gestionada mediante riesgos. La fortaleza del marco no reside en su carácter prescriptivo, sino en su flexibilidad; se adapta a la enorme diversidad de entornos de sistemas de control industrial, desde subestaciones de alta tensión hasta sistemas de procesamiento farmacéutico por lotes o plataformas petroleras en alta mar.

Las organizaciones que implementan con éxito programas de seguridad de OT alineados con el CSF comparten varias características: tratan la seguridad como una disciplina operativa y no como una función de TI acoplada a la fuerza a sistemas de ingeniería; invierten en experiencia específica de OT, ya sea de forma interna o mediante socios especializados; y construyen programas que pueden demostrar una reducción medible del riesgo en lugar de simplemente estar listos para una auditoría.

La nueva función Gobernar de NIST CSF 2.0, combinada con la profundidad técnica de SP 800-82 Rev.3 y la especificidad industrial de ISA/IEC 62443, proporciona la base pública más completa disponible para el desarrollo de programas de seguridad de OT. La cuestión ya no es si existe la guía, sino si las organizaciones invertirán para aplicarla con el rigor que exige la protección de las infraestructuras críticas.

Los adversarios no están esperando a que las organizaciones completen sus evaluaciones de marcos de trabajo. En 2024, CISA documentó más de 500 vulnerabilidades conocidas y explotadas que afectaban a componentes de ICS y OT. La brecha entre la capacidad del adversario y la preparación del defensor en entornos de OT sigue siendo uno de los desafíos de seguridad más trascendentales en la protección de infraestructuras críticas.

Siguientes pasos recomendados para los equipos de seguridad

1. Realizar un proyecto de descubrimiento pasivo de activos de OT para establecer una base de inventario completa.

2. Llevar a cabo una evaluación de riesgos específicos de OT alineada con NIST SP 800-82 Rev.3 e IEC 62443-3-2 para identificar y priorizar sus vulnerabilidades de mayor consecuencia.

3. Desarrollar o revisar su plan actual de respuesta a incidentes de OT; valide de manera específica que los procedimientos de respuesta consideren el impacto operativo e incluya simulacros teóricos de mesa.

4. Evaluar los controles de acceso remoto: elimine los túneles VPN siempre activos hacia las redes de OT, implemente MFA y configure el registro de sesiones para todo acceso de terceros.

5. Desplegar una plataforma de detección con soporte para ICS capaz de realizar monitoreo a nivel de protocolo a través de sus segmentos de red de OT.

6. Establecer o perfeccionar su programa de ciberseguridad en la cadena de suministro, enfocándose en la integridad del software de los proveedores de ICS y en la gobernanza de acceso de terceros.

Puntos clave

• NIST CSF 2.0 introduce una nueva función de Gobernanza, haciéndolo directamente aplicable a entornos de OT/ICS.

• Aplicar el marco en SCADA, PLC y RTU requiere adaptaciones específicas para el sector, no una superposición directa de la seguridad de TI.

• NIST SP 800-82 Rev.3 e ISA/IEC 62443 son los estándares complementarios que cierran la brecha entre la guía de CSF y la implementación en campo.

• Una ruta de implementación en 7 pasos ayuda a los equipos de seguridad a pasar de la aspiración a tener una resiliencia operativa medible.

En Shieldworkz, trabajamos codo a codo con empresas de servicios públicos, energía, manufactura y operadores de infraestructura crítica para convertir los requisitos de los marcos normativos en defensas probadas en campo en el mundo real.

Contáctenos hoy mismo para programar una conversación sin compromiso sobre su entorno específico de OT/ICS. Los sistemas que protege suministran energía a nuestro mundo, merecen la seguridad más sólida posible.