Respuestas a la política de actualizaciones de Microsoft

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.