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

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ó apenas unos minutos. Las consecuencias, si un operador no hubiera notado el cursor moviéndose en su pantalla, pudieron haber afectado a más de 15,000 residentes. El vector de ataque fue una herramienta heredada de acceso remoto. El sistema de control industrial no tenía segmentación de red ni monitoreo específico para OT.

Antes de continuar, no olvides revisar nuestra última publicación del blog sobre la decodificación de la más reciente alerta de CISA sobre Zero Trust para Tecnología Operativa aquí.

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

Este es el entorno en el que debe entenderse el marco de ciberseguridad de NIST para OT. No como una casilla de cumplimiento, sino como una base estructural para organizaciones cuyos sistemas, si se interrumpen, 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 NIST amplió explícitamente el alcance del marco más allá de la infraestructura crítica para incluir a todas las organizaciones, al tiempo que introdujo la gobernanza como una función de primer nivel. Para los profesionales de seguridad OT, este cambio es trascendental.

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

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

El modo de falla más común cuando las organizaciones aplican un marco de ciberseguridad a entornos OT es asumir que los principios de seguridad 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 falsifica datos de sensores es mucho más peligroso que una hoja de cálculo exfiltrada.

Los sistemas SCADA que administran líneas de transmisión de alto voltaje, los Sistemas de Control Distribuido (DCS) en plantas de procesamiento químico y los PLC en líneas de ensamblaje automotriz operan con protocolos de comunicación en tiempo real —DNP3, Modbus, PROFINET, EtherNet/IP— que anteceden al pensamiento moderno de ciberseguridad. Muchos de estos sistemas no pueden tolerar la latencia introducida por dispositivos de seguridad en línea. Algunos no pueden ser parchados. Las actualizaciones de firmware en sistemas instrumentados de seguridad (SIS) pueden requerir apagados completos del proceso que duran días.

Por lo tanto, aplicar NIST CSF a la seguridad de ICS y SCADA 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é importa para OT

La actualización de 2024 del 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 OT ya entendían de forma intuitiva: la seguridad sostenible requiere compromiso organizacional, no solo controles técnicos.

NIST CSF 2.0 también introdujo perfiles de implementación por niveles más adecuados a las restricciones 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 OT no puede abordarse con un solo documento generalista.

Las seis funciones principales del CSF aplicadas a entornos industriales

1. Gobernar (GV): construir 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 OT/ICS, esto significa formalizar la intersección entre el riesgo operacional 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 suelen hablar distintos lenguajes de riesgo.

La implementación práctica aquí implica crear una Política de Ciberseguridad OT que contemple explícitamente los requisitos de disponibilidad de procesos, definir la propiedad de los activos OT (a menudo dividida entre TI, ingeniería OT y operaciones de planta) y establecer una estrategia de gestión de riesgos alineada con marcos regulatorios relevantes como NERC CIP para empresas eléctricas, IEC 62443 para automatización industrial o las Directivas de Seguridad de TSA para operadores de ductos.

• 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 interrupciones operativas, no solo para escenarios de filtración de datos.

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

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

No puedes proteger lo que no puedes ver. En entornos OT, el inventario de activos es notoriamente difícil. A diferencia de los entornos TI, donde Active Directory ofrece un punto de partida, las redes OT suelen contener activos que nunca han sido documentados 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 OT. De forma crítica, este inventario debe capturar patrones de comunicación: qué habla con qué, usando qué protocolo y en qué segmento de red.

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

Una importante empresa eléctrica de Norteamérica descubrió más de 2,400 activos OT previamente no registrados durante su primer ejercicio de descubrimiento pasivo de red. La mayoría estaban en la red de tecnología operativa, pero nunca habían aparecido en ninguna entrada de la CMDB.

3. Proteger (PR): implementar defensas en capas

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

La segmentación de red sigue siendo el control protector de mayor valor en entornos industriales. Una implementación adecuada significa zonas DMZ entre las redes TI y OT, filtrado estricto de tráfico en cada límite de nivel Purdue y firewalls conscientes del protocolo que inspeccionen protocolos industriales en lugar de simplemente permitirlos con base en los números de puerto.

El acceso remoto se ha convertido en un vector de ataque crítico. Proveedores de ingeniería, integradores y servicios de monitoreo remoto requieren conectividad a los sistemas OT. La mejor práctica exige jump servers dedicados en DMZ OT, MFA para todas las sesiones de acceso remoto, grabación de sesiones y aprovisionamiento de acceso justo a tiempo, eliminando túneles VPN siempre activos hacia las redes operativas.

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

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

• Aplicar MFA a todas las rutas de acceso privilegiado y remoto hacia las redes OT.

• Realizar capacitación periódica de concientización en seguridad adaptada a operadores OT, no simulaciones genéricas de phishing.

4. Detectar (DE): reconocer amenazas en el contexto específico de OT

La detección en entornos OT requiere un enfoque fundamentalmente distinto al monitoreo de seguridad 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 más peligrosos específicos de ICS: reprogramación no autorizada de PLC, cambios inesperados en puntos de ajuste de proceso, comunicación anómala entre componentes que no deberían comunicarse.

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

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

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

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

La respuesta a incidentes en entornos OT conlleva restricciones 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 potencialmente desencadenar una condición peligrosa. Los procedimientos de respuesta deben desarrollarse en estrecha colaboración con los equipos de operaciones e ingeniería de seguridad, y deben considerar el impacto operacional de cada acción de respuesta.

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

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

6. Recuperar (RC): restablecer las operaciones de forma segura

La función Recuperar se centra en mantener la resiliencia y restablecer capacidades después de un incidente. Para entornos OT, la planificación de 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 comprometa.

Las copias de respaldo seguras y fuera de línea de la lógica PLC, la configuración de HMI, los datos del historiador y las configuraciones de dispositivos de red son activos fundamentales de recuperación. Estas copias de respaldo 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 actuales del hardware.

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

Hoja de ruta de implementación de 7 pasos para equipos de seguridad OT

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

Paso 1: priorizar y delimitar sistemas OT críticos

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

La delimitación debe alinearse con las definiciones de zona de ISA/IEC 62443. Definir qué sistemas constituyen la Zona 0 (dispositivos de campo), la Zona 1 (control básico), la Zona 2 (control supervisado) y la Zona 3 (operaciones de manufactura), y establecer qué zonas están dentro del alcance inmediato del programa de seguridad versus fases posteriores.

Paso 2: entender los sistemas y los requisitos de cumplimiento

Comprender el panorama de amenazas para tu sector específico es esencial. Una estación de compresión de gas natural enfrenta perfiles de actores de amenaza distintos a los de una planta de manufactura automotriz. Las alertas ICS-CERT de CISA, los ISAC específicos del sector (E-ISAC para electricidad, WaterISAC para servicios de agua, A-ISAC para aviación) y el reporte anual Year in Review de Dragos proporcionan inteligencia de amenazas específica del sector que debe informar tus requisitos de seguridad.

ISA/IEC 62443 define Niveles de Seguridad (SL 1-4) que describen la resistencia frente a capacidades crecientes del adversario, desde atacantes ocasionales hasta actores patrocinados por Estados con conocimiento interno. Establecer qué SL deben alcanzar tus sistemas críticos es un requisito fundamental de este paso.

Paso 3: crear el perfil actual de ciberseguridad

Un perfil actual es una instantánea de la implementación vigente de las categorías y subcategorías del CSF por parte de la organización. En entornos OT, esta evaluación debe realizarse con contexto específico de OT, no simplemente importarse desde una evaluación de seguridad 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 son operativamente poco prácticos.

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

Paso 4: realizar la evaluación de riesgos OT

La metodología de evaluación de riesgos OT debe incorporar un análisis de consecuencias que refleje la realidad operacional. Un modelo de riesgo que trate todas las intrusiones a sistemas de control como equivalentes pasa por alto la distinción crítica entre, por ejemplo, el acceso no autorizado a un servidor historiador y el acceso no autorizado a un PLC de seguridad que administra lógica de gestión de quemadores.

La metodología Consequence-Driven Cyber-Informed Engineering (CCE) de CISA proporciona un excelente marco para el análisis de consecuencias en infraestructura crítica. 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 riesgo 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 reconocer honestamente las restricciones operativas. En entornos donde parchear el firmware de un PLC específico requiere una parada planificada de 72 horas, los equipos de seguridad deben construir controles compensatorios —monitoreo de red, control estricto de acceso, listas blancas de aplicaciones 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 hoja de ruta priorizada de remediación. La priorización debe ponderar fuertemente el potencial de reducción de riesgo: una mejora de segmentación de red de bajo costo que elimina una vía de ataque de alta severidad aporta más valor de seguridad que una costosa implementación de seguridad de endpoint en sistemas con baja exposición.

Mejores prácticas de ciberseguridad industrial por sector

Servicios eléctricos: alineación entre NERC CIP y CSF

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

NERC CIP-007 (Gestión de Seguridad de Sistemas), CIP-010 (Gestión de Cambios de Configuración) y CIP-013 (Gestión de Riesgo de la Cadena de Suministro) se alinean directamente con las funciones Proteger e Identificar del CSF. Sin embargo, NERC CIP tradicionalmente ha sido binario: o cumples con el estándar o no. El modelo de madurez por niveles del CSF ayuda a las empresas eléctricas a entender su postura de seguridad en un continuo, en lugar de verla simplemente como un estado de cumplimiento.

