Respuestas a la política de actualizaciones de Microsoft
El pasado día 15 publicamos en una-al-día las explicaciones de
Microsoft sobre su nueva política de actualizaciones. Hoy damos la
palabra a nuestros lectores.
Debido al gran volumen de mensajes, y lo extenso de algunos, vamos a
intentar resumir en cinco puntos los argumentos que más se repitieron
por parte de los lectores.
1) Las vulnerabilidades existen y se
explotan antes de ser publicadas
En las explicaciones de
Microsoft podíamos leer Las vulnerabilidades representan un aumento
exponencial del riesgo a partir de su descubrimiento y anuncio, no
antes. […] no perdemos en materia de seguridad desde el momento que
asumimos que el riesgo es casi inexistente antes de cualquier tipo de
anuncio.
Respecto a esta afirmación, son muchos los
lectores que recuerdan que no todas las vulnerabilidades se publican
cuando son descubiertas, no todo los hackers son whitehats. De hecho
existen grupos de investigación dedicados a descubrir vulnerabilidades y
a explotarlas en beneficio propio.
Que una vulnerabilidad no se
publique, no quiere decir que no existan ataques basadas en ellas que
estén pasando desapercibidos. El sistema debe ser seguro por diseño, no
porque no se publiquen o se oculten sus fallos. No a la seguridad por
oscuridad.
2) Microsoft no descubre las vulnerabilidades
Según Microsoft en ese 0,1 por ciento de casos donde el orden de
sucesos no ocurra de esta forma, como por ejemplo el conocimiento de una
vulnerabilidad de forma previa a la creación del update.
Para muchos lectores ese porcentaje tal vez sería válido a la inversa, es
decir, la inmensa mayoría de los descubrimientos de agujeros en el
software de Microsoft son autoría de terceras personas ajenas a la
compañía. Por lo tanto las vulnerabilidades suelen conocerse antes de la
creación y distribución de la actualización.
Microsoft no puede, ni debe, controlar el descubrimiento y publicación
de vulnerabilidades.
3) Las empresas planifican sus propias
políticas de actualizaciones
La medida está pensada
fundamentalmente para minimizar situaciones de actualización de software
no planificadas, y permitir que una corporación pueda planificar sus
recursos adecuada y ordenadamente ante una actualización de seguridad.
Muchos administradores de sistemas y responsables de seguridad indican que
cuentan con sus propias políticas corporativas de actualizaciones, y que
la planificación de éstas no deben estar condicionadas (ni se van a ver
mejoradas) porque las actualizaciones se encuentren disponibles un día
determinado.
En la mayoría de los casos, en ambientes críticos,
los parches y actualizaciones deben pasar unos tests y controles de
calidad en sistemas de pruebas, antes de distribuirlos en los sistemas
en producción. No en vano, la instalación directa e inmediata de los
parches puede ocasionar problemas de incompatibilidad, mal
funcionamiento, o regresión de vulnerabilidades.
Este tipo
de comprobaciones, que hasta ahora se hacía de forma escalonada y
puntual según publicación de parches concretos, ahora resulta más
complicada al acumularse todo en una fecha, y puede dar lugar a retrasos
en el despliegue final. No es lo mismo, ni se tarda el mismo tiempo, en
comprobar que una actualización para Internet Explorer es correcta, que
en comprobar 6 ó 7 parches para diferentes componentes del sistema.
En definitiva, en muchos casos la acumulación de parches supone un retraso en
la distribución final de los mismos en ambientes corporativos. Los
administradores piden que la actualización se encuentre disponible tan
pronto sea posible, ya serán ellos los que decidan como les afecta, la
prioridad, y el día en que se procederá a su instalación.
4) Dificultad para usuarios sin banda ancha en la descarga de grandes
actualizaciones
Algunos usuarios, que conectan a Internet a
través de módems analógicos conectados a la red telefónica básica,
muestran su preocupación por la acumulación y distribución de los
parches en un mismo día.
Si algunas actualizaciones
individuales pueden ocupar megas, la actualización del paquete mensual
puede llegar a ser todo un inconveniente para ellos.
Como
anécdota, recordar que fueron muchos los usuarios domésticos que
tuvieron problemas con la actualización de la vulnerabilidad que
explotaba el gusano Blaster, ya que en el tiempo que tardaban en
descargarse la actualización desde Internet el gusano volvía a
infectarles y/o a reiniciar sus equipos.
5) Comparativa Microsoft
vs. Linux cualitativa (no cuantitativa)
Con respecto a los
números barajados por Microsoft, a la hora de comparar vulnerabilidades
entre sus sistemas y algunas distribuciones de Linux, los lectores hacen
hincapié en que es necesario distinguir entre vulnerabilidades de
aplicaciones y del propio sistema operativo.
Las distribuciones
cuentan con un gran número de aplicaciones, de instalación opcional, que
no forman parte del sistema operativo. Además, no basta con dar números
absolutos, debería analizarse cuantas de esas vulnerabilidades son
explotables remotamente, y el impacto real en la seguridad de los
usuarios.
La propia política de Microsoft, de integración de
aplicaciones y funcionalidades extras en el propio sistema operativo,
supone un aumento en el número de vulnerabilidades que afectan a todos
sus sistemas. Un ejemplo claro lo tenemos en Internet Explorer.
Con respecto a la resolución, muchos lectores recuerdan que en algunos
casos la comunidad Open Source, tras el descubrimiento de una
vulnerabilidad, facilita parches en cuestión de horas. En última
instancia, el usuario tiene el control sobre el sistema, y no depende
exclusivamente de la resolución de una empresa.
La clave
A título personal, aunque comparto de forma genérica las opiniones de
los lectores, creo que la clave en la explicación de Microsoft está en
la afirmación en ese 0.1% de casos donde el orden de sucesos no ocurra
de esta forma, como por ejemplo el conocimiento de una vulnerabilidad de
forma previa a la creación del update, NO SE SEGUIRÁ ESTA NORMA DE
PUBLICACIÓN MENSUAL y se publicará en cuanto la actualización esté
preparada.
El caso es que desde hace semanas tenemos varios
de esos casos, en concreto hay varias vulnerabilidades de Internet
Explorer que se han hecho públicas (algunas desde finales de noviembre),
han sido catalogadas como críticas (tanto por su impacto como por la
facilidad de explotación), y están siendo aprovechadas en ataques.
A día de hoy, finales de diciembre, aun no hay parches para corregir esas
vulnerabilidades. De entrada queda patente los tiempos de respuesta de
Microsoft ante vulnerabilidades críticas. Si bien aun queda pendiente
conocer cuando se publicarán finalmente estos parches.
Si
los parches de Internet Explorer se publican en su paquete de
actualizaciones mensuales, el segundo martes de enero, en vez de hacerlo
de forma puntual en cuanto tengan la solución (dada la importancia),
Microsoft habrá tirado por tierra gran parte de sus propias
argumentaciones.
