Priorización y CVSS: El Triage en Urgencias

Objetivo de esta Guía

Aprender que en el mundo corporativo no existe el tiempo ni el dinero para arreglar todos los errores de seguridad. Tu trabajo no es arreglar todo; tu trabajo es decidir que dejar sangrar y que meter inmediatamente al quirófano.

El escáner de red (Nessus) terminó su trabajo y te entregó un reporte en PDF de 5,000 páginas diciendo que tienes 14,500 vulnerabilidades. Si le envías ese PDF al equipo de administradores de sistemas, te van a odiar, lo van a tirar a la basura, y no van a arreglar nada. Necesitas hacer Triage.

Esta guía cubre el sistema CVSS, las métricas que lo componen, como interpretarlo, y como combinarlo con el contexto de negocio para tomar decisiones de priorización efectivas. No se trata solo de saber el número. Se trata de entender que significa ese número en tu realidad.

La Analogía: La Sala de Emergencias (Triage)

Imagínate que eres el jefe de enfermeros en la Sala de Emergencias de un hospital militar durante una guerra. Acaban de llegar 14,500 pacientes al mismo tiempo. Solo tienes 10 doctores (programadores).

Sin Triage: Los doctores empiezan a atender alfabéticamente a los pacientes. Pasan 5 horas curando las rodillas raspadas de 100 soldados, mientras que los pacientes con heridas de bala en el pecho se mueren en la sala de espera.

Con Triage: Tu te pones en la puerta. Tomas decisiones rápidas, brutales y matemáticas. Le pones una etiqueta verde al de la rodilla raspada (Vete a casa, no es urgente) y una etiqueta roja al de la bala en el pecho (Directo a quirófano).

En Ciberseguridad, esa etiqueta médica de colores se llama CVSS.

Pero hay una diferencia crucial con la medicina: en un hospital, una herida de bala siempre es más urgente que una rodilla raspada. En ciberseguridad, una vulnerabilidad con puntuación 9.8 (crítica) en un servidor interno aislado puede ser menos urgente que una vulnerabilidad 6.5 (media) en un servidor web público.

El contexto lo cambia todo.

Recordando el CVSS

CVSS (Common Vulnerability Scoring System) es un estándar abierto de FIRST que comunica la severidad técnica de una vulnerabilidad mediante métricas reproducibles. Su resultado va de 0.0 a 10.0, pero no representa por sí solo el riesgo de una organización.

Las Categorías de Severidad

Crítico (9.0 - 10.0): Etiqueta Roja. El atacante no necesita contraseña (Unauthenticated), el ataque se hace desde internet (Network), y le da control total sobre la máquina (Remote Code Execution - RCE).

Alto (7.0 - 8.9): Etiqueta Naranja. La vulnerabilidad es grave pero requiere algún privilegio o condición especial.

Medio (4.0 - 6.9): Etiqueta Amarilla. El atacante necesita estar físicamente en la oficina, o necesita tener ya una cuenta de usuario normal, o el impacto es limitado.

Bajo (0.1 - 3.9): Etiqueta Verde. "La página web revela que usa la versión 1.2 de JQuery". Información útil pero no crítica.

Ninguno (0.0): Sin riesgo medible.

La Trampa del Escáner

Un 10 en CVSS suena aterrador, pero si ese servidor no esta conectado a nada, es un 10 en el aire.

El error número uno de un Analista de Vulnerabilidades novato es abrir la consola de Nessus, ordenar la lista por "Críticos" y mandarle un correo de pánico al Administrador de Sistemas.

El CVSS Base es ciego. El escáner Nessus te dirá que la computadora de la Recepcionista tiene un error CVSS 9.8 (Crítico). Matemáticamente es cierto, el error es grave. Pero al negocio no le importa porque:

• La computadora de la recepcionista no tiene acceso a datos sensibles
• No esta conectada a internet
• No forma parte de ningún proceso crítico
• La recepcionista no tiene privilegios de administrador

El CVSS por si solo no es suficiente para priorizar. Necesitas contexto.

Las Métricas de CVSS 4.0

