ES-ISAC Energía: Lo que cuatro casos reales nos enseñan antes de que llegue la transposición de NIS2

Una subestación en Ucrania, un oleoducto en Estados Unidos, una central nuclear en la India y veintidós entidades energéticas danesas. En esta lista no aparece ninguna instalación española, y esa es justamente la razón para leerla con atención. Detrás de cada caso hay una intrusión, un acceso indebido o una interrupción que explotó debilidades reconocibles desde cualquier sala de control.

Ni el sector energético ni la industria nuclear nacionales son ajenos a este tipo de amenazas, y muchas de las medidas necesarias para hacerles frente están a punto de convertirse en recomendación o incluso obligación con la transposición de la directiva NIS2. A ello se suma, en el ámbito eléctrico, el Reglamento Delegado (UE) 2024/1366, primer código de red europeo con normas vinculantes de ciberseguridad, y normativa específica en el ámbito nuclear que está en desarrollo por el Consejo de Seguridad Nuclear.

Revisar hoy, con la calma que da no estar en plena crisis, por dónde entraron los atacantes y qué impacto tuvieron sigue siendo la forma más económica de aprender la lección. 

Apertura remota de interruptores desde el propio HMI

Tres distribuidoras eléctricas ucranianas sufrieron cortes provocados mediante el acceso a sus sistemas de control. Los atacantes entraron con credenciales legítimas de acceso remoto y utilizaron las propias interfaces HMI para enviar órdenes de apertura de interruptores.

• Debilidades: acceso remoto a la red de operación mediante credenciales robadas y sin doble factor.
• Impacto: alrededor de 225.000 clientes sin suministro durante varias horas. Los atacantes borraron estaciones de trabajo y sustituyeron el firmware de los conversores serie-ethernet para dificultar la reposición, y saturaron el centro de atención telefónica para retrasar el aviso de los clientes. Las operaciones se recuperaron mediante el control manual de las subestaciones.

Una cuenta de VPN olvidada detiene un oleoducto

Colonial Pipeline, uno de los mayores sistemas de transporte de productos refinados de Estados Unidos, interrumpió su operación durante varios días tras sufrir un ataque de ransomware. El acceso inicial se produjo mediante una cuenta de VPN que ya no estaba en uso, pero que seguía activa y no requería autenticación multifactor. La contraseña asociada había aparecido previamente en una filtración de credenciales.

• Debilidades: una cuenta de acceso remoto heredada que no había sido desactivada, sin autenticación multifactor, y el uso de una contraseña que había sido comprometida previamente. A ello se sumó la dependencia de sistemas corporativos afectados por el ataque para determinadas funciones necesarias para la gestión de la operación.
• Impacto: la compañía detuvo el oleoducto de forma preventiva ante la imposibilidad de garantizar la operación comercial, con desabastecimiento de combustible en varios estados. Aunque no afectó directamente a los sistemas de control, la parada se produjo igualmente.

Malware en la red administrativa de una central nuclear

La central nuclear de Kudankulam, en la India, encontró malware en un equipo de su red administrativa. La detección no fue interna: llegó a través de un aviso del CERT nacional a partir de información de terceros.

• Debilidades: existencia de un equipo de la red administrativa con conexión a Internet. La identificación inicial del malware fue comunicada por CERT-In, lo que evidencia que la detección no se produjo inicialmente dentro de la organización.
• Impacto: según la operadora, los sistemas de instrumentación y control no se vieron afectados por estar aislados de la red administrativa. El aislamiento previo hizo su trabajo, pero la organización tuvo que gestionar la intrusión y desmentir públicamente versiones más alarmistas mientras investigaba.

Veintidós empresas de la infraestructura energética danesa comprometidas durante una campaña coordinada

El CERT sectorial danés documentó el que pudiera ser uno de los mayores ciberataques coordinados sufridos por la infraestructura crítica del país. En dos oleadas, los atacantes explotaron vulnerabilidades en cortafuegos de un mismo fabricante, muy extendidos entre las entidades del sector.

• Debilidades: dispositivos perimetrales con una vulnerabilidad crítica ya publicada y sin parchear en la primera oleada y, en la segunda, dos vulnerabilidades de día cero. El hecho de que buena parte del sector empleara el mismo modelo convirtió un fallo de producto en un riesgo sectorial.
• Impacto: varias entidades atacadas fueron comprometidas de forma inmediata. La simultaneidad impidió que pudieran avisarse entre ellas, y fue la monitorización conjunta del CERT sectorial la que permitió correlacionar los eventos y contener la campaña.

Top 5 recomendaciones

De estos cuatro escenarios se extraen debilidades muy concretas, y casi todas se podrían situar en la frontera entre IT y OT. Las hemos traducido en cinco medidas y a continuación, las hemos vinculado al articulado de NIS2, de manera que se vea a la vez qué conviene priorizar y con qué recomendación u obligación se corresponde.

