Por/By: Lion Focus Insights
Durante mucho tiempo, una de las formas más prácticas de organizar la remediación de vulnerabilidades fue comenzar por las críticas, seguir con las altas y continuar bajando en la lista. Y no hay nada de malo en utilizar la severidad como punto de partida. Cuando existen cientos o miles de findings y es necesario establecer algún criterio, ofrece una referencia objetiva y fácil de entender.
El problema aparece cuando también se convierte en el punto de llegada.
Imaginemos una vulnerabilidad con CVSS 9.8 en un servidor interno, segmentado y sin acceso directo desde Internet. En otro entorno existe una vulnerabilidad 7.5 en una aplicación pública. Puede ser alcanzada externamente y, además, existen evidencias de explotación de esa vulnerabilidad en el mundo real.
Si hoy solo pudieras corregir una de las dos, ¿comenzarías necesariamente por la 9.8?
Probablemente necesitarías saber un poco más antes de responder.
Y es precisamente ese “saber un poco más” lo que hace interesante la priorización de vulnerabilidades.
El CVSS no está equivocado
A veces la discusión sobre priorización termina colocando al CVSS en el papel de villano, como si utilizar la severidad fuera una práctica obsoleta. No se trata de eso.
CVSS sigue siendo una referencia importante para representar de forma estandarizada las características técnicas de una vulnerabilidad. El vector de ataque, la complejidad, los privilegios necesarios, la interacción del usuario y los posibles impactos sobre confidencialidad, integridad y disponibilidad forman parte de esa evaluación.
Lo que no pretende hacer por sí solo es responder qué vulnerabilidad representa el mayor riesgo para una organización específica.
FIRST, responsable de CVSS, hace esta distinción con claridad al explicar que el CVSS Base Score mide severidad, no riesgo. El Base Score representa características intrínsecas de la vulnerabilidad, independientemente de las particularidades de cada entorno.
Puede parecer apenas una diferencia conceptual, pero en la práctica cambia bastante las cosas.
En análisis de vulnerabilidades es relativamente común encontrar situaciones en las que el finding con mayor CVSS no es necesariamente el que más llama nuestra atención. Una vulnerabilidad menos severa puede encontrarse en condiciones mucho más favorables para un atacante.
Entonces empiezan a aparecer otras preguntas.
¿El activo está expuesto? ¿La vulnerabilidad puede explotarse de forma remota? ¿Existen condiciones específicas para que la explotación funcione? ¿Hay exploit disponible? ¿Existen evidencias de ataques que utilicen esa vulnerabilidad?
No estamos descartando la severidad. Estamos agregando contexto a su alrededor.
Por eso, una forma útil de pensar la priorización es considerar tres dimensiones:
Severidad + Explotabilidad + Exposición
No como una fórmula universal capaz de calcular todo el riesgo de una organización, sino como tres informaciones que ayudan bastante a responder una pregunta mucho más práctica: ¿por dónde empezamos?
Algunas informaciones cambian bastante la fila
Volvamos a las dos vulnerabilidades del comienzo.
La primera tiene CVSS 9.8, pero está en un entorno interno y segmentado. La segunda tiene CVSS 7.5, está expuesta a Internet y descubrimos que existen evidencias de explotación activa.
La primera no dejó de ser crítica. Su CVSS tampoco necesita cambiar.
Pero ahora sabemos algo sobre la segunda que la severidad por sí sola no representaba.
Un ejemplo bastante claro de este tipo de información es el Known Exploited Vulnerabilities Catalog (KEV), mantenido por CISA. El catálogo reúne vulnerabilidades para las que existen evidencias de explotación en el mundo real, y CISA recomienda utilizarlo como una de las entradas para la priorización.
Esto no significa que todo lo que aparece en KEV deba pasar automáticamente por delante de cualquier otra vulnerabilidad. Tampoco significa que aquello que no aparece en el catálogo sea poco importante.
Pero, si estamos intentando decidir qué tratar primero, saber que una vulnerabilidad está siendo utilizada efectivamente por atacantes es una información difícil de ignorar.
También hay situaciones en las que no tenemos evidencia de explotación conocida, pero queremos entender mejor la posibilidad de que ocurra.
Es en ese espacio donde entra el EPSS (Exploit Prediction Scoring System). Mantenido por FIRST, estima la probabilidad de que una vulnerabilidad publicada sea explotada in the wild durante los próximos 30 días.
Es común encontrar discusiones que colocan CVSS y EPSS uno al lado del otro como si fuera necesario decidir cuál es mejor. Tal vez la pregunta esté mal planteada.
Nos dicen cosas diferentes.
Una vulnerabilidad puede tener severidad alta y una baja probabilidad estimada de explotación. Otra puede tener una severidad menor y presentar señales mucho más relevantes desde la perspectiva de amenaza.
Y todavía falta una información importante en esta historia: dónde está esa vulnerabilidad.
La misma vulnerabilidad, tres situaciones diferentes
Pensemos en la misma vulnerabilidad crítica presente en tres activos.
Uno es un servidor de laboratorio aislado. Otro está disponible únicamente en la red interna. El tercero es un servicio publicado directamente en Internet.
La vulnerabilidad es la misma. El CVSS es el mismo. Si observamos solamente una exportación del scanner, los tres findings pueden terminar prácticamente uno al lado del otro.
Sin embargo, para un atacante externo no son tres situaciones iguales.
Cuando analizamos una exposición, una de las primeras cosas que queremos entender es justamente si ese camino está disponible para un atacante. Un servicio publicado en Internet naturalmente merece un análisis diferente de algo que no puede alcanzarse de la misma manera.
Esto también muestra por qué la Gestión de Vulnerabilidades y la visibilidad de la superficie de ataque comienzan a encontrarse.
No basta con saber que una vulnerabilidad existe. Saber dónde existe y cómo está expuesto ese activo ayuda a entender mejor el escenario.
Y el contexto puede ir más allá.
Si sabemos que un activo soporta una operación crítica, contiene información sensible o cumple una función importante para el negocio, esa información puede influir en la decisión. Lo mismo ocurre con controles compensatorios que dificulten una explotación o reduzcan su posible impacto.
No siempre tendremos disponible toda esa información. En la realidad, muchas veces no la tendremos.
Y quizá ese sea otro punto importante: no necesitamos esperar a tener un modelo de riesgo perfecto para mejorar la priorización. Si hoy conseguimos combinar severidad con información sobre explotabilidad y exposición, ya contamos con mucho más contexto que una fila basada exclusivamente en CVSS.
A medida que la organización madura y logra incorporar criticidad de los activos, controles y posibles impactos para el negocio, el análisis puede ganar nuevas capas.
NIST aborda justamente esta relación entre riesgos de ciberseguridad, prioridades organizacionales y recursos disponibles. Al final, decidir prioridades también significa reconocer algo bastante concreto: ninguna organización tiene capacidad ilimitada para tratar todo al mismo tiempo.
El scanner terminó. Ahora comienza otra parte del trabajo.
Este quizá sea uno de los aspectos menos discutidos de la Gestión de Vulnerabilidades.
Encontrar vulnerabilidades se ha vuelto relativamente eficiente. Dependiendo del entorno, no es difícil producir una lista enorme.
El scanner termina y aparecen 500, 2.000, 10.000 findings.
¿Y ahora?
Si la respuesta es simplemente ordenar la planilla desde Critical hasta Low y enviarla a los responsables, todavía queda una parte considerable del problema.
Alguien tendrá que decidir qué hacer primero.
Es en ese momento cuando una vulnerabilidad 7.5 puede empezar a preocupar más que una 9.8. O cuando un finding que llevaba semanas en el backlog cambia de prioridad porque apareció un exploit. O porque entró en KEV. O simplemente porque alguien descubrió que aquel servidor que todos creían interno también responde desde Internet.
Situaciones como estas ayudan a entender que la prioridad no es una característica permanente de la vulnerabilidad.
El CVSS puede seguir exactamente igual mientras todo a su alrededor cambia.
Esta quizá sea una de las diferencias más importantes entre clasificar una vulnerabilidad y gestionar la exposición asociada a ella.
También existe un riesgo en el sentido contrario. Cuando empezamos a agregar contexto, resulta tentador buscar una nueva puntuación que resuelva definitivamente el problema: combinamos CVSS, EPSS, KEV, exposición, criticidad y algunas variables más, y esperamos que el resultado nos diga exactamente qué hacer.
Esos modelos pueden ser muy útiles. Pero todavía necesitan ser interpretados.
No existe una puntuación que conozca perfectamente cada arquitectura, cada control, cada dependencia y cada posible consecuencia para el negocio.
En algún momento, especialmente en los casos más relevantes, todavía será necesario analizar evidencias y tomar una decisión.
Y eso no es una deficiencia del proceso. Es parte de él.
Entonces, ¿qué debería venir primero?
Volvamos por última vez a nuestras vulnerabilidades 9.8 y 7.5.
Con la poca información que teníamos al comienzo, probablemente no sería responsable decidir mirando solamente los números.
Después descubrimos que la 7.5 está expuesta a Internet y tiene evidencias de explotación. Ahora tenemos motivos concretos para considerar tratarla primero.
Si mañana descubrimos que la 9.8 está en un activo crítico, puede alcanzarse por otro camino y forma parte de una cadena de ataque relevante, quizá la decisión vuelva a cambiar.
Así debería funcionar.
La Gestión de Vulnerabilidades no necesita abandonar la severidad. Solo necesita reconocer que representa una parte de la decisión.
Al final, cuando un equipo tiene miles de vulnerabilidades y capacidad para tratar solo una parte de ellas ahora, saber cuál tiene el CVSS más alto es útil.
Pero difícilmente será la única pregunta que el equipo querrá hacer.
Referencias
- FIRST — CVSS v4.0 User Guide
- CISA — Known Exploited Vulnerabilities Catalog
- FIRST — Exploit Prediction Scoring System (EPSS)
- NIST — Prioritizing Cybersecurity Risk for Enterprise Risk Management
Continúa explorando
- ¿Qué es la superficie de ataque y por qué cambia continuamente?
- ¿Qué es CTEM y cómo funciona Continuous Threat Exposure Management?
- ¿Qué es un vector de ataque? Entiende su relación con la superficie de ataque
¿Quieres llevar esta visión a tu superficie de ataque?
Conoce cómo Lion Focus ayuda a descubrir, monitorear, validar y priorizar exposiciones cibernéticas.
Leonnes Cybersecurity
Cyber Exposure Platform