CVSS 4.0, vigente en 2026, organiza las métricas en cuatro grupos. El estándar distingue además qué combinación se está comunicando: CVSS-B para Base, CVSS-BT para Base más Amenaza, CVSS-BE para Base más Entorno y CVSS-BTE cuando se incluyen los tres grupos que modifican el resultado.

Métricas Base

Describen características intrínsecas de la vulnerabilidad:

• Attack Vector (AV): red, adyacente, local o físico.
• Attack Complexity (AC): condiciones técnicas fuera del control del atacante.
• Attack Requirements (AT): condiciones previas específicas del despliegue que deben existir.
• Privileges Required (PR): privilegios necesarios antes del ataque.
• User Interaction (UI): ninguna, pasiva o activa.
• VC, VI y VA: impacto en confidencialidad, integridad y disponibilidad del sistema vulnerable.
• SC, SI y SA: impacto en confidencialidad, integridad y disponibilidad de sistemas posteriores.

CVSS 4.0 retiró la métrica Scope de CVSS 3.1 y separó explícitamente el impacto sobre el sistema vulnerable y los sistemas posteriores.

Métricas de Amenaza

El grupo Threat refleja información que puede cambiar con el tiempo. CVSS 4.0 conserva Exploit Maturity (E) para indicar la madurez de la explotación conocida. Las antiguas métricas Remediation Level y Report Confidence fueron retiradas.

Métricas de Entorno

Permiten adaptar la severidad al entorno concreto:

• Requisitos de confidencialidad, integridad y disponibilidad del activo.
• Versiones modificadas de las métricas Base cuando el despliegue cambia sus condiciones reales.

Estas métricas son preferibles a modificar mentalmente el resultado: documentan de forma reproducible por qué una organización obtiene una valoración distinta.

Métricas Suplementarias

Añaden contexto sin modificar la puntuación final. Incluyen Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort y Provider Urgency.

Qué cambió frente a CVSS 3.1

CVSS 4.0 incorporó Attack Requirements, refinó User Interaction, reemplazó Scope por impactos separados, renombró Temporal como Threat y añadió métricas suplementarias. Los vectores 3.1 siguen apareciendo en bases históricas, por lo que conviene identificar siempre la versión junto al valor.

El Contexto de Negocio (Business Context)

Un buen analista no altera mentalmente la puntuación. Registra por separado la severidad CVSS, la amenaza observada, la exposición, el valor del activo y los controles compensatorios. Cuando corresponda, utiliza las métricas de Entorno de CVSS 4.0.

Escenario A (CVSS 9.8 en el Sótano)

Nessus marca un error "Crítico 9.8" en el servidor de pruebas de los desarrolladores.

El Contexto: Ese servidor de pruebas no tiene datos de clientes, y más importante, no tiene salida a internet. Un hacker en Rusia jamás podría llegar físicamente a esa computadora porque el firewall interno lo bloquea.

Prioridad Real: Baja. "Arréglalo cuando tengas tiempo".

Escenario B (CVSS 6.5 en la Corona)

Nessus marca un error "Medio 6.5" en el servidor principal de transferencias del Banco. El error permite robar dinero si el hacker logra engañar a un empleado.

El Contexto: Ese servidor esta conectado a internet público y guarda millones de dólares en transacciones.

Prioridad Real: Crítica Inmediata. "Levanten a los programadores, arréglenlo hoy".

La Regla de Oro

Vulnerabilidad Matemática (CVSS) + Riesgo de Negocio (Contexto) = Prioridad Real.

Factores de Contexto a Considerar

Exposición: El activo esta expuesto a internet? Tiene firewalls? WAF? Segmentación?

Valor del Activo: Que datos maneja? Información personal? Datos financieros? Secretos industriales? Que impacto tendría su compromiso para el negocio?

Criticidad del Servicio: Que pasa si este servicio deja de funcionar? Es crítico para las operaciones? Tiene respaldo?

Facilidad de Explotación: Existe un exploit público? Es fácil de usar? Hay exploits en metasploit?

Actividad de Amenazas: Se esta explotando activamente esta vulnerabilidad en la naturaleza? Hay reportes de grupos de ransomware usandola?

Dependencias: Otros sistemas dependen de este? Comprometerlo permitiria moverse lateralmente a sistemas más críticos?

