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.
shernando@hispasec.com
Más información:
Cisco Security Response: RealVNC Remote Authentication Bypass Vulnerability
http://www.cisco.com/warp/public/707/cisco-sr-20060622-cmm.shtml
Hardware Management Console Cumulative history and Readme for use with
HMC V5 R2 and V5 R2.1
http://www14.software.ibm.com/webapp/set2/sas/f/hmc/power5/install/v52.Readme.html#MH00688
Grave Vulnerabilidad en RealVNC
http://www.hispasec.com/unaaldia/2760
Importante actualización en Sendmail
http://www.hispasec.com/unaaldia/2707
Deja una respuesta