El enfoque tradicional de la mayoría de los hackers ha sido el software, pero el foco histórico del crimen está en cualquier cosa de valor. Por lo tanto, no debería sorprendernos que a medida que la tecnología operativa (OT) y la infraestructura del sistema de control industrial (ICS) se hayan convertido en componentes mucho más prominentes de la infraestructura crítica nacional, la actividad de piratería maliciosa se oriente cada vez más en esta dirección.

También es lógico pensar que los aspectos más destacados de la piratería informática, es decir, el acceso remoto, las herramientas automatizadas y la atribución débil, se extenderían de forma natural a la identificación malintencionada de la infraestructura crítica de OT / ICS. Estos atributos son particularmente atractivos en este contexto, porque los delincuentes interesados ​​en perturbar las fábricas, los sistemas de producción y otras infraestructuras tangibles, previamente tenían que establecer presencia física o comprometer a algún grupo con acceso local.

El nuevo enfoque para la piratería de OT / ICS implica una combinación de técnicas tradicionales con experiencia en el dominio de los sistemas a los que se apunta, aunque es posible que se requiera poca experiencia para desencadenar daños en un sistema ICS / OT. El problema más importante aquí es la capacidad de los atacantes para atacar sistemas tangibles, como plantas de energía y refinerías, sin tener que intervenir en las instalaciones locales. Esta es una desviación importante de las normas históricas.

Es instructivo revisar los detalles de algunos ataques anteriores de OT / ICS con énfasis en cómo los actores maliciosos adaptaron los métodos de piratería conocidos con los detalles del sistema ICS específico. En las siguientes secciones, examinamos dos de los hacks de ejemplos más conocidos que se han producido en los últimos años: el gusano Stuxnet de 2010 y el ataque de poder de Ucrania de 2015.

Ataque de Stuxnet

Stuxnet consistía en la funcionalidad del gusano que opera en las capas superiores del Modelo Purdue, que fue diseñado para localizar y atacar los recursos OT en las capas inferiores. Específicamente, el gusano se propagó desconociendo a los humanos con memorias USB infectadas con malware que se transportaban y usaban en sitios de infraestructura crítica. Una vez residente en una computadora con Windows, el gusano buscó la presencia del software del sistema de control de Siemens utilizado para controlar dispositivos electromecánicos.

Si la búsqueda de Stuxnet en una máquina de Windows determinada encuentra el software de control deseado de Siemens, el juego de herramientas se propagaría a través de todas las computadoras en el sistema de control de Siemens, a través de cortafuegos y redes IP. Cuando el malware de Stuxnet encontró las computadoras responsables, se descargó un potente rootkit en lo que se conoce como un controlador lógico programable (PLC), como se encuentra en la Capa 1 del Modelo de Purdue. Los PLC controlan muchos tipos de sistemas físicos.

Si bien quedan muchas dudas sobre el origen del ataque, la comunidad de seguridad generalmente acepta que Stuxnet fue desarrollado para centrar las centrífugas de gas en las instalaciones de enriquecimiento de uranio de Irán. La opinión consensuada es que el gusano usó su carga útil de rootkit para enviar comandos destructivos especiales a la infraestructura de enriquecimiento de Irán como una alternativa a las formas convencionales de ataque. El ataque forzó cambios en la velocidad del rotor de las centrífugas de gas para causar daños permanentes a estos dispositivos, todo hecho a distancia.

los hackers explotan la infraestructura crítica

Progresión del ataque Stuxnet

Comprender cómo se pudo haber prevenido Stuxnet ofrece consejos útiles sobre la seguridad OT / ICS. En primer lugar, uno probablemente señalaría con el dedo el software de Microsoft y Siemens, que proporcionaron un entorno amigable para el gusano USB. Cuatro vulnerabilidades de día cero en Microsoft Windows, por ejemplo, se usaron para infectar sistemas de destino. Por lo tanto, es razonable reconocer el impacto de las vulnerabilidades de la plataforma como causa raíz en los ataques OT / ICS presentes y futuros. Este no es un problema que siempre desaparecerá: todo el software tiene defectos, y algunos de esos defectos son vulnerabilidades conocidas y desconocidas.

En segundo lugar, uno reconocería la facilidad con la que el gusano podía propagarse desde niveles superiores de la arquitectura a niveles más bajos. Esto sugiere que las interfaces OT / TI requieren al menos los mismos niveles de protección de puerta de enlace que se encuentran en una puerta de enlace empresarial típica. Esto implica que las capas inferiores del Modelo Purdue no deberían confiar implícitamente en el software que opera en los niveles superiores.

Esto es más fácil decirlo que hacerlo, pero es el camino, porque el gusano demostró la capacidad funcional para saltar automáticamente a través de firewalls a través de conexiones cifradas y autenticadas. La imposición de nuevos requisitos de seguridad cibernética, como la autenticación de dos factores entre los procesos que se comunican a través de la interfaz OT / IT, habría hecho poco para frenar a Stuxnet.