Priorización Basada en Riesgo

La priorización basada en riesgo combina CVSS con contexto para generar una puntuación de riesgo real.

Modelos de Priorización

CVSS Puro: Usar el CVSS base sin modificaciones. Simple pero peligroso.

CVSS + Contexto Manual: El analista ajusta manualmente la puntuación según el contexto. Requiere conocimiento del negocio y los activos.

CVSS + EPSS: EPSS (Exploit Prediction Scoring System) es un modelo que predice la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días, basado en datos historicos y análisis de amenazas. Combinar CVSS con EPSS da una mejor priorización.

CVSS + EPSS + Contexto: El modelo más completo. Combina severidad (CVSS), probabilidad de explotación (EPSS), y contexto de negocio.

EPSS en Detalle

El Exploit Prediction Scoring System (EPSS) es desarrollado por el FIRST (el mismo que mantiene CVSS). Usa machine learning para predecir la probabilidad de explotación.

Puntuación EPSS: Del 0% al 100%. Indica la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días.

Ejemplo: Una vulnerabilidad puede tener CVSS 9.8 (crítico) pero EPSS 0.1% (baja probabilidad de explotación). Otra puede tener CVSS 6.5 (medio) pero EPSS 95% (altamente probable que sea explotada).

En el segundo caso, aunque la severidad técnica es menor, el riesgo real es mayor porque los atacantes ya están explotando activamente la vulnerabilidad.

Frameworks de Priorización

SSVC (Stakeholder-Specific Vulnerability Categorization): Desarrollado por Carnegie Mellon y CISA. En lugar de números, usa arboles de decisión para categorizar vulnerabilidades según:

• Explotabilidad: Existe exploit? Es funcional?
• Impacto Técnico: Que tan grave es el impacto?
• Misión: Que tan crítico es el activo para la misión de la organización?

Resultado: Categorías como "Inmediato", "Programado", "Seguimiento", "Información".

Esta aproximacion es más práctica que el CVSS puro porque fuerza al analista a considerar el contexto.

El Problema de la Fatiga de Alertas

Cuando todas las vulnerabilidades son "críticas" (CVSS 9+), ninguna lo es. La fatiga de alertas ocurre cuando:

• El escáner reporta demasiadas vulnerabilidades críticas
• El equipo no puede parchearlas todas
• Empiezan a ignorar las alertas
• Una vulnerabilidad realmente crítica se pierde en el ruido

La solución no es bajar el número de alertas, sino mejorar la priorización. No todas las vulnerabilidades críticas merecen la misma atención.

Caso Práctico: CVE-2021-44228 (Log4Shell)

En diciembre de 2021, se descubrió Log4Shell (CVE-2021-44228), una vulnerabilidad en la biblioteca de logging Log4j de Apache.

CVSS Base: 10.0 (Crítico máximo). Vector de ataque: Network. Complejidad: Baja. Privilegios: Ninguno. Impacto: Alto en C, I, A. No requiere interacción del usuario.

Contexto: Log4j es una biblioteca omnipresente en aplicaciones Java. Millones de servidores la usan. El exploit es público y trivial de ejecutar.

EPSS: 97.8% (casi certeza de explotación).

Priorización: Inmediata. No importa donde este el servidor, si usa Log4j, debe parchearse.

Este caso demuestra cuando todas las métricas apuntan a urgencia máxima. Pero incluso dentro de Log4Shell, la priorización variaba según el contexto:

• Servidor web público con Log4j: Parche inmediato (minutos/horas)
• Servidor interno sin internet con Log4j: Parche urgente (horas/días)
• Dispositivo IoT con Log4j (si el fabricante no provee parche): Aceptación del riesgo o aislamiento

Automatización de la Priorización

La priorización manual no escala cuando tienes miles de vulnerabilidades.

Herramientas de Priorización

VMDR (Qualys Vulnerability Management, Detection, and Response): Integra CVSS, EPSS, y Threat Intelligence para priorizar automáticamente.

Tenable.io / Tenable.sc: Incluye modelos de priorización basados en contexto y threat intelligence.

RiskSense: Plataforma dedicada a priorización de vulnerabilidades usando múltiples fuentes de datos.

