[Solar-general] solo para hacer lio... microsoft y la seguridad

[softwarelibre]

Bueno, en algun momento tenia que pasar...
les mando una nota de MS a Hispasec respecto a politicas de
seguridad...
(como ponen en CNN: "NO COMMENTS")

 Explicaciones de Microsoft sobre su nueva política de actualizaciones
 ---------------------------------------------------------------------

En diversas ocasiones, desde una-al-día hemos analizado y criticado la
nueva política de actualizaciones de Microsoft. En respuesta a
Hispasec, Héctor Sánchez, responsable de Seguridad Corporativa de
Microsoft Ibérica, nos ofrece el punto de vista oficial de Microsoft
al respecto, que a continuación reproducimos de forma íntegra.

>>>>>

Estimados amigos de Hispasec:

A la vista de las noticias publicadas el 12/11/2003 y el 9/12/2003 al
respecto de la política de Microsoft sobre los anuncios de
actualizaciones de seguridad, me doy cuenta del esfuerzo que desde
Microsoft tenemos que continuar haciendo en comunicar más claramente
los motivos por los que se toman determinadas decisiones.

Con ese objetivo, y por si lo consideráis de interés para los lectores 
de una-al-día, os doy la explicación a la que aludís en la noticia:

1.- ¿Que ha anunciado Microsoft exactamente?

Microsoft ha anunciado un cambio en la política de la comunicación de
actualizaciones de seguridad, de forma que estas se producirán de
forma predecible en el segundo martes de cada mes. Es decir, que ese
mes en el que se produzca una alerta de seguridad con su respectiva
actualización, el anuncio se hará ese día concreto. Y si durante ese
mes no ha habido ninguna alerta, como el caso del mes de Noviembre, no
se anunciará nada hasta el siguiente mes. Existirán excepciones cuando
la situación lo requiera como explicaré en el punto 3.

2.- ¿Que se persigue con esta política ?

Exclusivamente un solo objetivo: Permitir la PLANIFICACIÓN. Sabemos
del esfuerzo que representa para una compañía un proceso de
actualización de software ante la aparición de un problema de
seguridad.

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. No existe ningún otro objetivo.

3.- Bien, ganamos en planificación, pero ¿Cómo afecta esta medida a la
seguridad de nuestros sistemas?

El primer pensamiento que surge es del estilo: "Pero como voy a
mantener mi sistema vulnerable durante un mes hasta que llegue ese día
de actualización?" Esta es la preocupación que mayoritariamente se nos
ha transmitido tras el anuncio de esta medida. Si pensamos en ello
detenidamente, veremos lo siguiente:

Las vulnerabilidades representan un aumento exponencial del riesgo a
partir de su descubrimiento y anuncio, no antes. Para ilustrar esto,
algunos ejemplos:

 - La distribución del MIT de Kerberos ha tenido una vulnerabilidad
latente durante años (9, 10 ?? ) Sin embargo, esta solo ha supuesto un
riesgo elevado, cuando ha sido descubierta, no antes.

 - El mismo ejemplo lo tenemos en el protocolo de gestión de red SNMP:
Un protocolo que tras 15 o 20 años de existencia, apareció en el año
2002 de la noche a la mañana vulnerable y es a partir de ese momento
del descubrimiento cuando supone un riesgo, no antes.

 - Si nos vamos a los Sistemas Operativos, podemos poner ejemplos en
todo tipo de sistemas, dado que el problema de las vulnerabilidades
afecta a toda la Industria IT. A modo de ejemplo, alguna de las
distribuciones de Linux mas extendidas (debian, Redhat), barajan
exactamente 187 y 100 vulnerabilidades de seguridad en lo que llevamos
de año 2003 (http://www.debian.org/security/2003/;
http://rhn.redhat.com/errata/rh73-errata-security.html ).Suponen
igualmente un mayor riesgo para dichos sistemas a partir del momento
de su publicación, no antes.

 - Si particularizamos en Microsoft, podemos poner un ejemplo reciente
con el virus Blaster: La vulnerabilidad que utilizó Blaster (026) ha
estado latente. El riesgo que ha supuesto durante esos años es mínimo,
prácticamente inexistente. ¿Cuando aumenta el riesgo? Cuando se
descubre y anuncia su existencia. De hecho, es solo 27 días después
cuando Blaster entra en escena. Técnicas de Ingeniería inversa sobre
el update publicado son en parte responsables de esta celeridad.


Si volvemos a pensar en el anuncio que hace Microsoft, tendremos mas
claro que no perdemos en materia de seguridad desde el momento que
asumimos que el riesgo es casi inexistente antes de cualquier tipo de
anuncio, y solo a partir de entonces, el riesgo es elevado.

En el entorno de una política de gestión de riesgos, esta medida
contribuye a minimizarlo, desde el momento en que se incrementa el
control sobre la planificación en el despliegue de la actualización de
seguridad.

Insisto en matizar que hablamos de retrasar unos días el anuncio, para
permitir la planificación.

Pero aun así, 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.

Por tanto, reitero que el objetivo de esta iniciativa es exclusivamente 
permitir la PLANIFICACIÓN, a cambio de ninguna perdida en seguridad.

Con la esperanza de contribuir a una información mas completa para los 
lectores de una-al-dia, recibid un cordial saludo

Héctor Sánchez Montenegro
Responsable de Seguridad Corporativa
Microsoft Ibérica
  

-- 
Best regards,
 softwarelibre                          mailto:softwarelibre en presidencia.gov.ar