solo para hacer lio... microsoft y la seguridad
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:[email protected]
participants (1)
-
softwarelibre