Los efectos colaterales de las vulnerabilidades

Las diversas vulnerabilidades que aparecen día a día constituyen, en muchas ocasiones, únicamente un primer foco de exposición para los usuarios y las organizaciones.

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.

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.

Technorati : seguridad informatica, virus
Del.icio.us : seguridad informatica, virus