Continuando con la línea de trabajo iniciada con los tres anteriores informes sobre protección de infraestructuras críticas, S2 Grupo publicó hace unas semanas la cuarta entrega. En esta ocasión, nos hemos centrado en una serie de dispositivos de los que actualmente depende gran parte de la infraestructura industrial española y son muy susceptibles de recibir ciberataques: Los sistemas de automatización de procesos industriales ICS (“Industrial Control System” por sus siglas en inglés).
Los sistemas de control industrial controlan, supervisan y gestionan la infraestructura esencial (crítica) de sectores relacionados con el suministro de energía eléctrica, el abastecimiento de agua y la gestión de aguas residuales, el petróleo y el gas natural, el transporte y otras actividades industriales. Incluyen componentes como sistemas de supervisión, control y adquisición de datos (SCADA), controladores lógicos programables (PLC) o sistemas de control distribuido (DCS). Los ICS se han vuelto un blanco muy apetecible para los ciberatacantes. Los ataques dirigidos ya no son intentos de intrusión realizados por curiosos, sino ciberdelincuencia o ciberguerra. Tanto la seguridad nacional como los beneficios corporativos dependen del funcionamiento fiable y seguro de estos sistemas de control industrial. En vista de estos riesgos muchos países, entre ellos España, están dándose cuenta de la necesidad de proteger mejor los sistemas ICS con la inversión y las medidas adecuadas.
Una vez instalados, los dispositivos ICS tienden a utilizarse durante años y se aíslan o se confía su seguridad a protocolos y hardware especializado cuya verdadera seguridad se desconoce. Muchos de estos sistemas se crearon antes de que las empresas usaran tecnologías basadas en Ethernet, y en su diseño se tuvieron en cuenta aspectos como la fiabilidad, el mantenimiento y la disponibilidad, pero no tanto la seguridad. Sin embargo, hoy en día es necesario que estén conectados a redes y que, en muchos casos, sean accesibles de forma remota, lo que deja al descubierto sus vulnerabilidades y cambia radicalmente la superficie de ataque. Los ataques a sistemas ICS han evolucionado y se han vuelto más frecuentes, por lo que urge mejorar las medidas de protección. Según sus objetivos, que van desde el ciberespionaje hasta la inutilización del sistema, las repercusiones sociales y económicas pueden ser graves. Sin embargo, muchos incidentes no llegan a hacerse públicos para que no peligre la reputación de la víctima, lo que lleva a subestimar la gravedad del problema. El último incidente de 2014 fue el ataque a una fábrica de acero alemana cuyos altos hornos sufrieron graves daños a raíz de un ataque cibernético.
Resumiendo, la seguridad en estos sistemas se ha convertido en estos últimos años en un tema de excepcional relevancia desde que aparecieron una serie de incidentes como el de la acería alemana comentado anteriormente. Estos ataques mostraban que es posible para los ciberterroristas, empresas competidoras y servicios secretos de otros países, sacar provecho cuando no se le da alta prioridad a la seguridad de la información de los ICS. Conocer el modo en que los atacantes pueden aprovechar las vulnerabilidades descubiertas en los ICS de infraestructuras críticas constituye una parte esencial de cara a estimar tendencias futuras. Para ello, el equipo de S2 Grupo ha llevado a cabo un trabajo de investigación tomando como fuente de información para una serie de fabricantes seleccionados, todas las CVE (vulnerabilidades publicadas) de la web del ICS-CERT [1] [2] desde Enero de 2014 hasta Julio de 2015. Dicha investigación ha dado lugar al 4º informe de protección de infraestructuras críticas.
Los fabricantes seleccionados han sido los siguientes:
ABB, GE (General Electric), Honeywell, Omron, Rockwell Automation, Schneider Electric, Siemens y Yokogawa.
Para cada vulnerabilidad, se ha obtenido la suficiente información que se ha caracterizado y clasificado para determinar:
- Quién descubre la vulnerabilidad (un fabricante, un investigador independiente, la universidad, una empresa de seguridad).
- El tipo de componente en el que aparece la vulnerabilidad (SCADA/HMI, Protocolo, PLC, Otro hardware, Otro software).
- De qué tipo de vulnerabilidad se trata (Buffer Overflow, Ejecución de código remoto, Web (servidor), Escalada de privilegios, DoS (denegación de servicio), Autentificación/Gestión de contraseñas).
- Qué tipo de solución se adopta (Sin solución propuesta, Software o Firmware actualizado (parche)).
- Qué tipo de mitigación recomienda el fabricante (Aislamiento, Actualizar versiones nuevas/Aislar versiones viejas, Actualizar & Aislar).
- Nivel de riesgo de la vulnerabilidad basado en el CVSS v2 Base Score (bajo, medio, alto).
- Si se puede explotar la vulnerabilidad de forma remota.
- Si existen “Exploits” publicados para cada vulnerabilidad descubierta.
- Qué nivel de habilidad del atacante es necesario para explotar la vulnerabilidad con éxito (bajo, medio, alto).
A continuación, con todos los datos recopilados se ha procedido a elaborar un estudio estadístico con la finalidad de obtener conclusiones que den una respuesta aproximada a futuras tendencias que pudieran seguir los ciberatacantes.
El análisis realizado muestra en primer lugar, lo incipiente de la investigación de vulnerabilidades en componentes de ICS a nivel mundial. Y esa es la primera conclusión. La comparación entre el número de vulnerabilidades publicadas por el ICS-CERT durante el periodo analizado con su equivalente TI no deja lugar a dudas: 136 frente a aproximadamente 10.000. Eso quiere decir, básicamente, que la mayor parte de las vulnerabilidades potenciales existentes en ICS están esperando todavía a ser descubiertas y constituyen, por tanto, una amenaza latente para los usuarios de estos sistemas y las organizaciones que dependen de ellos. A pesar de todo, la muestra adquirida permite obtener importantes pistas acerca de cómo afrontar la seguridad de estos sistemas y las infraestructuras críticas en los que integran.
Tan sólo el 14% de las vulnerabilidades de los ICS son descubiertas por los propios fabricantes. Es importante tener esto en mente en un sector en el que, en muchos casos, los operadores de las infraestructuras temen las implicaciones de la intervención de terceros especialistas en ciberseguridad en las garantías y contratos de mantenimiento suscritos con los fabricantes. A la vista de los resultados, parece evidente que no cabe esperar que la solución provenga, exclusivamente, de los que diseñaron, implementaron y, en muchos casos, mantienen los sistemas como contrata externa.
La mayor parte de las vulnerabilidades se descubre en software asociado al software SCADA, incluyendo su diseño, explotación y mantenimiento. En nuestra opinión hay que ser prudentes, ya que puede existir un sesgo difícil de cuantificar. Como se ha dicho, la mayor parte de las vulnerabilidades no son descubiertas por los fabricantes que son los que tienen acceso fácil a su propia gama de productos. Parece evidente que para un tercero es más sencillo evaluar un software que tener acceso para investigación a equipamiento físico muy costoso.
Más interesante es ver cómo la mayor parte de las vulnerabilidades se clasifican como de denegación de servicio o autenticación: un 40% que asciende a un 80% en el caso de hardware y protocolos. Esto puede tener su origen en que el sector no ha adoptado, todavía, las prácticas de desarrollo seguro que ya constituyen estándares en el sector TI.
Esta situación es especialmente grave si se combina con el hecho de que, mientras que el 95% de las vulnerabilidades posee un parche, el 86% de las que no lo tienen se han hallado precisamente en las categorías de hardware o protocolo. Esto es lógico ya que, en principio, el software es más fácil de parchear que el propio hardware. Por un lado existen interdependencias: en general no es posible sustituir un protocolo por una versión segura del mismo si los equipos que se comunican haciendo uso de ese protocolo no pueden recibir la actualización correspondiente de hardware. En segundo lugar, las largas vidas útiles de los equipos en el ámbito industrial hacen que muchos dispositivos, diseñados hace incluso décadas, no dispongan de medios para actualizar el firmware. Es más, especialmente en sistemas actuales pueden existir multitud de equipos muy específicos (por ejemplo, sondas o instrumentación) procedentes de distintos fabricantes y basta con que uno de ellos no disponga de la opción para que sea imposible modificar el sistema. Como conclusión: en un sistema ICS no existen soluciones sencillas ni generalizables y, en muchos casos, se debe recurrir a medidas complementarias, tanto técnicas como procedimentales y organizativas.
Existe una correlación entre la dificultad de parchear componentes de hardware y protocolos y la existencia de exploits públicos: A pesar de suponer el objeto de un 18% de las vulnerabilidades, no existe un solo exploit público dirigido contra PLC. Probablemente la razón sea el grado de conocimiento técnico especializado requerido para atacar estos sistemas: las mismas razones que hacen difícil parchear el hardware de los componentes de los ICS hacen difícil crear exploits. En general, el 82% de las vulnerabilidades publicadas no poseen, en el momento de redactar este informe, exploits públicos. No obstante, confiar la protección de las infraestructuras críticas a este hecho no es más que perseverar en el desacreditado paradigma de la seguridad por oscuridad: que se requiera conocimiento especializado no quiere decir que no sea posible adquirirlo, especialmente para individuos que han fijado como objetivo un sistema en particular (ya se vio en el III Informe de Protección de Infraestructuras Críticas la gran cantidad de información pública de valor libremente accesible a través de internet).
Y es que la famosa convergencia IT/OT ha hecho que un sorprendente 47% de las vulnerabilidades publicadas requieren de un nivel de conocimiento especializado bajo, según los criterios del ICS-CERT. Este hecho, combinado con que el 87% están calificadas como de riesgo alto nos ponen ante la verdadera magnitud del reto a que nos enfrentamos: sin ser alarmistas, la situación actual podría compararse con la de estar sentados sobre un barril de pólvora, especialmente al recordar que estos equipos se encuentran directamente en la interfase entre los sistemas de información y el mundo físico.
Y es que hay muchas cosas que hacer. La más obvia es actuar en aquello que está en nuestra mano. El análisis ha puesto de manifiesto la importancia del parcheo. A pesar de las dificultades que entraña y las entendibles renuencias basadas en las posibles incompatibilidades de las actualizaciones con los sistemas en explotación, para el 95% de las vulnerabilidades existen actualizaciones proporcionadas por los fabricantes. El hecho de que exista un 19% de vulnerabilidades para las que hay simultáneamente un parche y un exploit pone de manifiesto el riesgo a que se enfrenta una organización que decida no instalarlos o que, directamente, desconozca que tales soluciones existan (algo muy común en organizaciones que carecen de una estructura de seguridad de los ICS que permita estar al corriente de estas noticias). La buena noticia en este caso es que tan sólo en 1% de los casos existen exploits sin una actualización oficial.
Por último, el análisis también arroja pistas acerca de la importancia de la monitorización: el 84% de las vulnerabilidades analizadas son explotables de forma remota. Dado que los sistemas de nuestras infraestructuras críticas ya no pueden prescindir de sus accesos remotos y la integración en redes, la segmentación y la vigilancia en busca de anomalías (que no el aislamiento, otra noción de seguridad errónea) son parte fundamental de la protección. A este respecto, no está de más recordar la creciente exposición de los ICS desde la aparición de herramientas como SHODAN, algo que ya se puso de manifiesto en el II informe de Protección de Infraestructuras Críticas.
En definitiva, el resultado del análisis nos lleva a considerar como esenciales las siguientes premisas para conseguir un nivel adecuado de protección de los ICS de las infraestructuras críticas:
- Llevar a cabo una búsqueda independiente de las vulnerabilidades potenciales de los ICS.
- Disponer de una estructura dedicada a la gestión de la seguridad de los ICS.
- Incorporar la seguridad al proceso proyecto-construcción.
- Monitorizar la seguridad de los ICS para detectar de forma precoz cualquier anomalía tan pronto como se presente.
El informe completo está disponible para su consulta en este enlace.
Referencias:
