Los efectos colaterales de las vulnerabilidades

Legislación

Si nos referimos a normativa, la gestión de las vulnerabilidades técnicas puede enfocarse de muchas maneras. La más empleada es posiblemente la gestión de vulnerabilidades según ISO 17799:2005, cuyo punto 12.6 está específicamente diseñado para estos propósitos, como parte vital dentro del dominio que componen la adquisición, el desarrollo y el mantenimiento de sistemas de la información.

El control de vulnerabilidades técnicas se puede abordar desde diversas ópticas complementarias y paralelas a la citada. Si nos referimos a la reciente ISO 27001:2005, se nos recomienda el establecimiento de controles que permitan reducir los riesgos debidos a la explotación de vulnerabilidades publicadas.

Quizás sería conveniente corregir ese matiz de la norma e incluir no sólo las vulnerabilidades publicadas, sino también las que no lo están. Es que la gestión de TI debe tener un concepto de previsión que en raras ocasiones se está utilizando cuando definimos controles para este punto de la norma. Así por ejemplo, si abordamos el control para productos de amplio espectro de uso como Mozilla Firefox o Internet Explorer, productos que sabemos que tienen un historial notorio de vulnerabilidades, es prudente prever futuras fallas, que si bien no serán conocidas en detalle hasta que ocurran, sabemos que tarde o temprano aparecerán.

En líneas generales, la gestión de vulnerabilidades enfocada desde las buenas prácticas consiste en obtener información a tiempo de las vulnerabilidades técnicas, evaluar la exposición de la organización ante dichas problemáticas y definir las acciones apropiadas para mitigar y solucionar las deficiencias técnicas. Para un adecuado gobierno IT no debe bastar con esperar a que los fabricantes nos pongan en bandeja los parches. Hay que extraer inteligencia y metodologías de previsión de los incidentes documentados. Este pequeño valor añadido es el que convierte a la gestión de parches tradicional en una gestión de vulnerabilidades proactiva, acorde a las necesidades de gestión de riesgo que precisan las organizaciones.

En muchas ocasiones, este control de vulnerabilidades termina cuando gestionamos una corrección primaria. Aparece un fallo en RealVNC y lo solucionamos. Aparecen fallos en OpenSSH y Sendmail y son corregidos. Sirvan estos tres ejemplos para ilustrar que esta política no suele ser suficiente, ya que los productos y servicios primarios son, en numerosas ocasiones, parte integrante de otros que heredan de los primeros los mismos estados de vulnerabilidad.

Vamos a poner un ejemplo muy sencillo que clarifica esta visión del problema. Si se nos ha fundido una bombilla en casa y al sacar del armario un retráctil de 6 bombillas éste cae al suelo, provocando la rotura de la bombilla que hemos seleccionado para reponer la fundida, lo más prudente es pensar que es posible que el resto de bombillas puedan estar dañadas, así que será conveniente examinar la totalidad de la caja en ese momento, para comprar nuevas bombillas en caso de que hayan quedado inutilizadas todas tras la caída. No parece adecuado guardar la caja sin más y esperar a que se funda una nueva bombilla para ver si tuvimos suerte en el primer incidente y sólo hubo una rotura. Actuando así, es posible que el día que precisemos un repuesto, no lo tengamos.

En la vida real

Yéndonos a casos reales, IBM Hardware Management Console (HMC), un extendido sistema de gestión por consola, se ve afectado de los recientes fallos declarados no sólo para OpenSSH (relativo a la inyección de comandos shell, sino también al de Sendmail (correspondiente a la corrupción de memoria en el manejo de señales). Ambas documentadas a tiempo en “una-al-día” y nuestro servicio corporativo de gestión de vulnerabilidades S.A.N.A. Aquellas organizaciones que cerraron la gestión de parches con los ofrecidos por los fabricantes primarios el 13 de febrero y el 23 de marzo respectivamente, fueron notificados ayer de que un producto, en este caso IBM HMC, se veía expuesto colateralmente por dichos problemas, con lo que la correcta aplicación de controles sobre el punto 12.6 de la norma obliga a reabrir la incidencia y paliarla, siguiendo los mismos procedimientos, siempre y cuando seamos usuarios de esta solución.

Otro caso demostrativo es el que padece Cisco CallManager, que adolece de un salto de restricciones en RealVNC. El incidente original se remonta al 17 de mayo, pero sin embargo es ayer cuando los servicios postventa de Cisco oficializan que CallManager padece de ese mismo problema. En ambos casos, las ventanas temporales son muy amplias y por tanto, el grado de exposición de las organizaciones es extremo, ya que los tres problemas documentados, especialmente el de RealVNC, son de carácter altamente crítico.

¿Es normal que los fabricantes como Cisco e IBM hayan consumido tanto tiempo en notificar la afectación indirecta en sus productos? Sí, es comprensible, ya que sus laboratorios sólo resuelven problemas colaterales que no hayan sido provocados en primera instancia por desarrollos propios. Además, la calidad de servicio de ambas compañías requiere que estos efectos colaterales se prueben y verifiquen en cientos de configuraciones distintas, desplegadas para clientes en ámbitos de TI muy dispares y sometidos a contratos de servicio con requisitos técnicos y legales bastante heterogéneos.

Es aquí donde tenemos que corregir a ISO 17799 e ISO 27001, y no circunscribir únicamente la gestión de vulnerabilidades técnicas a los problemas publicados y declarados, sino ser proactivos y, apoyándonos en buenos inventarios de productos internos, anticiparnos a los problemas futuros.

Eso es la gestión de la seguridad. Previsión, anticipación y proactividad. Atrás quedó la gestión de parches pura y dura.