Todo escaneo de vulnerabilidades termina igual: una lista larga, con decenas o cientos de hallazgos marcados como “Críticos” o “Altos”. El problema es que el equipo de TI tiene horas contadas, ventanas de mantención limitadas y un presupuesto finito. No se puede parchear todo a la vez, y fingir que sí lleva a corregir lo más fácil en lugar de lo más importante.
La pregunta correcta no es “¿qué es más grave?”, sino “¿qué corrijo primero para reducir más riesgo con lo que tengo?”.
Por qué ordenar solo por CVSS no alcanza
El puntaje CVSS mide la severidad técnica de una vulnerabilidad en abstracto: qué tan grave sería si alguien la explotara. Es un buen punto de partida, pero no responde tres preguntas clave:
- ¿Se está explotando realmente? Muchas vulnerabilidades con puntaje alto nunca llegan a ser atacadas en la práctica.
- ¿Está expuesto el activo? Una falla crítica en un servidor aislado de la red interna no pesa lo mismo que en un equipo publicado a Internet.
- ¿Qué pasa si cae ese activo? No es lo mismo el servidor de facturación que un computador de pruebas.
Si ordenas solo por CVSS, terminas con decenas de “10.0” empatados y sin criterio para decidir.
Las cuatro variables que usamos
En los informes del framework IKU-Risk™ combinamos cuatro dimensiones:
| Variable | Qué responde | Fuente |
|---|---|---|
| Severidad técnica | ¿Qué tan grave es la falla? | CVSS |
| Probabilidad de explotación | ¿Qué tan probable es que la ataquen en los próximos 30 días? | EPSS (FIRST) |
| Explotación confirmada | ¿Ya se está usando en ataques reales? | Catálogo KEV de CISA |
| Contexto del negocio | ¿Está expuesto? ¿Qué impacto tiene si cae? | Inventario de activos y entrevista con la empresa |
Una vulnerabilidad con CVSS medio, pero incluida en el catálogo KEV y presente en un equipo expuesto a Internet, casi siempre va antes que un “Crítico” teórico en un servidor interno sin acceso externo.
Un método simple en 5 pasos
- Arma o actualiza el inventario. Sin saber qué activos tienes, dónde están y qué hacen, cualquier priorización es una suposición.
- Filtra lo que ya se está explotando. Todo lo que aparece en el catálogo KEV y afecta a activos expuestos va primero, sin discusión.
- Ordena el resto por probabilidad × impacto. Usa EPSS como probabilidad y la criticidad del activo para el negocio como impacto.
- Agrupa por esfuerzo. Un solo parche o cambio de configuración puede cerrar muchos hallazgos a la vez. Esos “paquetes” rinden más por hora invertida.
- Define la capacidad real del ciclo. Si el equipo puede aplicar 15 correcciones este mes, el plan debe decir cuáles 15, no “todo lo crítico”.
De la teoría al modelo: Cyber-Prioritizer
Este razonamiento es la base de Cyber-Prioritizer, el motor de código abierto desarrollado en IKUBERT. Agrega un paso más: modela con Cadenas de Markov cómo evoluciona el riesgo de cada activo en el tiempo y elige el conjunto de parches que más riesgo elimina con el presupuesto disponible. En un inventario simulado, con el mismo presupuesto de 10 parches, redujo el riesgo dinámico en 30,4 % frente al 25,7 % del orden basado solo en CVSS.
Lo que debe tener un buen informe de vulnerabilidades
- Un orden de ejecución, no solo una lista de hallazgos.
- La razón de cada prioridad, en lenguaje que entienda la gerencia.
- Lo que no se va a corregir este ciclo, con el riesgo que eso implica y quién lo acepta.
- Una fecha de revisión: la priorización caduca, porque la amenaza cambia cada semana.
Si tu equipo tiene más hallazgos que horas disponibles, el problema no es técnico, es de priorización. Conversemos y te ayudamos a ordenar el backlog.