Lecciones aprendidas de un análisis forense del ciberataque a la red eléctrica Ucraniana

Tres compañías de distribución de energía sufrieron un ataque cibernético en el oeste de Ucrania el 23 de diciembre de 2015. Como la información forense es extensa desde un punto de vista técnico, es una oportunidad para poner ISA/IEC-62443-3-3: Seguridad para sistemas de automatización y control industrial Parte 3-3: Requisitos de seguridad del sistema y niveles de seguridad a prueba con un ejemplo de la vida real. Se utilizaron varias fuentes para este propósito que, en general, proporcionan información inusualmente detallada. Esta publicación de blog:

• Revisa la cinemática del ataque utilizando los informes disponibles y suposiciones razonables basadas en nuestra experiencia de escenarios de ciberataque y de sistemas y vulnerabilidades de tecnología operativa (OT) típica
• Presenta una metodología para evaluar el Nivel de seguridad: logrado (SL-A) por uno de los distribuidores ucranianos (correspondiente al caso mejor documentado)
• Aplica esta metodología; presenta y discute el SL-A estimado; revisa este SL-A según el requisito fundamental (FR); y deriva conclusiones y conclusiones
• Evalúa el nivel de seguridad (SL-T) que debe ser dirigido para detectar y prevenir ataques similares

Cinemática del ciberataque

Aunque el ataque en sí se desencadenó el 23 de diciembre de 2015, se planeó cuidadosamente. Las redes y los sistemas se vieron comprometidos tan pronto como ocho meses antes. Tener en cuenta este período de tiempo es esencial para una comprensión adecuada de las formas y los medios que se deben utilizar para detectar y eventualmente prevenir un ataque similar.

Nuestro análisis del ciberataque es triple:

1. Intrusión inicial de la red de tecnología de la información (TI) mediante spear phishing
2. Recopilación de inteligencia en las redes y sistemas de TI y OT utilizando el malware flexible BlackEnergy: escaneos de red, saltos de un sistema a otro, identificación de vulnerabilidades del dispositivo, diseño del ataque e instalación de más malware y puertas traseras
3. Ataque que duró 10 minutos el 23 de diciembre.

Paso 1: ¡Malware en el correo!

En la primavera de 2015, se activó una variante del malware BlackEnergy cuando un empleado de Prykarpattya Oblenergo abrió el archivo adjunto de Excel de un correo electrónico. BlackEnergy es una “suite” de malware que llegó a las noticias por primera vez en 2014, cuando se usó ampliamente para infiltrarse en los servicios públicos de energía. Su objetivo era reunir información sobre la infraestructura y las redes y ayudar a prepararse para futuros ataques cibernéticos.

El diagrama de la figura 1 es una visión simplificada de las arquitecturas de red (es decir, Internet, TI, OT) y ayudará a representar cada paso del ciberataque. El hacker se muestra como el “tipo sombrero negro” en la parte superior derecha. El hacker usó la conexión de TI de la utilidad a Internet como el canal para preparar y eventualmente desencadenar el ciberataque.

Podemos ver que la compañía tenía configurados los firewalls adecuados, uno entre la red de TI e Internet y el segundo entre la red de TI y OT (industrial). La red OT incluía un control de supervisión del sistema de gestión de distribución (DMS) y adquisición de datos con servidores y estaciones de trabajo y un conjunto de puertas de enlace utilizadas para enviar órdenes desde el DMS a unidades terminales remotas que controlaban los interruptores y otros equipos en las subestaciones eléctricas. También se conectaron dispositivos adicionales a la red (por ejemplo, estaciones de trabajo de ingeniería y servidores históricos) pero no son relevantes para la cinemática del ataque.

En este paso, el hacker logró comprometer una computadora portátil de oficina gracias al archivo adjunto de correo electrónico BlackEnergy. Esto es difícil de evitar mientras las personas abran archivos adjuntos de correos electrónicos de aspecto legítimo.

Figura 1. Diagrama simplificado de la arquitectura de uno de los sistemas de control.

Figura 2. Segundo paso del ataque a uno de los sistemas de control.

Paso 2: preparación de ataque, escaneos de red y amenaza persistente avanzada (APT)

Durante varios meses en el verano de 2015, el malware BlackEnergy se controló de forma remota para recopilar datos, saltar de un host a otro, detectar vulnerabilidades e incluso llegar a la red OT y realizar actividades similares de “reconocimiento”.

El análisis de datos forenses sobre esta fase es incompleto, porque el pirata informático realizó una limpieza y eliminó varios discos durante el ataque real. Sin embargo, el análisis previo de BlackEnergy, así como las consideraciones razonables sobre el proceso estándar utilizado para los ataques cibernéticos, hacen probable la siguiente reconstitución con una confianza razonable.

