Las referencias a CERT o CSIRT dentro del mundo de la seguridad informática son frecuentes. Todo (o casi todo) el mundo dentro de este ámbito sabe lo que son y cuál es su función.
Sin embargo, en el tiempo que pasé estudiando Ingeniería Industrial jamás, ni una sola vez, escuché ninguna de estas palabras. Y parece razonable que así sea. Al fin y al cabo los “Equipos de Respuesta ante Incidencias de Seguridad Informática” (que eso es lo que son los CERT/CSIRT por si algún lector anda despistado) son, a todas luces, cosa de los informáticos, no de los industriales. Su nombre no da lugar a dudas: “Seguridad Informática”.
No obstante, un día, el que aquí escribe se encontró con otro de esos maravillosos acrónimos que tanto gustan en el mundo TI: ICS-CERT. Y… ¡un momento! Parece que los industriales ya no podemos escurrir el bulto. Porque los ICS son (por sus siglas en inglés) los Sistemas de Control Industrial. Y eso nos toca de lleno. Para aquellos que en este momento no sepan muy bien de qué estoy hablando o que estén preguntándose qué pintan los Sistemas de Control Industrial en un blog de seguridad informática les recomiendo encarecidamente que echen un vistazo a la sección de Ciberseguridad Industrial de esta bitácora.
El ICS-CERT opera dentro del National Cybersecurity and Integration Center (NCCIC) que es una división del Departamento de Seguridad Nacional de los EEUU. Como ocurre con los CERT clásicos, este organismo se encarga de, entre otras cosas, gestionar la publicación de vulnerabilidades y de recopilar las soluciones que los fabricantes dan para las mismas pero, en este caso, en el área de los sistemas de control industrial.
Así pues, en la medida en que existen CERT específicos para este tipo de sistemas, parece que los ataques a infraestructuras de carácter industrial empiezan a generar cierta preocupación. Así que hay alguien que se encarga de avisar al fabricante en caso de encontrarse vulnerabilidades y éste, a su vez, de publicar una solución que resuelva el problema a sus clientes. Después de tanto tiempo ya podemos dormir tranquilos, ¿o no? Veamos una de las últimas alertas publicadas: ICSA-15-064-04.
Se trata de una vulnerabilidad [CVE-2015-2177] para todas las versiones de PLC SIMATIC S7-300 de Siemens, una de las series de autómatas más extendidas en todo tipo de procesos industriales (industrias química, energética, alimentaria o de suministro y depuración de aguas, sin ir más lejos).
La puntuación de esta vulnerabilidad es de 7,8 sobre 10 (CVSS Base) y permite una Denegación de Servicio (DoS) en esos equipos sin autenticación previa. Es decir que, en ciertas circunstancias, sin necesidad de poner ni usuario ni contraseña, un atacante podría dejar “KO” nuestro sistema. Y además podría hacerlo de manera remota, sin estar físicamente cerca de los equipos. Haciendo llegar a nuestro PLC una serie de paquetes de datos creados ad hoc (textualmente en el CVE: “specially crafted packets”) el PLC se queda en modo de defecto. La única opción que tendríamos en ese caso sería reiniciar nuestro PLC.
El problema parece bastante serio. No hace falta tener un conocimiento técnico muy profundo para entender la gravedad de las consecuencias de un paro inesperado en la producción en cierto tipo de industrias. Pero bueno, no hay nada de lo que a priori debamos preocuparnos porque Siemens ha publicado ya su solución (PDF). Y viendo la relevancia de la vulnerabilidad, seguro que ya estaremos a salvo. O quizá no…
Veamos con un poco más de detalle qué nos dice el fabricante. Para mitigar el problema Siemens nos recomienda:
- Aplicar protección de nivel 3 (protección de lectura/escritura).
- Aplicar el concepto de “Protección de celdas”.
- Usar VPN para comunicaciones entre las celdas.
- Aplicar “Defensa en profundidad”.
Lo primero que nos llama la atención es el uso del verbo mitigar. De hecho, si buscamos una vulnerabilidad muy similar publicada por el mismo grupo de investigación [CVE-2014-2256], observamos que Siemens proporciona una actualización de firmware y utilizan otro verbo: “resolver”. Parece que el uso de la expresión “mitigar” es deliberado.
Hagamos un repaso punto por punto a las propuestas de Siemens.
Aplicar protección nivel 3. Buceando un poco en la documentación de los S7-300 vemos que se trata de una protección de acceso a la información de la CPU que se puede activar a través del software de programación de Siemens para estos PLC, STEP 7. Si nos vamos al manual encontramos lo siguiente:
Es decir, si establecemos un nivel de protección 3 se nos solicitará contraseña para cargar y/o descargar el programa que hay en el PLC. Además, y aquí viene algo interesante: “impide la ejecución de funciones online que pudieran impedir negativamente en el proceso”. ¿Podría esto resolver nuestro problema? Busquemos un poco más en el manual.
El concepto “online” en este caso se refiere a estar conectado con nuestro sistema de control a través del software de programación “STEP 7”. Parece poco probable que, tratándose de “specially crafted packets”, su envío haya de realizarse necesariamente a través de STEP 7. Además, en cualquier caso, el PLC sigue intercambiando información con el resto de elementos de nuestro sistema de control (porque para eso está diseñado) por tanto, aún con esta protección habilitada, si somos capaces de acceder a la red donde el PLC se encuentra, podríamos hacerle llegar el paquete malicioso.
Puesto que el código específico no ha sido publicado, no hemos podido reproducir la situación exacta en nuestro laboratorio pero la experiencia con casos similares a este nos dice que este tipo de acciones mitigan el problema pero no lo solventan.
La segunda medida que nos sugiere Siemens es aplicar el concepto “Protección de celdas”. O lo que es lo mismo: segmenta tu red. Pon dentro de una misma celda todos aquellos elementos de tu sistema que no tengan mecanismos propios de protección o que no sean capaces de establecer comunicaciones cifradas (que probablemente no serán pocos). Todos aquellos elementos que deban tener comunicación en tiempo real es conveniente que también estén dentro de la misma celda. Esto, en algún caso y según el proceso, nos deja con una celda del tamaño de nuestro sistema de control completo.
La tercera recomendación es usar conexiones VPN para comunicaciones entre celdas. Asegúrate de que toda la información que viaja entre esos segmentos va convenientemente cifrada. No vaya a ser que alguien sea capaz de leerla sin permiso o, lo que podría ser incluso peor, leerla y devolverla modificada. Aunque en el entorno TI la aplicación de esta recomendación sea trivial, en el entorno industrial puede llegar a ser complicada. En el caso de que fuera posible tener diferentes celdas, la mayoría de equipos que se venden para sistemas de control industrial no acepta protocolos cifrados. ¿Cómo establecer este tipo de comunicaciones si los equipos no las admiten? Además esto tampoco es una verdadera solución para nuestro problema. Si conseguimos acceder a una de las celdas, aunque la comunicación entre ellas sea cifrada, el paquete malicioso seguiría llegando a su objetivo. Una comunicación cifrada (si el cifrado es robusto) es tan frágil como lo sean sus extremos, en este caso, las celdas.
Por último, Siemens nos aconseja aplicar “Defensa en profundidad”. Esto es, crea diferentes perímetros de seguridad lógica alrededor de tu sistema de control industrial. Haz uso de firewalls, proxies y pon en marcha sistemas automáticos de detección y protección frente a intrusiones (IDS/IPS). Lleva a cabo una adecuada política de gestión de usuarios y de renovación de contraseñas y mantén actualizados los antivirus y software de listas blancas en los PCs de la red de control.
Como se ha visto, la solución de Siemens tiene mucho de “hágalo usted mismo”… si puede. Y es que si alguno esperaba algo que se pareciera a un parche o una actualización de firmware ha errado el tiro. El fabricante nos da recomendaciones para que trabajemos en la protección de la arquitectura de nuestro sistema porque no ha encontrado una solución definitiva para proteger el equipo. Y aunque no es ningún disparate trabajar en esa línea, no es lo que se esperaría en el mundo TI como respuesta de un fabricante ante la publicación de una vulnerabilidad. Se transfiere toda la responsabilidad directamente al propietario del equipo.
Ya hemos comentado en algún que otro post que la realidad del entorno industrial es sensiblemente distinta a la del entorno puramente corporativo. Éste ha sido sólo un ejemplo práctico más. Su naturaleza, los requerimientos de funcionamiento de este tipo de sistemas y a menudo también el modo en que se debe trabajar con ellos, impiden la aplicación directa del tipo de soluciones clásicas del entorno TI. Los propietarios y operadores de este tipo de infraestructura han de seguir tomando conciencia y adoptar acciones compensatorias. Evaluar el estado de la ciberseguridad de sus ICS y monitorizar las comunicaciones en los mismos puede ser un buen punto de partida. Bueno, eso o esperar sentado una solución de los fabricantes. Sentado.
Fuentes de las imágenes:
- La ilustración del ICS Cert es una captura de https://ics-cert.us-cert.gov/.
- La imagen del CVSS Score es de http://www.cvedetails.com/.
- La última ilustración es de http://www.harquin.com/pov/?article=113.