Google siente la ira de Microsoft por la divulgación de vulnerabilidades

Microsoft ha señalado a Google por su decisión de revelar una falla antes de que Redmond lanzara una solución.

Chris Betz, director senior de Microsoft Trustworthy Computing, ha dicho que la compañía cree en la divulgación coordinada de vulnerabilidades y solicita que los investigadores divulguen de forma privada las vulnerabilidades a los proveedores de software, trabajando con ellos hasta que haya una solución disponible antes de compartir los detalles públicamente.

en un BlogBetz nombró a Google por el lanzamiento de una vulnerabilidad en un producto de Microsoft, dos días antes de su corrección planificada en su propio ciclo mensual. Al decir que esto se hizo «a pesar de nuestra solicitud de que eviten hacerlo», Betz dijo que Microsoft específicamente «le pidió a Google que trabajara con nosotros para proteger a los clientes reteniendo detalles hasta el martes 13 de enero».^th, cuando lanzaremos una solución ”.

Dijo: “Aunque seguir adelante se mantiene en el cronograma anunciado por Google para la divulgación, la decisión se siente menos como principios y más como una ‘trampa’, y los clientes son los que pueden sufrir como resultado. Lo que es adecuado para Google no siempre lo es para los clientes. Instamos a Google a que haga de la protección de los clientes nuestro principal objetivo colectivo «.

Dijo que quienes están a favor de la divulgación pública completa creen que este método empuja a los proveedores de software a corregir las vulnerabilidades más rápidamente y hace que los clientes desarrollen y tomen medidas para protegerse, pero no estuvo de acuerdo y dijo que la divulgación de información sin contexto o una ruta establecida para protecciones adicionales, presiona indebidamente un entorno técnico ya complicado.

“Es necesario evaluar completamente la vulnerabilidad potencial, diseñar y evaluar contra el panorama de amenazas más amplio, y emitir una ‘solución’ antes de que se divulgue al público, incluidos aquellos que usarían la vulnerabilidad para orquestar un ataque. Estamos en este último campo.

Betz reconoció que responder a las vulnerabilidades de seguridad puede ser un proceso complejo, extenso y que requiere mucho tiempo, y parte de la complejidad en la discusión del tiempo tiene sus raíces en la variedad de entornos que los profesionales de la seguridad deben considerar.

Dijo: “Para llegar a un lugar donde importantes estrategias de seguridad protejan a los clientes, debemos trabajar juntos. Apreciamos y reconocemos la colaboración positiva, el intercambio de información y la orientación a resultados en curso con muchos agentes de seguridad en la actualidad. Pedimos a los investigadores que revelen de forma privada las vulnerabilidades a los proveedores de software, trabajando con ellos hasta que haya una solución disponible antes de compartir cualquier detalle públicamente.

“Es en esa asociación donde los clientes se benefician más. Las políticas y enfoques que limitan o ignoran esa asociación no benefician a los investigadores, los proveedores de software ni a nuestros clientes. Es un juego de suma cero en el que todas las partes terminan lesionadas ”.

Comentando, Rob Graham de Errata Security dicho que es «agradable ver que Google le hace a Microsoft lo que Microsoft le hizo a todos los demás hace una década».

Dijo: “Disfruté leyendo la respuesta oficial de Microsoft a este evento, llena de retórica noble por qué Google es malo y por qué Microsoft debería tener más tiempo para corregir errores. Es solo un lloriqueo. Están molestos por su incapacidad para adaptarse y corregir errores de manera oportuna. Les molesta cómo Google explota su anuncio injusto.
ventaja. Dado que Microsoft no puede cambiar su desarrollo, intentan cambiar la opinión pública para obligar a Google a cambiar.

“Pero Google tiene razón. Dado que no podemos crear un software perfecto, debemos realizar arreglos rápidos y frecuentes como estándar. Nadie debería estar en el negocio de proporcionar software «seguro» que no pueda solucionar los errores rápidamente. En lugar de que 90 días sean demasiado cortos, en realidad son demasiado largos. Microsoft necesita avanzar con los tiempos y adoptar metodologías ‘ágiles’, o simplemente aceptar su papel de ordeñar el legado durante las próximas décadas como lo hace IBM con los mainframes ”.