Corte de poder ucraniano

En diciembre de 2015, los piratas informáticos pusieron en peligro la distribución de energía eléctrica a los ciudadanos de Ucrania. Tres empresas de energía, todas con nombres demasiado largos para repetir aquí, fueron atacadas y el resultado final es aterrador: casi un cuarto de millón de personas no tenían electricidad durante varias horas. El origen y la motivación del ataque se han debatido, pero parecerían menos relevantes que la cuestión de cómo evitar que ocurra algo así en el futuro.

El análisis del ataque revela el uso de una multitud de diferentes métodos de ciberataque SCADA, incluidos los siguientes componentes:

  • Trojan Malware : se identificó malware avanzado ejecutable de Windows llamado BlackEnergy, pero no estuvo implicado en la interrupción. En cambio, los métodos de control remoto de hacktivista estándar se usaron muy probablemente.
  • Spear Phishing : los atacantes usaron correo electrónico spear phishing con identidad de remitente falso (Parlamento ucraniano) y archivos adjuntos maliciosos.
  • Control remoto : el ataque provocó el funcionamiento a distancia de los equipos y sistemas de la subestación de la compañía eléctrica.
  • Acción destructiva : la utilidad KillDisk entregada como parte del ataque destruyó archivos en servidores y dispositivos de la subestación.
  • Denegación de servicio : los centros de soporte al cliente de la compañía eléctrica sufrieron ataques de DDOS para degradar su capacidad de brindar servicio a los clientes afectados.

Este ataque coordinado sugiere que la interfaz IT / OT para estas compañías eléctricas ucranianas estaba en gran parte desprotegida. Cada uno de los componentes del ataque es bien conocido por la comunidad de ciberdefensa, y si bien ningún riesgo de ataque cibernético puede reducirse a cero en ningún caso, las protecciones aquí parecían demasiado ineficaces para los usuarios y sistemas en un entorno de red eléctrica.

Tal vez la mejor lección del ataque de Ucrania es que los proveedores de infraestructura crítica deben desarrollar y mantener estándares de ciberseguridad más elevados que los proveedores de sistemas y servicios más mundanos. La idea de que una colección tan extensa de ataques se haya podido involucrar con éxito con estas compañías debería sonar alarmante en todo el segmento de la industria, y esto incluye a las compañías eléctricas de países más grandes como Estados Unidos.

Una noción básica que tales compañías podrían considerar involucra enclaves de separación alrededor de la subestación eléctrica o funciones relacionadas. Esto podría lograrse mejor usando infraestructuras de comunicaciones físicas separadas. Estos enclaves físicos separados también se beneficiarían de las potentes soluciones de puerta de enlace que implementan el flujo de comunicaciones unidireccionales. Esto garantizaría que los ataques a la parte de TI de una compañía de energía no cayeran en cascada a las subestaciones de OT.

los hackers explotan la infraestructura crítica

Protección de subestación IT / OT utilizando tecnología avanzada de separación

Independientemente de los tipos específicos de tecnologías de seguridad cibernética utilizadas, la idea de que las subestaciones puedan separarse en dominios físicamente discretos en toda la infraestructura de la compañía provee una poderosa protección contra los tipos de ataques en cascada comúnmente encontrados en ataques avanzados, especialmente de los actores del estado-nación.

Lecciones para la seguridad OT / ICS

Los diseñadores y operadores de infraestructura OT / ICS deben reconocer que incidentes como el gusano Stuxnet y el ataque de la compañía ucraniana Power Company ofrecen indicios claros sobre las mejores soluciones de seguridad para el sector. En primer lugar, debe quedar claro que los ataques cibernéticos estándar basados ​​en TI pueden lanzarse y se lanzarán en sus sistemas OT. Esto sugiere que existirá un rol para los proveedores de seguridad tradicionales que pueden adaptar sus enfoques al trabajo a través de las interfaces OT / TI.

En segundo lugar, deben reconocer que las vulnerabilidades explotables de ICS siempre existirán en la infraestructura de OT, y que el malware se está diseñando para abordar específicamente estas debilidades. Ya no es una solución de seguridad aceptable simplemente suponer que debido a las diferencias de tecnología que pueden existir entre los sistemas basados ​​en TI y OT, esos ataques cibernéticos no cruzarán el límite. La evidencia reciente sugiere claramente lo contrario.

Finalmente, estos ataques recientes sugieren que esta supuesta brecha tecnológica entre los sistemas de TI y AT ciertamente se está reduciendo. La idea de que el malware pueda buscar, encontrar y destruir las capacidades de SCADA en un gusano lanzado usando ingeniería social de TI convencional (por ejemplo, colocar tarjetas de memoria en estacionamientos) debería crear perspectivas escalofriantes para los ingenieros de seguridad de OT / ICS. Esperemos que la comunidad preste atención y tome medidas protectoras de inmediato.

Fuente: Helpnetsecurity.com

Compartir