Kenna Security (ahora Cisco): Usa modelos predictivos para priorizar basándose en probabilidad de explotación.

Automatización y Falsos Positivos

La automatización puede exacerbar el problema de falsos positivos si no se configura correctamente.

Un escáner automático puede reportar una vulnerabilidad que no existe (falso positivo). Si el sistema de priorización automática la marca como crítica, el equipo pierde tiempo investigando y parcheando algo que no es real.

Por eso, los resultados del escaneo deben pasar por un proceso de validación antes de entrar al sistema de priorización. La validación puede ser manual o semi-automatizada.

Formas de Falla

Los errores más comunes en priorización:

Priorizar solo por CVSS: Ignorar el contexto de negocio y el riesgo real. Parcheas vulnerabilidades críticas en sistemas de prueba mientras ignoras vulnerabilidades medias en sistemas críticos.

No considerar la explotabilidad: Una vulnerabilidad con CVSS 9.8 pero sin exploit público puede ser menos urgente que una con CVSS 7.5 que ya esta siendo explotada activamente.

Fatiga de prioridades: Cuando todo es urgente, nada lo es. Si marcas todas las vulnerabilidades como "críticas", el equipo dejará de tomar las alertas en serio.

Procesos manuales: Depender solo del criterio humano para priorizar miles de vulnerabilidades es insostenible. La automatización es necesaria.

No re-evaluar prioridades: Las vulnerabilidades cambian con el tiempo. Lo que hoy es una vulnerabilidad sin exploit, mañana puede tener un exploit funcional. Un análisis de prioridades estático se vuelve obsoleto rápidamente.

Ignorar la causa raíz: Priorizar vulnerabilidades individuales sin abordar la causa raíz (falta de proceso de desarrollo seguro, falta de actualizaciones automáticas, falta de capacitación) lleva a parchar la misma vulnerabilidad una y otra vez.

Falta de comunicación: El equipo de seguridad prioriza una vulnerabilidad, pero el equipo de IT tiene sus propias prioridades. Sin comunicación y alineacion, la priorización no se traduce en acción.

El Riesgo de No Priorizar

No priorizar tiene consecuencias directas:

• Sobrecarga del equipo de IT: Reciben listas interminables de vulnerabilidades sin orden de importancia. Se abruman y dejan de parchear.
• Vulnerabilidades críticas ignoradas: Entre el ruido de miles de vulnerabilidades bajas, las críticas se pierden.
• Pérdida de credibilidad del equipo de seguridad: Si cada alerta es "crítica", el equipo de IT deja de confiar en las evaluaciones de seguridad.
• Incidentes evitables: Vulnerabilidades conocidas y parcheables que no se priorizaron correctamente llevan a brechas de seguridad.

El Ángulo del Hacker

Para el atacante, la priorización de vulnerabilidades es irrelevante. El solo necesita una vulnerabilidad para entrar.

El Atacante También Prioriza

Los atacantes también priorizan, pero de manera diferente:

• Que vulnerabilidades tienen exploits públicos y funcionales?
• Que vulnerabilidades están en sistemas expuestos a internet?
• Que vulnerabilidades son fáciles de explotar (no requieren habilidades avanzadas)?
• Que vulnerabilidades tienen mayor probabilidad de éxito (bajo riesgo de detección)?
• Que vulnerabilidades permiten movimiento lateral o escalada de privilegios?

Los atacantes buscan el camino de menor resistencia. No van a gastar un exploit de día cero si pueden entrar por una vulnerabilidad conocida y sin parchear.

La Ventana de Oportunidad del Atacante

Desde la perspectiva del atacante, el tiempo es crítico:

Día 0: Se publica una vulnerabilidad. Días 0-2: Los investigadores crean un exploit de prueba de concepto. Días 2-7: Los atacantes integran el exploit en sus herramientas. Días 7-30: Los atacantes escanean internet en busca de sistemas vulnerables. Días 30+: Los sistemas que no se parchearon en el primer mes son objetivos.

Si el equipo de seguridad prioriza correctamente y parcha en los primeros 7 días, cierra la ventana antes de que los atacantes puedan actuar.