• Exige doble factor en todo acceso remoto a la red de operación y controla el ciclo de vida de las cuentas. Ninguna cuenta debería sobrevivir al proyecto o al proveedor que la justificó. NIS2 lo recoge de forma literal en el art. 21.2.j, que cita el uso de soluciones de autenticación de múltiples factores o de autenticación continua entre las medidas mínimas exigidas, cuando proceda. La letra i) del mismo artículo cubre el control de acceso y la gestión de activos.
• Trata el cortafuegos y el concentrador de VPN como activos críticos: inventario actualizado, parcheo prioritario y seguimiento activo de los avisos del fabricante. El art. 21.2.e exige gestión y divulgación de vulnerabilidades, y el art. 21.2.d, la seguridad de la cadena de suministro, que incluye la relación con los proveedores de estos equipos.
• Separa la red administrativa de la de operación e instrumentación y control, y verifica los flujos reales, no los que figuran en el diagrama de arquitectura. Aquí aplican el art. 21.2.a, sobre políticas de análisis de riesgos y seguridad de los sistemas de información, y el art. 21.2.i, sobre gestión de activos. En el ámbito nuclear, esta separación es además el objeto de la norma IEC 62645 y de los requisitos del Consejo de Seguridad Nuclear.
• Ensaya la operación en modo manual y la continuidad sin sistemas corporativos. En alguno de los casos analizados, la capacidad de operar sin IT fue lo que marcó la diferencia entre una interrupción de horas y una de días. El art. 21.2.c exige continuidad de la actividad: copias de seguridad, recuperación en caso de catástrofe y gestión de crisis.
• Decide antes a quién llamas y en qué plazo. La notificación y la compartición con el sector no se improvisan. El art. 23 obliga a una alerta temprana en 24 horas, una notificación en 72 horas y un informe final en el plazo de un mes. En el sector eléctrico, el Reglamento Delegado (UE) 2024/1366 añade sus propias obligaciones de información, y en el ámbito nuclear la Instrucción IS-43 del CSN regula la notificación de sucesos de seguridad física y ciberseguridad.

Conclusiones

Hay algo que se repite en los cuatro casos y que debería preocupar a cualquier organización: el ataque no entró por una vulnerabilidad extraordinaria, sino por un acceso que nadie consideró suficientemente importante como para protegerlo. Una cuenta que sobrevivió a quien la creó. Un cortafuegos con un parche pendiente. Un equipo de oficina expuesto directamente a internet.

El problema no siempre está en lo sofisticado del ataque. A veces está en lo cotidiano de la puerta que dejamos abierta.

La diferencia entre contener y encadenar días de parada no tiene por qué radicar siempre en cuánto se invertía en ciberseguridad, sino en qué decisiones se habían tomado tiempo atrás. 

La pregunta que de verdad importa no es si una instalación española protagonizará el próximo caso de esta lista, sino si, cuando llegue ese día, la respuesta estará ya escrita o habrá que improvisarla.

Ninguna de las cinco medidas anteriores es una interpretación propia. Todas figuran, con este o parecido nombre, en el articulado de NIS2, que vincula a las entidades esenciales e importantes y alcanza a buena parte del sector energético. En España, el texto llamado a incorporarlo al ordenamiento es el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, está todavía en tramitación.

Nada de esto, sin embargo, obliga a esperar. Quien empiece hoy por esta lista reduce desde el primer día la probabilidad de repetir alguno de los cuatro escenarios y, cuando la norma llegue, partirá de una posición mucho más avanzada para cumplirla.

Referencias utilizadas en la elaboración de este contenido

• CISA (Cyber-Attack Against Ukrainian Critical Infrastructure)
• CISA (Strengthening the Cybersecurity of Federal Networks”, Electricity Subsector Report)
• SANS y E-ISAC (Analysis of the Cyber Attack on the Ukrainian Power Grid) 
• DOE / FBI / CISA (Colonial Pipeline Cyber Incident)
• CISA (DarkSide Ransomware: Best Practices for Preventing Business Disruption)
• Government Technology (Bad Password Gave Colonial Pipeline Hackers Access)
• Congress.gov (The evolving cybersecurity landscape) 
• Department of Atomic Energy / Gobierno de India (Respuesta parlamentaria sobre el ataque a Kudankulam)
• Department of Atomic Energy / Press Information Bureau Government of India (Malware in NPCIL system isolated, critical plant systems not affected)
• Department of Atomic Energy / Press Information Bureau Government of India (Cyber attack on KKNPP)
• Dragos (Assessment of Reported Malware Infection at Nuclear Facility)
• SektorCERT (The attack against Danish critical infrastructure)
• NIS2 (Directiva UE 2022/2555)
• Reglamento Delegado (UE) 2024/1366 (código de red de ciberseguridad para los flujos transfronterizos de electricidad)