Un CVSS de 9,8 llama la atención.
Y debe hacerlo.
La severidad técnica es una señal importante para comprender qué podría ocurrir si una vulnerabilidad es explotada. El problema aparece cuando esa señal se convierte automáticamente en una prioridad de negocio.
Una puntuación puede describir muy bien características del fallo y, al mismo tiempo, no conocer casi nada del entorno donde ese fallo existe.
Por eso, cuando veo una vulnerabilidad acompañada únicamente por un CVSS, mi siguiente pregunta suele ser:
¿Qué información todavía nos falta para decidir?
1. Falta saber qué activo está afectado
La misma vulnerabilidad puede cambiar radicalmente de importancia según dónde aparezca.
No es igual encontrarla en:
- un laboratorio aislado;
- un servidor de autenticación;
- una aplicación que procesa transacciones;
- un equipo administrativo;
- una plataforma que soporta una operación crítica;
- un sistema próximo a retirarse.
El CVSS no sabe qué representa ese activo para la organización.
Necesitamos entender su función, dependencia, propietario, información procesada y consecuencias de una posible interrupción o compromiso.
Sin esa información, priorizamos una debilidad técnica sin comprender el objeto que estamos protegiendo.
2. Falta saber quién puede alcanzarlo
La accesibilidad cambia el riesgo.
Un activo puede estar:
- expuesto directamente a Internet;
- detrás de una capa de autenticación;
- segmentado;
- disponible solo desde una red administrativa;
- accesible por terceros;
- conectado a una zona desde la cual sería posible avanzar hacia sistemas más sensibles.
Dos activos con la misma vulnerabilidad y el mismo CVSS pueden tener superficies de ataque completamente distintas.
Por eso la vulnerabilidad no debería analizarse separada de la exposición.
3. Falta saber si alguien está intentando explotarla
La severidad técnica expresa posibilidad.
La información de amenaza ayuda a entender probabilidad y urgencia.
Conviene saber, por ejemplo:
- si existe explotación conocida;
- si hay técnicas públicas o herramientas disponibles;
- si se observa actividad contra vulnerabilidades similares;
- si la vulnerabilidad está siendo utilizada en campañas reales;
- si existe evidencia relevante para el sector o entorno de la organización.
Esto no convierte la priorización en una predicción perfecta.
La amenaza es otra señal que debe combinarse con el contexto.
4. Falta saber qué controles existen alrededor
Una vulnerabilidad puede permanecer técnicamente presente y tener su exposición reducida temporalmente por otros controles.
Por ejemplo:
- segmentación;
- filtrado;
- autenticación adicional;
- restricciones de acceso;
- aislamiento;
- monitoreo;
- deshabilitación de una función vulnerable.
Pero hay una diferencia crítica entre tener un control y suponer que el control funciona.
Cuando un control compensatorio modifica una prioridad, debería existir evidencia suficiente para confiar en él.
De lo contrario, una falsa sensación de protección puede ser peor que reconocer la exposición.
5. Falta saber desde cuándo existe
El tiempo añade otra dimensión.
No es igual un hallazgo recién identificado que uno prioritario que lleva meses abierto sin una decisión clara.
La antigüedad puede revelar:
- bloqueos de remediación;
- sistemas que nadie quiere modificar;
- excepciones sin vencimiento;
- responsables poco claros;
- problemas recurrentes;
- o una diferencia entre lo que el tablero declara prioritario y lo que la organización realmente puede ejecutar.
El tiempo no transforma automáticamente una vulnerabilidad en crítica, pero sí puede mostrar deuda de riesgo acumulada.
6. Falta saber si existe una corrección viable
Una recomendación técnica puede ser correcta y operacionalmente difícil.
Aplicar un parche puede requerir:
- pruebas de compatibilidad;
- ventanas de mantenimiento;
- coordinación con proveedores;
- respaldo y plan de reversión;
- actualización de componentes dependientes;
- aprobación de un dueño de proceso.
También puede ocurrir que no exista todavía una corrección definitiva.
Entonces la decisión cambia: quizá sea necesario mitigar, aislar, monitorear, aceptar temporalmente el riesgo o acelerar un reemplazo.
La prioridad necesita reconocer la realidad de ejecución.
7. Falta saber qué ocurriría si el activo fuera comprometido
Este es el punto donde la conversación técnica debe conectarse con el negocio.
¿Qué podría verse afectado?
- disponibilidad de una función;
- integridad de información;
- confidencialidad de datos;
- capacidad de autenticación;
- operación de clientes;
- cumplimiento;
- capacidad de recuperación;
- confianza en un proceso.
Una vulnerabilidad adquiere significado de riesgo cuando podemos explicar una consecuencia plausible dentro de un contexto concreto.
8. Falta saber si estamos viendo datos confiables
Hay un supuesto que suele pasar desapercibido: que el hallazgo representa correctamente el estado actual del activo.
Antes de tomar decisiones conviene revisar:
- cuándo fue evaluado por última vez;
- si el análisis tenía el nivel de acceso necesario;
- si el activo sigue existiendo;
- si la dirección o nombre corresponden al sistema correcto;
- si la vulnerabilidad continúa presente;
- si los datos de inventario están actualizados.
Una priorización sofisticada construida sobre datos incompletos sigue siendo una mala priorización.
Del score al contexto
Cuando juntamos estas piezas, la pregunta deja de ser:
“¿Cuál tiene el CVSS más alto?”
Y se convierte en algo más útil:
“¿Qué combinación de debilidad, activo, exposición, amenaza, controles e impacto justifica atención primero?”
Esa pregunta no elimina el CVSS.
Lo coloca en su lugar correcto: una señal técnica dentro de una decisión más amplia.
No necesitamos un modelo perfecto
Existe el riesgo de responder a este problema creando modelos de puntuación excesivamente complejos.
Más variables no siempre producen mejores decisiones.
Un modelo útil debería ser suficientemente claro para que un equipo pueda explicar:
- por qué algo está primero;
- qué información modificó la prioridad;
- qué acción se espera;
- quién debe ejecutarla;
- qué ocurre si no puede hacerse ahora;
- y cuándo debe revisarse la decisión.
Si nadie puede explicar por qué un riesgo tiene determinado puntaje, el modelo puede convertirse en otra caja negra.
Una conclusión práctica
CVSS es valioso porque estandariza una parte de la conversación técnica.
Pero una organización no remedia puntuaciones.
Remedia problemas que existen en activos concretos, con una exposición concreta, dentro de procesos concretos y bajo restricciones concretas.
La información que falta entre el CVSS y la decisión es precisamente el contexto que convierte una vulnerabilidad técnica en una prioridad de riesgo.