Vulnerabilidades Favoritas de los Atacantes

Los atacantes tienen vulnerabilidades favoritas que explotan consistentemente:

• EternalBlue (MS17-010): Usado por WannaCry y otros ransomware.
• BlueKeep (CVE-2019-0708): RDP, wormable.
• ProxyLogon/ProxyShell (CVE-2021-26855, etc.): Exchange Server.
• Log4Shell (CVE-2021-44228): Log4j.
• Follina (CVE-2022-30190): Microsoft Office.

Estas vulnerabilidades comparten características: son fáciles de explotar, tienen exploits públicos, y afectan a software omnipresente.

Construyendo un Proceso de Priorización

Paso 1: Recibir Resultados del Escaneo

El escáner produce una lista de vulnerabilidades con CVSS, descripción, y sistemas afectados.

Paso 2: Enriquecer con Contexto

Para cada vulnerabilidad, agregar:

• Exposición del activo (internet, interno, aislado)
• Valor del activo (datos, criticidad del servicio)
• Disponibilidad de exploit (EPSS, threat intelligence)
• Existencia de controles compensatorios

Paso 3: Asignar Prioridad Real

Usando un framework como SSVC o una matriz personalizada:

Exposición	CVSS	EPSS	Prioridad
Internet	Crítico	Alto	Inmediata
Internet	Alto	Alto	Urgente
Internet	Medio	Alto	Alta
Interno	Crítico	Alto	Alta
Interno	Alto	Bajo	Media
Aislado	Crítico	Bajo	Baja

Paso 4: Asignar Responsable

Cada vulnerabilidad debe tener un dueño responsable de su remediación. Sin un responsable claro, las vulnerabilidades quedan sin parchear.

Paso 5: Monitorear y Re-evaluar

Las prioridades cambian. Una vulnerabilidad que hoy no tiene exploit, mañana puede tenerlo. El proceso debe incluir re-evaluación periódica.

Autoevaluación

Revisa si podrías dirigir la sala de emergencias:

1. Por qué enviar un reporte crudo de 5,000 páginas de Nessus directamente al equipo de Servidores (IT Operations) se considera una falta de respeto profesional y una falla en el proceso de Gestión de Vulnerabilidades?

2. Dos servidores tienen exactamente el mismo fallo técnico con una puntuación matemática (CVSS Base) de 9.8. El Servidor A maneja el aire acondicionado del edificio (y no tiene internet). El Servidor B maneja la pasarela de pagos de la página web pública. Por qué las prioridades de parcheo son completamente opuestas?

3. Un atacante necesita primero tener una cuenta valida en tu sistema (Usuario/Contraseña) para poder ejecutar un fallo que destruye la base de datos. En la métrica de CVSS, este ataque requiere privilegios ("Privileges Required: High"). Por qué esto baja la puntuación de la vulnerabilidad comparado con un ataque que no requiere contraseña?

4. El proceso de Triage es mentalmente duro. Tienes un tiempo limitado de tus ingenieros para arreglar fallos este mes. Tienes 50 vulnerabilidades "Bajas" (Verdes) y 1 vulnerabilidad "Alta" (Naranja). A cual le asignas los recursos y por qué?

5. Explica la diferencia entre los grupos Base, Threat, Environmental y Supplemental de CVSS 4.0. ¿Qué combinación comunica mejor la situación real de una organización?

6. Que es EPSS y como complementa al CVSS en la priorización de vulnerabilidades?

7. Una vulnerabilidad tiene CVSS 9.8 pero EPSS 0.5% (baja probabilidad de explotación). Otra tiene CVSS 6.5 pero EPSS 95% (alta probabilidad de explotación). Cual deberías parchear primero y por qué?

8. Tu escáner de vulnerabilidades reporta la misma vulnerabilidad crítica hipotética en 50 servidores. Como determinas cuáles parchear primero si no puedes parchearlos todos simultáneamente?

9. Explica el concepto de "fatiga de prioridades" y como afecta la efectividad de un programa de Vulnerability Management.

10. En el contexto del framework SSVC, explica por qué dos organizaciones diferentes pueden priorizar la misma vulnerabilidad de manera diferente.