Petróleo y gas: proteger operaciones de campo distribuidas

Las operaciones de petróleo y gas presentan retos únicos: activos distribuidos geográficamente, dependencia extensa de RTU heredadas en estaciones remotas de monitoreo de ductos, comunicaciones satelitales y celulares con ancho de banda limitado para herramientas de seguridad, y relaciones complejas 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 TSA de 2021 y 2022 para operadores de ductos exigieron medidas específicas de ciberseguridad 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 TI/OT. Las organizaciones cubiertas por estas directivas encuentran que los programas alineados con el CSF proporcionan una estructura práctica para cumplir con los requisitos de las directivas mientras construyen una postura de seguridad sostenible a largo plazo.

Agua y aguas residuales: seguridad OT con recursos limitados

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

El incidente de Oldsmar resaltó una vulnerabilidad recurrente en el sector: acceso remoto mediante herramientas de nivel consumidor (TeamViewer en ese caso), credenciales compartidas y sin segmentación de red OT. La implementación de la función Proteger del CSF, específicamente control de acceso (PR.AC) y tecnología protectora (PR.PT), aborda estas brechas más críticas incluso dentro de restricciones severas de recursos.

Manufactura: expansión IIoT y superficie de ataque en evolución

Las iniciativas de manufactura inteligente —gemelos digitales, redes de sensores IIoT, plataformas de mantenimiento predictivo— están ampliando la superficie de ataque OT más rápido de lo que los programas de seguridad pueden adaptarse. Cada nuevo dispositivo conectado es un posible punto de entrada, y los entornos de manufactura a menudo carecen de procesos maduros de gestión de cambios que sometan las nuevas conexiones OT a revisión de seguridad.

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

Errores comunes de implementación y cómo evitarlos

Construyendo un programa sostenible de seguridad OT

El Marco de Ciberseguridad de NIST, aplicado con disciplina específica para OT, proporciona a las organizaciones industriales una ruta estructurada desde medidas reactivas y fragmentadas hacia una postura de seguridad proactiva y administrada por riesgos. La fortaleza del marco no radica en su nivel de prescripción, sino en su flexibilidad: se adapta a la enorme diversidad de entornos de sistemas de control industrial, desde subestaciones de alto voltaje hasta sistemas de procesamiento por lotes farmacéuticos y plataformas petroleras marinas.

Las organizaciones que implementan con éxito programas de seguridad OT alineados con el CSF comparten varias características: tratan la seguridad como una disciplina operacional, no como una función de TI agregada a los sistemas de ingeniería; invierten en experiencia específica de OT, ya sea internamente o mediante socios especializados; y construyen programas que pueden demostrar una reducción medible del riesgo, en lugar de limitarse a la preparación para auditorías.

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 desarrollar un programa de seguridad OT. La pregunta ya no es si la guía existe, sino si las organizaciones invertirán en aplicarla con el rigor que exige la protección de infraestructura crítica.

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

Próximos pasos recomendados para los equipos de seguridad

1. Realizar un descubrimiento pasivo de activos OT para establecer una línea base completa del inventario.

2. Realizar una evaluación de riesgos específica para OT alineada con NIST SP 800-82 Rev.3 e IEC 62443-3-2 para identificar y priorizar tus vulnerabilidades de mayor consecuencia.

3. Desarrollar o revisar tu plan actual de respuesta a incidentes OT: valida específicamente que los procedimientos de respuesta consideren el impacto operacional e incluyan ejercicios de mesa.

4. Evaluar los controles de acceso remoto: elimina túneles VPN siempre activos hacia redes OT, implementa MFA y despliega grabación de sesiones para todo acceso de terceros.

5. Desplegar una plataforma de detección consciente de ICS capaz de monitoreo a nivel de protocolo en todos los segmentos de tu red OT.

6. Establecer o madurar tu programa de ciberseguridad de cadena de suministro, enfocándote en la integridad del software de proveedores ICS y en la gobernanza del acceso de terceros.

Conclusiones clave

• NIST CSF 2.0 introduce una nueva función Gobernar, lo que lo hace directamente aplicable a entornos OT/ICS.

• Aplicar el marco a SCADA, PLC y RTU requiere adaptación específica por sector, no una superposición directa de seguridad TI.

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

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

En Shieldworkz, trabajamos codo a codo con operadores de servicios públicos, energía, manufactura e infraestructura crítica para convertir los requisitos del marco en defensas reales y probadas en campo.

Contáctanos hoy para programar una conversación sin presión sobre tu entorno específico OT/ICS. Los sistemas que proteges impulsan nuestro mundo; merecen la máxima seguridad posible.