A alto nivel, una organización debería aplicar los parches al mismo ritmo que el proveedor los publica. Por ejemplo, Microsoft tiene parche el martes el segundo martes de cada mes. Para cuando llegue el segundo martes del mes, ya debería estar todo completamente parcheado con los del mes anterior. Oracle lo hace trimestralmente.

Si bien este objetivo siempre parece "imposible", ¡se puede hacer! La priorización de vulnerabilidades se centra en las vulnerabilidades reales y urgentes que deben repararse en un plazo mucho más rápido que el "negocio habitual".

Esta publicación de Scythe de Jorge Orchilles cubre varios métodos para determinar cuáles de esas vulnerabilidades se incluyen en esta categoría de "parchear ahora":

• Common Vulnerability Scoring System (CVSS)
• Exploit Predictability Scoring System (EPSS)
• AttackerKB
• Otros sistemas de scoring

La puntuación base de CVSS se calcula al enviarse un nuevo CVE (Common Vulnerabilities and Exposures). Los CVE generalmente los crea el proveedor afectado y el proveedor que lanza el parche les asigna una puntuación base de CVSS. La mayoría de las veces, CVE, CVSS y el parche se lanzan al mismo tiempo.

Métricas

Como sugiere su nombre, CVSS es un sistema de puntuación, no un sistema de clasificación de riesgos. Se supone que los consumidores de CVE y CVSS deben calcular los puntajes temporales y ambientales de cada vulnerabilidad para tener una mejor métrica sobre qué parches priorizar.

El grupo de métricas Base representa las características intrínsecas de una vulnerabilidad que son constantes a lo largo del tiempo y en todos los entornos de usuario. El puntaje base por sí solo dará como resultado muchas vulnerabilidades de riesgo alto y crítico y no reflejará el riesgo contextual de su organización.

La métrica base se compone de dos conjuntos de métricas: las métricas de explotabilidad y las métricas de impacto.

• Las métricas de explotabilidad reflejan la facilidad y los medios técnicos con los que se puede explotar la vulnerabilidad. Es decir, es formalmente el componente vulnerable.
• Las métricas de impacto reflejan la consecuencia directa de un exploit exitoso y representan la consecuencia de lo que sufre el impacto, al que nos referimos formalmente como el componente impactado. Si bien el componente vulnerable suele ser una aplicación de software, un módulo, un controlador, etc. (o posiblemente un dispositivo de hardware), el componente afectado podría ser una aplicación de software, un dispositivo de hardware o un recurso de red.

Este potencial para medir el impacto de una vulnerabilidad que no sea el componente vulnerable, fue una característica clave introducida con CVSS v3.0.

El grupo de métricas Temporales refleja las características de una vulnerabilidad que puede cambiar con el tiempo, pero no en los entornos de usuario. Por ejemplo, la presencia de un kit de explotación fácil de usar aumentaría la puntuación de CVSS, mientras que la creación de un parche oficial la disminuiría.

El grupo de métricas Ambientales representa las características de una vulnerabilidad que son relevantes y únicas para el entorno de un usuario en particular. Es un modificador para un entorno único en función de la importancia del activo afectado. Las consideraciones incluyen la presencia de controles de seguridad que pueden mitigar algunas o todas las consecuencias de un ataque exitoso y la importancia relativa de un sistema vulnerable dentro de una infraestructura tecnológica.

¿Qué parches aplicar?

Una de las consideraciones subyacentes para priorizar qué parches aplicar es la explotabilidad (¿puede una amenaza aprovechar de manera significativa una vulnerabilidad?) que se cubre en la puntuación temporal de CVSS en Madurez del Código de Explotación. La puntuación temporal analiza tres métricas:

• Madurez del código de explotación (E): mide la probabilidad de que la vulnerabilidad sea utilizada y, por lo general, se basa en el estado actual de las técnicas de explotación, la disponibilidad del código de explotación o la explotación activa "in-the-wild".
• Nivel de corrección (RL): ¿hay un parche oficial, una solución alternativa, una solución temporal o no hay nada disponible?
• Informe de confianza (RC): ¿hay un informe confirmado o reproducción funcional, es razonable o se desconoce?

Si bien CVSS se utiliza para puntuar vulnerabilidades que tienen CVE, el sitio de MITRE no proporciona la puntuación CVSS. En su lugar, se puede usar la National Vulnerability Database (NVD) que tiene tanto el CVE como el CVSS. También tiene algunos análisis y más información sobre ciertas vulnerabilidades. 

Explotar el sistema de puntuación de predicción

Muchos proveedores han aplicado otras variables que ayudan a los defensores a priorizar si la vulnerabilidad es explotable:

• Está siendo explotado activamente: esto significa que el proveedor es consciente de que esta vulnerabilidad ya está siendo explotada y, por lo tanto, debe priorizarse.
• Fue revelada por un tercero: esto significa que un tercero ha revelado la vulnerabilidad al proveedor. Si bien esto puede no implicar que sea explotable, si un tercero lo encuentra, existe una alta probabilidad de que otro tercero también lo haga y pueda explotarlo.

El Exploit Prediction Scoring System (EPSS) comenzó como una investigación presentada en Blackhat 2019 y ahora es un grupo de trabajo oficial de FIRST. EPSS se diferencia de CVSS en que es un esfuerzo para predecir cuándo se explotarán las vulnerabilidades.

Al saber qué vulnerabilidades tienen una mayor probabilidad de ser explotadas, los consumidores pueden priorizar mejor qué vulnerabilidades corregir.

AttackerKB

Rapid7 tiene un proyecto comunitario llamado AttackerKB que ofrece comentarios de fuentes colectivas para ayudar a los consumidores a determinar qué vulnerabilidades priorizar. En este portal, el analista de seguridad puede proporcionar calificaciones y análisis basados en dos métricas:

• Valor del atacante: entre bajo y alto.
• Explotabilidad: entre lo difícil y lo fácil
• Con base en esas métricas, el analista puede elegir y etiquetar por qué la vulnerabilidad es de alto o bajo valor para un atacante.

Los analistas también tienen la capacidad de confirmar que la vulnerabilidad se explota activamente en la naturaleza. Por ejemplo, aquí hay análisis técnico de SMBGhost.

Otros sistemas de puntuación de proveedores

Muchos proveedores de gestión de vulnerabilidades tienen su propio marco de priorización o puntuación como parte de sus productos de análisis y gestión de vulnerabilidades:

• Rapid7’s insightVM Real Risk Prioritization
• Tenable Vulnerability Priority Rating

Mejores prácticas

Cada organización es diferente. Identificar, cuantificar y priorizar la gran cantidad de vulnerabilidades en su entorno es difícil pero se puede intentar el siguiente plan de trabajo:

• Elija un sistema de puntuación y cúmplalo
• Calcule puntajes temporales y ambientales en CVSS
• Sea consistente pero tenga espacio para hacer excepciones (Heartbleed es un gran ejemplo)
• Priorizar en función del riesgo real
• Considere la posibilidad de explotación calculando la puntuación temporal en CVSS o utilizando EPSS

Conclusión

Las organizaciones deben aplicar parches al mismo ritmo que los proveedores afectados lanzan parches. Se debe priorizar las vulnerabilidades que requieren más urgencia y que es el objetivo final de la gestión de vulnerabilidades, identificar y resolver las vulnerabilidades más críticas que enfrenta su organización. Las organizaciones pueden establecer prioridades calculando la puntuación ambiental y temporal de CVSS y/o aprovechando algunos de los proyectos más nuevos para la priorización de vulnerabilidades que se tratan en esta publicación.

Fuente: Scythe