Como se muestra en la figura 2, durante el paso dos, tuvo lugar una gran cantidad de actividad de red. El malware controlado a distancia escaneó la red de TI, detectó una conexión abierta desde un sistema de TI a una plataforma de supervisión OT, realizó escaneos de red OT, recopiló información de componentes OT y finalmente instaló componentes de malware listos para disparar tanto en TI como en OT sistemas.

Esta fase duró semanas, tal vez meses, y permitió un desarrollo de exploits personalizado. Un  exploit  es un poco de software diseñado y desarrollado para explotar una vulnerabilidad específica. Está integrado como una carga útil en malware que está configurado para entregar la carga útil para su ejecución en un objetivo. En realidad, este esfuerzo fue algo limitado. La única pieza original de código de malware desarrollado fue la que se necesitaba para cancelar las puertas de enlace como parte del paso tres. Y esto realmente no fue un “esfuerzo” significativo, ya que las puertas de enlace se han señalado durante mucho tiempo como dispositivos vulnerables.

Paso 3: desencadenar el ciberataque

En la tarde, dos días antes de Navidad, como lo indicó un operador, el mouse se movió en la interfaz hombre-máquina (HMI) y comenzó a apagar los interruptores de forma remota.

Cuando el operador local intentó recuperar el control de la interfaz de supervisión, se desconectó y no pudo volver a iniciar sesión porque se había cambiado la contraseña (figura 3).

Todo el ataque solo duró un par de minutos. El hacker usó el malware preinstalado para tomar el control remoto de la HMI y apagar la mayoría de los conmutadores de las redes. Se utilizó malware adicional, en particular el exploit desarrollado a medida, para evitar que el operador recupere el control de la red al eliminar muchos discos (usando KillDisk) y sobrescribiendo el firmware de la puerta de enlace Ethernet a serie con un código aleatorio, por lo que los dispositivos se vuelven en pedazos de chatarra irrecuperables.

Las actividades adicionales de “bonificación” incluyeron la realización de un ataque de denegación de servicio distribuido en el centro de llamadas, evitando que los clientes se contacten con el distribuidor y desconectando la fuente de alimentación ininterrumpida para apagar el centro de control (figura 4).

Obviamente, este paso tenía como objetivo desconectar la alimentación de cientos de miles de suscriptores del oeste de Ucrania conectados a la red. Sin embargo, la mayor parte del esfuerzo se gastó para asegurarse de que no se volviera a conectar la alimentación: todos los malwares específicos se desarrollaron con ese objetivo. Una vez activado, la única forma en que el operador podía evitar ese problema era detener el ataque mientras se realizaba.

Pero el ataque fue demasiado rápido para permitir cualquier reacción; de hecho, en un entorno de infraestructura crítica, las acciones del operador pueden causar problemas de seguridad. Por lo tanto, solo se permiten acciones predefinidas, y los operadores deben seguir las pautas para tomar cualquier medida. En el caso de una situación operativa no prevista, no están capacitados para tomar decisiones sobre el terreno. Esta era exactamente la situación en el caso de Ucrania. Las acciones “obvias” podrían haber detenido el ataque (como tirar del cable que conecta el OT a la red de TI), pero no se puede esperar que los operadores no capacitados tomen medidas tan disruptivas por iniciativa propia en una situación estresante donde los errores son bastante posibles.

Figura 3. Tercer paso (1) del ataque a uno de los sistemas de control.

Figura 4. Tercer pago (2) del ataque a uno de los sistemas de control.

Aprendizaje

En retrospectiva, una vez que conocemos todos los detalles sobre el ciberataque, parece fácil de detectar, dadas las actividades de red bastante significativas y los niveles de actividad que tienen lugar en numerosos sistemas.

Pero en realidad es un desafío averiguar exactamente qué está sucediendo en una red, especialmente si no tiene idea de lo que es la actividad de red “normal”. Una vez que se permiten las conexiones tanto a Internet como a la red OT, es difícil detectar signos de ataques cibernéticos debido al volumen de tráfico . Se necesita un monitoreo continuo con la capacidad de identificar los pocos paquetes sospechosos en medio de todos los paquetes “buenos”. Se han realizado múltiples pruebas del concepto de dicha detección utilizando detección correlacionada de TI y OT y se presentaron en las conferencias GovWare 2016 en Singapur, los días Exera de Ciberseguridad 2016 en París y la semana SEE Cybersecurity 2016 en Rennes (Francia).

Existen otros medios, y el uso de ISA/IEC-62443-3-3 para analizar la seguridad del distribuidor ucraniano ayuda a identificar todos los controles que faltaban y que podrían haber evitado el ataque cibernético.

