Periodo
1-JUN-2021 a 31-DIC-2023
Detección de ciberamenazas en los sistemas de monitorización y control de instalaciones de generación renovables (RENSHIELD)
Referencia
PI-2132/22/2021
Organismos / empresas
Ministerio de Ciencia y Tecnología (CIEN) / Junta de Andalucía (CTA) / AICIA
Isotrol
Investigadores
- Vicente Mayor
- Agustín Lara
Resumen
La colaboración entre el Grupo de investigación e ISOTROL se enmarca dentro del proyecto “RENSHIELD – Detección de ciberamenazas en los sistemas de monitorización y control de instalaciones de Generación Renovables”, cuyo objetivo es ofrecer métodos y sistemas para que Isotrol aumente su capacidad de detección de eventos de seguridad en sus sistemas de monitorización para plantas de energía renovable. Se propone el diseño e implementación de una solución de ciberseguridad software con capacidad de detección de ataques y vulnerabilidades que presente un comportamiento pasivo (i.e., no genere tráfico) y pueda ser adaptable y escalable. No obstante, la capacidad de detección y las técnicas utilizadas finalmente dependerán de los condicionantes de cada cliente e instalación. Como principios generales de diseño se consideran restricciones de capacidad de transporte de datos en el canal de comunicaciones y limitaciones en la capacidad de cómputo (CPU) para los agentes de seguridad desplegados.
Antecedentes
En colaboraciones previas con ISOTROL (proyecto Red Eléctrica Cibersegura) se abordó la protección, desde el punto de vista de la ciberseguridad, de la infraestructura desplegada para la operación y supervisión de las plantas de energías renovables de su responsabilidad. Las redes desplegadas se basan en el uso de sistemas SCADA en planta sobre la que se despliegan los diferentes equipos de campo y que son operadas remotamente a través de una red privada. El desarrollo de este proyecto previo se centró fundamentalmente en dos aspectos:
– el análisis de riesgos y vulnerabilidades de las redes y equipos,
– la protección de la infraestructura de red mediante soluciones basadas en el uso de cortafuegos y la monitorización de las interacciones entre equipos en planta y externos a partir del análisis de flujos.
La solución desarrollada debía ser de bajo coste computacional y nulo impacto en la operación de las plantas, para lo que se consideró el uso de dispositivos tipo mini-pc operando sobre un switch con capacidades de mirroring.
Una vez desplegada y evaluada la solución, se identificaron varias líneas de mejora relacionadas con la incorporación de sistemas de detección de intrusiones, que son las abordadas en este proyecto.
Objetivos
El objetivo principal del presente proyecto es el desarrollo de un sistema de detección de intrusiones (IDS) aplicable a las redes SCADA desplegadas en las plantas de energía renovable y que pueda ser adaptado a las características específicas de cada una de dichas plantas. En este sentido, el IDS debe poder ser entrenado y particularizado para su uso en función del tipo de elementos desplegados en cada caso concreto, tanto a nivel software como hardware, así como adaptarse a los patrones de operación y parámetros de las diferentes plantas.
La detección de ataques debe realizarse de forma no intrusiva (pasiva), primándose frente a otros criterios la no interferencia en la operación de la red de control monitorizada. Asimismo, debe identificar ataques tanto a nivel de protocolos y comunicaciones como de los parámetros de monitorización/operación de la planta. De esta forma, se deben poder detectar ataques como la inyección de datos falsos, comandos inadecuados, interrupción de flujos de datos de sensores, etc. Por lo tanto, en cierta forma, el sistema debe tener capacidad de diagnóstico de fallos, ya que en algunos escenarios estos serían indistinguibles de un ataque.
Por otra parte, el despliegue del IDS debe poder realizarse de forma automatizada, por lo que se precisan capacidades de autoconfiguración y debe poder entrenarse sin más intervención que la validación de los posibles ataques detectados por parte de un operador.
Propuesta
Uno de los problemas determinantes a abordar es el entrenamiento automatizado del sistema en el escenario final real. Para ello se propone que el IDS active un periodo de aprendizaje (cuya duración sea configurable) tras su despliegue inicial. El objetivo de este periodo es que el sistema forme una base de datos de los activos descubiertos, a través del tráfico que generen en las LAN monitorizadas. Cada activo se puede caracterizar por ciertos atributos invariantes (p.ej., dirección IP, dirección física, Sistema Operativo) y también por sus comunicaciones (p.ej., servicios que ofrece, servicios que consume, tráfico medio que genera, etc.). Para aquellos activos que son de tipo ICS (p.ej., SCADA o esclavos), además se guarda cierta información sobre sus comunicaciones mediante el protocolo modbus. Por ejemplo, si son de tipo SCADA, se guardan los comandos enviados a cada esclavo, valores máximos y mínimos de las variables enviadas, así como la periodicidad máxima y mínima en cada comunicación. Al finalizar el periodo de aprendizaje, el sistema genera un informe (Fig. 1) sobre los activos observados. Este informe debería ser validado por el operador de la planta (figura inferior), ya que permite observar vulnerabilidades de configuración en la red monitorizada y/o patrones de comportamiento no permitidos.
Una vez validada la base de datos de activos, esta representará un modelo de normalidad. A continuación, el IDS operará en modo detección de anomalías a partir del modelo establecido. Para ello, se propone el uso de dos módulos de observación (Fig. 2) que operan en paralelo:
– Un módulo que detecte múltiples indicadores de compromiso (IoC) relativos a los flujos de tráfico IP observados en la red. Estos indicadores de compromiso pueden ser relacionados con ataques de tipo DoS, DDoS, scanning de equipos, scanning de puertos, o Man-in-the-middle. Este módulo es una evolución del desarrollado en proyectos previos.
– Un módulo que detecte varios IoC relativos a las comunicaciones modbus de los activos que son de tipo SCADA o esclavo. Estos IoCs pueden ser relacionados, con ataques de tipo False Command Injection, False Data Injection, Scanning de aplicación, Denegación de Servicio de aplicación.
Además, opcionalmente, el sistema admite la ejecución de Snort (un IDS de detección de ataques conocidos), que también generará eventos asociados a ataques o vulnerabilidades según lo que observa en el tráfico. Durante esta fase de detección, también se detectan y notifican cambios en los activos aprendidos tales como nuevas comunicaciones o servicios que constituyen vulnerabilidades potenciales.
Cada uno de los módulos anteriores, generará un evento cuando se cumpla alguna condición preestablecida en cada IoC. Todos los eventos generados son procesados en una etapa posterior de correlación de eventos para determinar posibles ataques. Así, los eventos generados por los IoC del módulo de observación de flujos de red, junto con los eventos generados por Snort, serán correlacionados para producir alertas sobre posibles ataques genéricos a través de la red (p.ej., scanning de equipos, scanning de puertos, denegación del servicio (DoS), man-in-the-midle, etc.). Igualmente, los eventos generados por el módulo de observación de comunicaciones modbus, serán correlacionados para generar alertas sobre posibles ataques dentro del proceso industrial ICS (p.ej., False Command Injection, False Data Injection, scanning de variables). Estas alertas deberían ser estudiadas de forma inmediata por un operador de seguridad para determinar si son falsos positivos o no, y, en tal caso, las acciones reactivas que correspondan. Esto se representa en la siguiente figura. El sistema puede almacenar todas las alertas localmente en un fichero de alertas o bien puede enviarlas a un sistema centralizado a través de Internet.
Resultados
- Los resultados de este proyecto corresponden a un prototipo operativo del sistema y una memoria técnica. La información relativa a estos es CONFIDENCIAL.