Mike Nash habla de la vulnerabilidad WMF

nash

Cuando alguien con un título tan «jugoso» como el de Corporate Vice President responsible for Security at Microsoft habla, qué menos que escuchar a ver que opina, sobre todo de un asunto tan lamentable como el vivido con el problema de los Windows Meta Files.

El señor Nash de se ha dejado caer por ese blog llamado Microsoft Security Response Center o MSRC y ha dejado declaraciones sobre el asunto. Concretamente ha hablado de 3 puntos, que paso a detallar.

1. Customers hate it when we ship updates to our software in general. Ideally we address these kinds of issues before we ship our products. That is what the Trustworthy Computing initiative and the Security Development Lifecycle (SDL) are all about.

«Los usuarios odian que les entreguemos actualizaciones de nuestro software en general. Teóricamente, los problemas los resolvemos antes de entregar los productos. Ese es el propósito de la Trustworthy Computing y el SDL»

2. If there is one thing we have done right in the last 2 years, it’s our move to monthly updates. Having a predictable schedule makes it easier for customers to plan and when you can plan, it puts less stress on the customers’ infrastructure and their people and the results are better.

«Si hay algo bueno que hayamos hecho en los últimos dos años, eso es decantarnos por las actualizaciones mensuales. Las agendas conocidas permiten planificar, y trasladan menos tensión a la infraestructura de los clientes, siendo los resultados mejores»

3. The only thing worse than having to deploy an update is having to deploy that same update twice because of a quality problem with the update. As a result, we have made some extensive revisions to the way we test our updates. Our basic philosophy is that the current version of any of our products is the latest version we shipped PLUS the latest service pack PLUS the set of updates we have shipped since the last service pack. That product needs to be tested. Can we test updates as extensively as the original product or service pack? Probably not given the need to be responsive, but if we are thoughtful we can focus our testing on the code paths and scenarios that matter the most and get great results.

«Lo único peor a la hora de desplegar una actualización es tener que hacerlo dos veces por falta de calidad en la primera actualización. Hemos efectuado rigurosas revisiones al proceso de prueba de las actualizaciones. Nuestra filosofía es que la versión actual de cualquiera de nuestros productos es la última versión comercializada MAS el último service pack MAS el último juego de actualizaciones desde el último service pack [.. sigue..]»

Es decir, según las teorías del señor Nash, recordemos, Vicepresidente Corporativo de Seguridad de Microsoft, es decir, probablemente el número 2 a nivel mundial en cuanto a seguridad de Microsoft, esto es el camino a seguir en la política de seguridad en plataformas Windows. Yo me permito hacer algún comentario:

1. Según Nash, a los usuarios de plataformas Windows no les gusta tener actualizaciones. Lo odian. Por eso mismo estaba hace una semana medio planeta clamando al cielo por un parche, señor Nash. Por mucho SDL que aplique y por mucho Trustworthy que pretendan, el usuario no es tan ignorante como aparenta y cuando sabe que está vendido porque su Trustworthy ha fracasado, usted lo que tiene que hacer es arreglar sus problemas. Y sin rechistar.

2. La estrategia de entregar actualizaciones 1 vez al mes es un error. Es un error porque los problemas cuando se generan, hay que arreglarlos inmediatamente, o en el peor de los casos, dar la posibilidad de solucionarlo inmediatamente. No sé Usted, pero si a mí si un cliente me detecta un problema hoy en un producto que le comercializo, no puedo emplazarle al mes siguiente para darle soluciones. Los problemas requieren acción inmediata. Cualquier filosofía de Gestión de Calidad coloca al cliente en el centro de los procesos, si bien parece que la suya lo coloca al final. «Venga usted el mes que viene».

3. Para corregir un problema masivo como el de WMF no hace falta estar un mes haciendo pruebas. Hace falta pensar. Es obvio que piensen en la calidad de lo que despliegan (yo diría más bien que piensan en que si sacáis un parche y ese parche da problemas, se os tirarán a la yugular como lobos), pero para corregir un problema como el acontecido desde luego que no hay que estar 15 días pensando y probando. Revise el código de Ilfak Guilfanov si no me cree. Eso se hace en pocas horas. Y a las pruebas me remito.

Señor Nash: La próxima vez salga a la palestra cuando sus clientes demanden masivamente soluciones por estar con el agua al cuello. Salir después para decir estas cosas no nos ayuda en nada. Los usuarios no somos tan ignorantes como antes, tenemos blogs, foros y servicios informativos, que no son los suyos, para documentarnos sobre qué está pasando y para que después de la tempestad, reconozcamos que palabras como las suyas son sólo un inefectivo bálsamo que no aporta nada sobre el problema que hemos sufrido.

Al ruedo hay que salir cuando el toro nos tiene acorralados, no cuando lo arrastran fuera de la plaza.

Un pensamiento en “Mike Nash habla de la vulnerabilidad WMF

  1. Pingback: meneame.net

Comentarios cerrados.