Metodología para estimar el SL-A

ISA/IEC-62443-3-3 enumera 51 requisitos del sistema (SR) estructurados en siete requisitos fundamentales (FR). Cada SR puede ser reforzado por una o más mejoras de requisitos (RE) que se seleccionan en función de los niveles de seguridad específicos (SL-Ts). Por lo tanto, la evaluación de los niveles de seguridad alcanzados (SL-As) se puede realizar:

• Para cada SR, verificar si se cumplen los requisitos básicos y las posibles mejoras
• Para cada FR, el SL-A es el nivel máximo alcanzado en todos los SR
• Siendo la evaluación general SL-A el nivel máximo alcanzado en todas las FR

La Tabla 1 resume el resultado de la evaluación en un FR que tiene pocos SR por el bien de la ilustración.

La matriz de la tabla 1 se extrae directamente del apéndice ISA/IEC-62443-3-3 que resume los requisitos. En cuanto al caso Prykarpattya Oblenergo y para cada requisito (básico o RE), hemos identificado tres casos posibles:

• La información disponible es suficiente para considerar el requisito cumplido: ✔
• La información disponible es suficiente para descubrir que se perdió el requisito: ✘
• No es posible evaluar si se cumplió o no el requisito  😕

Tabla 1. Resultado de la evaluación del SL-A para el FR5.

Una vez completada, la tabla 1 corresponde a la evaluación real del FR5 para el caso en cuestión (Ucrania), lo que lleva a un SL-A de 2. Esto significa que la segmentación de la red (“restringir el flujo de datos”) se implementó al menos para el básico de requisitos y para algunas mejoras de requisitos.

Aplicación al caso de Ucrania

Este análisis se realizó en todos los SR, y se identificaron dos situaciones:

• El SR puede no ser aplicable (por ejemplo, requisitos sobre comunicación inalámbrica en ausencia de dichos medios).
• Es posible que no tengamos evidencia directa de que se cumplió o se perdió el SR, pero la deducción basada en instalaciones similares típicas y otras entradas permite una especulación razonable sobre si se cumplió o no el requisito.

Por ejemplo, podemos considerar la falta de “copia de seguridad”, porque los discos no se pudieron restaurar varias semanas después del ataque. Considerando SR 5.2 RE (1), es razonable considerar que la conexión de shell seguro (SSH) a través del firewall fue una excepción y que se denegó todo el resto del tráfico. El hacker no habría pasado por la carga de capturar la contraseña si existieran formas más directas de llegar a la red OT.

De los 51 SR, cuatro se consideraron “no aplicables” (1.6, 1.8, 1.9 y 2.2), y 25 no pudieron determinarse (” ? “). Esta es una gran cantidad, lo que significa que solo la mitad de los SR en realidad podrían evaluarse . En realidad, esto favorece un SL-A más alto, porque solo se tienen en cuenta los SR evaluados, y por defecto consideramos que el SR se cumple potencialmente.

Se tomó otra decisión en términos de presentación de datos. En lugar de presentar la información con un requisito (básico y RE) por línea, como en la tabla 1, decidimos tener una línea por SR y enumerar el aumento de RE en las diversas columnas. La Tabla 2 ilustra la misma evaluación FR5 usando este modo de presentación.

Tabla 2. Estimación del SL-A (FR5).

Tabla 3. Estimación general de las siete FR.

Finalmente, se utilizó una vista más sintetizada sin el texto RE para presentar la imagen general de todos los FR, que de lo contrario abarcarían varias páginas. Los SL generales estimados se reagrupan en la tabla 3.

Los resultados representados en la tabla 3 son bastante malos. Además, la mitad de los requisitos no se pudieron evaluar y, por lo tanto, esta opinión es probablemente optimista.

En el lado derecho, los SL-As estimados se enumeran para los siete FR. Podemos ver que los SL-As son cero excepto por:

• FR5 (flujo de datos restringido): principalmente debido al firewall IT-IACS y al estricto control de flujo. Cumplir con este requisito significa que se debe filtrar el tráfico entre zonas en la red OT. El ejemplo de ataque ucraniano demuestra que este requisito podría revisarse en futuras actualizaciones del estándar:
  • Cumplir con SR 5.2 no requiere uno para definir zonas. Como en el caso ucraniano, todos los sistemas OT podrían interactuar entre sí. Tenga en cuenta que las recomendaciones sobre las definiciones de zona están disponibles en ISA/IEC-62443-3-2 que deben usarse antes de aplicar ISA/IEC-62443-3-3.
  • El requisito para el filtrado de tráfico entre zonas se establece para SL = 1. El retorno de la inversión es cuestionable, ya que el costo y el riesgo del filtrado de tráfico son altos, y la efectividad es cuestionable, como lo demuestra el caso de Ucrania. Puede tener más sentido exigir la detección tan pronto como SL-T = 1 sea el objetivo y requerir un filtrado / prevención activa para SL superiores.
