Los fabricantes de soluciones SCADA debaten sobre la revelación de información de problemas de seguridad

Según la tecnología se hace más accesible y más madura, nuevos servicios y productos irrumpen en los mercados, trayendo cada uno de ellos el pan de los problemas de seguridad bajo del brazo.

Generalmente, los avisos de seguridad son de criticidad baja, o media. Los avisos críticos o muy críticos son menos frecuentes, lo que sin duda representa un balón de oxígeno para aquellos administradores corporativos y usuarios finales. Ya que deben mantener, en un entorno muy cambiante, una variedad muy amplia de sistemas, sujetos a continuo escrutinio en busca de problemas de seguridad. No sólo por parte de los laboratorios, sino de atacantes que pretenden como bien sabemos, obtener beneficios diversos de la explotación de sistemas.

En algunos segmentos, los problemas de seguridad soy muy poco frecuentes. Posiblemente por estar menos expuestos y ser menos populares, a causa de su complejidad y por tratarse de sectores en los que tradicionalmente los problemas de seguridad se solucionan sin levantar mucha repercusión mediática. Uno de estos ámbitos es el que representan son los sistemas de control SCADA.

Los sistemas SCADA (Supervisory Control and Data Acquisition) son aquellos empleados habitualmente en el control y monitorización de procesos industriales, con un elevado factor de automatización, y que generalmente precisan de supervisión continua para garantizar el estado óptimo de operación. Cualquier entorno industrial o de alta especialización es susceptible de funcionar con algún sistema de este tipo, incluso con varios en combinaciones diversas.

Los problemas de seguridad en entornos SCADA son siempre un arma de doble filo: por un lado tenemos el problema de seguridad en sí, y por otro lado, la criticidad del entorno de operación. Este segundo factor normalmente es el más delicado, y esto es fácil de comprender. Los procesos de control industrial y no industrial supervisados por sistemas SCADA son muy variopintos, y entre ellos están procesos de alta criticidad. Se emplean en industrias petroleoquímicas, químicas, generación y transporte de energía eléctrica, plantas nucleares, instalaciones militares, aeroportuarias, aerospaciales, aceleradores de partículas… la lista es larga, así como las implicaciones que puede tener un problema de seguridad en cualquiera de estos entornos.

Recientemente, un problema de seguridad inherente a SCADA ha suscitado una polémica, en un sector de la seguridad de la información en el que tradicionalmente no suele haber noticias ni flujo de información, debido a su exclusividad. En este caso, el desbordamiento de búfer en un servidor ICCP de LiveData ha sido el detonante de la mecha. Técnicamente, el problema se debe a un error de límites en los servidores ICCP que permite, previo envío de cápsulas malformadas, denegar el servicio de estas implementaciones del RFC 1006 del servicio de transporte ISO sobre TCP, habituales en despliegues SCADA.

El problema técnico es moderadamente crítico, pero lo que hace que este tipo de problemas sea de una criticidad extrema es el factor entorno de operación, tal y como se ha comentado anteriormente. No es lo mismo denegar el servicio de un servidor de correo que denegar el servicio en un servidor que tiene implicaciones en la gestión de, por poner un ejemplo, la alimentación de barras de combustible en un reactor nuclear. Las razones son obvias.

Los descubridores del problema, Digital Bond, una de las únicas consultoras de seguridad dedicadas a la seguridad SCADA, recurrieron al proceso de revelación de información vía US-CERT. Contactaron con el fabricante, y dejaron que US-CERT y CERT/CC gestionasen el difícil proceso de sincronizar y coordinar a los fabricantes que dependen del producto vulnerable, así como a los fabricantes en los que había sospecha de vulnerabilidad por la naturaleza del problema detectado.

Finalmente, hoy día 17, se ha liberado un aviso público de seguridad en el que queda patente que estos servidores son vulnerables. Esto ha abierto el debate sobre si es pertinente o no ofrecer este tipo de información en un sector en el que tradicionalmente no suele haber revuelos. De hecho, es la primera vez que se gestiona vía CERT un problema de seguridad de este tipo, lo que hace que el caso sea especialmente llamativo.

Esto demuestra, tal y como comentan en el blog de Digital Bond, que CERT tiene la suficiente capacidad para coordinar incluso en un ambiente que habitualmente no es el que suelen manejar. El aviso publicado está precedido por 8 semanas de espera transcurridas entre el aviso inicial al fabricante y la puesta en conocimiento de CERT del asunto.

Adicionalmente, se fijaron horquillas de entre 3 y 6 meses para que el fabricante resolviera el problema una vez notificado, lo que hace que desde que se avisara inicialmente al vendedor, debieran transcurrir entre 6 y 9 meses para que el aviso viera la luz.

El problema documentado, volviendo al símil de la punta del iceberg, es sólo el comienzo del hilo del que poder tirar. Otros muchos sistemas SCADA/EMS operan con implementaciones ICCP bajo formatos propietarios, lo que hace que sea altamente probable la existencia de productos en situación de vulnerabilidad similar. En palabras de Digital Bond, numerosos fabricantes, en los que recaen sospechas de problemas parecidos, no ofrecieron información sobre el estado de vulnerabilidad de sus productos, con lo cual se desconoce si deben o no deben ser sometidos a actualización. Estos fabricantes con estatus de vulnerabilidad desconocido son, según CERT, Advanced Control Systems Inc, Barco, Eliop, EA-India, Invensys Process Systems, LogicaCMG, Radio Control Central Stations Inc, SPL Worldgroup Inc, S&C Electric Company y Telvent.

Como nota final, comentar que los administradores de la solución afectada, ICCP LiveData, pueden actualizar en ftp://ftp.livedata.com/. Se consideran vulnerables todas las versiones del producto anteriores a la versión 5.00.035. Los administradores SCADA que tengan en su infraestructura algún tipo de implementación ICCP deberían, con la máxima premura, contactar con el soporte del fabricante para conocer su estado de vulnerabilidad, si existiera.