Cuando las bases de datos de vulnerabilidades ya no son suficientes
Los cambios introducidos por el NIST en el funcionamiento de la National Vulnerability Database (NVD) han modificado de forma significativa la manera en que las organizaciones interpretan las vulnerabilidades publicadas en este registro de referencia. En el pasado, la NVD proporcionaba información enriquecida sobre las vulnerabilidades, como puntuaciones CVSS, productos afectados, clasificaciones CWE y enlaces de referencia. Sin embargo, el NIST ha pasado a un modelo de priorización en el que ese nivel de detalle se reserva ahora para las vulnerabilidades de alta prioridad, concretamente aquellas incluidas en el catálogo KEV de la CISA, los fallos que afectan al software utilizado por el Gobierno federal de Estados Unidos o los relacionados con software crítico.
Este cambio responde al enorme aumento del volumen de vulnerabilidades y a las dificultades de la NVD para seguir el ritmo de las necesidades actuales. Sin embargo, esto no significa que las vulnerabilidades vayan a desaparecer de las bases de datos públicas. Lo que ocurrirá es que muchas de ellas contarán con menos contexto centralizado que ayude a los equipos a comprender su gravedad, los productos afectados o la urgencia de su corrección.
En consecuencia, las organizaciones ya no pueden depender únicamente de bases de datos externas o de puntuaciones genéricas para decidir qué vulnerabilidades corregir primero. Sobre el papel, una vulnerabilidad puede parecer prioritaria, pero en la práctica representar una amenaza limitada si afecta a un activo no crítico o bien protegido. Por el contrario, una vulnerabilidad con menor visibilidad puede requerir una respuesta más rápida si afecta a un sistema expuesto a Internet, es crítica para el negocio o presenta indicios de actividad sospechosa.
Para los MSP, esta complejidad se multiplica al gestionar clientes con infraestructuras, prioridades y niveles de exposición diferentes. Una misma vulnerabilidad puede ser urgente para un cliente con un servicio expuesto, pero tener una prioridad menor para otro en el que el activo no sea crítico o existan controles compensatorios implantados.
Cómo priorizar las vulnerabilidades en función del riesgo real
Cuando falta un análisis contextual externo, la priorización debe dejar de centrarse únicamente en la vulnerabilidad y pasar a basarse en el activo, su nivel de exposición y la actividad observada. Para ello, los equipos de seguridad y los MSP deben seguir un proceso claro:
1. Mantener actualizado el inventario de activos
El primer paso es saber exactamente qué sistemas tiene la organización, dónde se encuentran, qué función desempeñan, qué servicios soportan y cuál es su nivel de exposición. Sin esta base, cualquier proceso de toma de decisiones será incompleto.
2. Identificar qué vulnerabilidades afectan realmente a los sistemas
Es fundamental saber qué endpoints, servidores o aplicaciones requieren corrección, qué parches están disponibles y qué impacto podría tener su despliegue. Este paso permite pasar de una lista genérica de CVE a una visión concreta de qué sistemas requieren atención y qué medidas pueden aplicarse.
3. Evaluar la exposición real del activo
Una vulnerabilidad en un sistema aislado no tiene la misma urgencia que otra presente en un activo expuesto a Internet, en un sistema conectado a redes sensibles o en uno con servicios expuestos.
4. Correlacionar las vulnerabilidades con la telemetría de los endpoints
Si un sistema afectado presenta actividad anómala, intentos de explotación, ejecución de procesos sospechosos o indicadores de compromiso (IoC), esa vulnerabilidad debe escalarse en la cola de remediación.
5. Correlacionar la telemetría entre distintas capas
Combinar información sobre vulnerabilidades, activos, redes, endpoints, identidades y actividad observada permite responder a cuestiones operativas clave, como qué activo está afectado, cuál es su nivel de exposición y qué acciones pueden reducir en mayor medida el riesgo.
6. Determinar la acción adecuada en función del riesgo
Priorizar no significa necesariamente aplicar primero un parche. En algunos casos, desplegar una corrección será la medida adecuada. En otros, puede ser más conveniente aislar un dispositivo, bloquear conexiones, deshabilitar servicios expuestos, limitar accesos o reforzar la monitorización hasta que exista un parche oficial.
7. Verificar la mitigación del riesgo
No basta con cerrar un ticket o desplegar un parche. Es fundamental comprobar que el activo ya no aparece identificado como vulnerable, que se ha eliminado cualquier exposición innecesaria y que no persiste ninguna actividad sospechosa.
Cómo simplifica la priorización una plataforma de seguridad unificada
Una plataforma de seguridad unificada ayuda a simplificar la priorización al eliminar la necesidad de correlacionar manualmente datos procedentes de herramientas aisladas. En lugar de consultar el inventario en una herramienta y revisar por separado endpoints, redes, parches, alertas y controles de acceso en otras, integra la telemetría de las distintas capas en un único marco operativo. Esto permite a los equipos de seguridad y a los MSP conocer rápidamente qué activos están afectados, determinar su nivel de exposición, identificar cualquier actividad anómala asociada y saber qué vulnerabilidades requieren una actuación inmediata.
Además, permite que la priorización vaya más allá de una lista estática de vulnerabilidades pendientes y se traduzca en acciones concretas para mitigar el riesgo. La gestión de parches identifica y despliega las correcciones; la seguridad de endpoints aporta telemetría de comportamiento y capacidades de contención; la visibilidad de red permite detectar niveles de exposición, tráfico sospechoso y activos no gestionados; y la correlación XDR convierte eventos dispersos en incidentes priorizados.
Para los MSP, este marco también puede complementarse con servicios MDR que ayuden a reforzar la monitorización y el triaje de los activos más críticos en función de su nivel de vulnerabilidad, su impacto en el negocio y el contexto específico de cada entorno. De este modo, la priorización deja de depender únicamente de una alerta aislada o de una única puntuación y pasa a basarse en una comprensión más completa del riesgo. Esto permite a los MSP ofrecer a sus clientes capacidades avanzadas de detección y respuesta sin tener que desarrollarlas íntegramente desde cero con recursos internos. Este modelo puede reforzarse aún más mediante un agente de IA nativo de la plataforma, como Rai de WatchGuard. Operando en segundo plano, aprovecha la telemetría de la plataforma unificada para adoptar las acciones adecuadas en función del perfil de riesgo de cada activo.
Ante los recientes cambios introducidos por el NIST y la NVD, que reducen el nivel de análisis contextual externo disponible, resulta esencial construir un contexto propio. Para los equipos de seguridad y los MSP, disponer de una visión unificada ayuda a reducir el ruido, eliminar revisiones manuales innecesarias y centrar los esfuerzos en aquellas vulnerabilidades que realmente tienen un mayor impacto en cada entorno.