La industria SCADA debate sobre la revelación de información de problemas de seguridad

Repasando los feeds de SecurityFocus he topado con esta noticia, que confieso me interesa un poquito más que otros asuntos relacionados con el complejo mundo del flaw disclosure.

Y es que amigos míos, un servidor se crió en un ambiente de ingeniería industrial, y eso hizo que tuviera contacto directo precisamente con sistemas SCADA, especialmente en la parte relativa a adquisición de datos, y en general, todo lo referente a sistemas informáticos de control industrial.

Los sistemas SCADA, para aquellos que os suene a chino, son aquellos en los que existe un proceso continuo informatizado en el que se hace una adquisición de datos, los llamados parámetros de control, que son analizados para posteriormente, con los resultados del análisis en la mano, reinyectarlos en el sistema, con el fin de obtener un gobierno parametrizado y automatizado que además de lograr el equilibrio, conduzca al sistema a un grado de optimización.

Volviendo a la noticia, parece que los siempre herméticos miembros de la comunidad SCADA empiezan a pronunciarse sobre la revelación de vulnerabilidades. Tradicionalmente, este selecto club no había entrado en este tipo de debates, pero parece que empiezan a mojarse. Y todo ello, cómo no, a raíz de un problema de seguridad. El reciente fallo del servidor ICCP de LiveData ha abierto la caja de Pandora en el sector.

Este problema representa el primer problema de seguridad SCADA documentado que ha seguido los cauces de revelación de información establecidos por US-CERT, con la colaboración del CERT/CC que se encargó, según dicen, de la parte más farragosa, el trabajo de coordinación entre fabricantes.

El jaleo se presenta cuando los descubridores del bug, los chicos de Digital Bond, deciden seguir un proceso coherente de notificación que concluye en la publicación de un aviso de seguridad, en el que se demuestra que es posible colapsar servidores ICCP de LiveData, empleados habitualmente en sistemas SCADA. No sólo avisan al fabricante, sino que dejan el asunto en manos del US-CERT para la coordinación y que los afectados e incluso otros fabricantes que emplean el servidor ICCP como parte de sus soluciones, puedan actuar, corregir los sistemas y ponerse al día ante cualquier full disclosure que pudiera acontecer.

En mi modesta opinión, Digital Bond ha hecho lo correcto. Otros se les han tirado al cuello, ya que para bien o para mal, los sistemas SCADA vulnerables que emplean ICCP es frecuente localizarlos en silos de misiles, plantas nucleares, control aeroportuario y un sinfín de aplicaciones altamente críticas, donde una denegación puede resultar muy problemática.

Ante este escenario, ¿qué hacer? ¿revelar la información o guardársela?. Que cada cual extraiga sus propias conclusiones :)

6 comentarios sobre “La industria SCADA debate sobre la revelación de información de problemas de seguridad

  1. Yo creo que es mejor revelarla, la seguridad basada en la ocultación es peligrosísima.

    Por cierto, que parece que tu feed (http://www.sahw.com/wp/feed/) da problemas desde hace unas semanas. Se lee raro sin acentos ni nada, es posible que sea un fallo de la codificación.. Ahm uso feeddemon para leerte.

    Saludos. :-)

  2. Holas ;)

    El tema de los feeds que comentas es un tema de codificación. Que yo recuerde, el blog está codificado en ISO-8859-15, y no en UTF-8. Esto hace que los agregadores o los programas de lectura de feeds que se basan en UTF-8 vean los feeds en ISO-8859-1 «raros».

    Otros agregadores como Bloglines, no tienen problema en interpretar ISO 8859-15. Recuerdo que hace dos años ya se me planteó la disyuntiva de elegir «charsetting» y me decanté por el ISO Europero en vez del UTF, ya que eran más los perjudicados por ver cosas raras desde UTF-8 que los que estaban en ISO-8859-1 o ISO-8859-15.

    Así pues, siento que FeedDemon vea el feed en una codificación que le resulta extraña. Quizás puedas especificar en el programa el charset a utilizar. De no ser así, lo siento de veras :(

    Saludos,

  3. Estoy de acuerdo con Corsaria. Lo del «security through obscurity» es peligroso, y además nunca sabes si alguien verá la luz repentinamente y lo utilizará en beneficio propio.

    Sin embargo, muchas compañías siguen «erre que erre» en lo mismo. Hace unos años, antes de contratar una línea WAN por enlace de radiofrecuencia, quise saber el sistema de encriptación utilizado, y me contestaron: «Eso no se puede revelar, porque es confidencial, pero quédate tranquilo que lo han desarrollado en Israel». Aparte del novedoso concepto de criptografía con denominación de origen, ¡lo que hay que oír! :-)

Comentarios cerrados.