Microsoft divulga su criterio para la clasificación de vulnerabilidades en Windows

Microsoft divulga su criterio para la clasificación de vulnerabilidades en Windows

Por primera vez, Microsoft hace público el criterio para la clasificación de vulnerabilidades en Windows que emplea el Centro de Respuesta de Seguridad de Microsoft para determinar la prioridad de los fallos reportados.

Por primera vez, Microsoft hace público el criterio para la clasificación de vulnerabilidades en Windows que emplea el Centro de Respuesta de Seguridad de Microsoft para determinar la prioridad de los fallos reportados.

Por primera vez Microsoft hace público el criterio que emplea el Centro de Respuesta de Seguridad de Microsoft (MSRC, por sus siglas en inglés) para la clasificación de las vulnerabilidades reportadas en Windows. Esta información, compuesta por dos documentos, es de especial interés para los investigadores de seguridad, quienes a partir de ahora tendrán un panorama más claro de cuál podrá ser el tratamiento que tendrá un fallo reportado a Microsoft y si será considerado o no para la elaboración de un parche que solucione el error.

Al primero de los documentos se puede acceder ingresando al sitio “Microsoft Security Servicing Criteria for Windows”. Aquí se explica cuáles son las preguntas que el equipo de seguridad de Microsoft se realiza para determinar si es necesario la elaboración de un parche lo antes posible (a través de Patch Tuesday, que se realiza el segundo martes de cada mes) o si la resolución del bug será considerada para la próxima versión o lanzamiento de Windows y no para resolver mediante un parche.

Microsoft establece un criterio para delimitar los problemas de seguridad de la siguiente manera:.

Security boundaries

Es lo que Microsoft considera una violación a sus políticas de acceso a los datos. Por ejemplo, el reporte de una vulnerabilidad que permite a un usuario, sin permisos de administrador, ganar acceso al modo kernel y a los datos, siempre se considerará una violación a los límites de seguridad, explica ZDnet. Para ello, la compañía utiliza una lista compuesta por nueve security boundaries que se pueden ver detalladas en el documento y que incluye, entre otros, áreas como redes, kernel, etc.

Security features

Por security features se refiere a errores reportados en aplicaciones y otras funciones del sistema operativo creadas para fortalecer estas funcionalidades de seguridad, como fallos en BitLocker, Windows Fedender, Secure Boot, entre otras.

Defense-in-depth security features

Esta tercera categoría se refiere a funcionalidades de seguridad que por sus propias limitaciones no se considera que tengan el mismo nivel de robustez de las anteriores, sino que aportan funcionalidades complementarias de seguridad. En este sentido, la desactivación de algunas de estas funcionalidades de seguridad que entran en esta categoría no suponen un riesgo directo debido a que para eso un atacante deberá encontrar una vulnerabilidad en una security boundaries para efectivamente lograr una primera fase de compromiso. Por lo tanto, las vulnerabilidades que afecten a estas funcionalidades difícilmente sean consideradas en los parches que se lanzan cada mes, sino más bien se tendrán en cuenta para próximos lanzamientos de los productos. En el documento completo se puede ver cuáles son las funcionalidades de seguridad consideradas en esta categoría.

El segundo documento que lanzó Microsoft se titula Microsoft Vulnerability Severity Classification for Windows y describe cómo la compañía asigna un ranking de acuerdo a la severidad de cada error reportado. En este sentido, este segundo documento explica cuáles son los bugs considerados “críticos”, “importantes”, “moderados” y de “bajo riesgo”.

El objetivo de Microsoft con la divulgación de los criterios que emplea para la clasificación y asignación de prioridades a las vulnerabilidades reportadas pretende aportar transparencia y que los investigadores puedan tener más claro qué pueden esperar de Microsoft al momento de detectar una vulnerabilidad a reportar.

Estos documentos fueron lanzados en junio como borrador y recibieron una devolución de la comunidad de investigadores y de la industria en general que permitieron hacer unos ajustes más previo a su lanzamiento la semana pasada.

Discusión