• FR6 (respuesta oportuna a los eventos): la existencia misma de información forense detallada es el resultado de un registro mínimo en su lugar.

La Tabla 4 muestra un análisis detallado de algunas de las RS más significativas.

Tabla 4. Análisis específico para algunas de las RS más significativas.

Aprendizaje

Al principio, al observar los informes sobre los diversos controles de seguridad del operador ucraniano, parecía que habían prestado mucha atención a los problemas de ciberseguridad . En efecto:

• Se utilizaron contraseñas no obvias
• Un firewall con estricta restricción de flujo de datos estaba en su lugar
• Se realizó un registro significativo

Pero, como se demostró en la evaluación SL-A, la mayoría de los niveles de seguridad de FR eran nulos, porque al menos uno de los SR no se abordó en absoluto. No tiene sentido configurar controles de seguridad avanzados cuando faltan algunos básicos. El eslabón más débil reduce la efectividad general de la seguridad. El hecho de que los controles de seguridad avanzados son inútiles si faltan otros controles de seguridad básicos se ilustra mejor con la configuración del firewall con un único enlace SSH que requiere una autenticación de contraseña no obvia. Esto suele ser una limitación operativa dolorosa, ya que permitir el acceso directo del protocolo de escritorio remoto (RDP) para varios sistemas o conexiones de red virtual (VNC) hubiera sido más fácil de usar. Desafortunadamente, estas restricciones adicionales no condujeron a una mayor seguridad, porque:

• La falta de supervisión de la red de TI permitió exploraciones extensas de la red, búsquedas de vulnerabilidades y el descubrimiento del enlace SSH permitido.
• La falta de una autenticación sólida (dos factores) o aprobación local (OT) de conexiones remotas permitió conectarse con frecuencia desde la red de TI a la red OT sin detección durante varios meses.
• La falta de detección de intrusiones en la red OT permitió escaneos extensos de la red OT, detección de vulnerabilidad y restricciones de transferencia de código móvil (malware, exploits).

Al implementar controles de seguridad, es esencial aplicar los requisitos de manera consistente en todos los aspectos de la seguridad: detección, prevención y reacción. Es mejor usar un estándar bien diseñado como ISA/IEC-62443-3-3. No apunte a SL-T = 2 o 3 en algunos FR si el SL-A sigue siendo cero en otros FR, ya que esto probablemente sería inútil.

¿Qué SL habría sido necesario para prevenir el ataque?

Al observar los problemas enumerados anteriormente, parece que elevar el SL-A al nivel 2 habría permitido detectar la actividad durante el segundo paso, evitando así el ataque cibernético. Había mucho tiempo disponible para la reacción posterior a la detección. Controles adicionales, como la autenticación fuerte/local, antimalware y los requisitos de SL 2 en realidad habrían evitado la cinemática específica del ataque.

El hecho de que configurar el SL-T en el nivel 2 hubiera sido suficiente para detectar y prevenir el ataque con varias capas de defensa puede sonar sorprendente para el lector, ya que esto (sin duda) fue un ciberataque patrocinado por el estado, que normalmente requiere SL-T = 3 o incluso 4 para prevenir.

En realidad, es probable que el hacker haya podido igualar SL-A = 2 mediante el desarrollo de exploits más avanzados y el uso de vectores de ataque que no sean Internet, como medios móviles o equipos móviles introducidos por empleados deshonestos o terceros. Sin embargo, esos pasos adicionales son más complejos y costosos y, debido a que no eran necesarios, se utilizaron medios menos avanzados.

Para resumir las conclusiones de este ciberataque utilizando la guía ISA/IEC-62443-3-3:

Como primer paso obligatorio, las empresas de distribución de energía deben apuntar a SL-T = 2, asegurando que se cumplan al menos los requisitos mínimos de detección (SR 6.2).

Para tener varias capas de defensa, prevención, detección y tiempo para reacciones en anticipación de los ataques más sofisticados, es mejor apuntar a SL-T = 3.

En cualquier caso, es esencial establecer controles de seguridad de manera consistente para garantizar que todos los FR hayan alcanzado el mismo SL-A antes de apuntar a un SL-T más alto. De lo contrario, los esfuerzos son inútiles, como lo demuestra el ejemplo en cuestión.

---

Publicado en ISA Interchange: LINK