Muchas organizaciones han adoptado la gestión de vulnerabilidades basada en el riesgo como un componente fundamental de su programa de ciberseguridad, y han ido más allá de la clasificación basada únicamente en el CVSS para crear marcos de priorización e invertir en fuentes de inteligencia sobre ciberamenazas , escáneres y flujos de trabajo para la corrección de vulnerabilidades . Sin embargo, las colas de correcciones suelen seguir siendo inmanejables, las puntuaciones de riesgo tienen dificultades para ganarse la confianza de los equipos de operaciones de TI y los equipos siguen teniendo dificultades para demostrar a la dirección una reducción cuantificable del riesgo.
En este artículo se explica paso a paso cómo subsanar cada una de las deficiencias, desde la infraestructura de cobertura hasta los modelos de puntuación, pasando por la coordinación entre equipos y los indicadores clave de rendimiento (KPI) que demuestran que su programa está reduciendo el riesgo, de modo que su equipo pueda mantenerse al día frente a las amenazas a las que se enfrenta su organización en la actualidad.
Por qué la mayoría de los programas de RBVM se estancan antes de alcanzar una mayor escala
Las organizaciones que están pasando de enfoques tradicionales de gestión de vulnerabilidades y de gestión de riesgos suelen arrastrar las mismas deficiencias que el modelo RBVM fue diseñado para superar: visibilidad incompleta de los activos, resultados de escáneres no validados y traspasos poco claros entre los equipos de seguridad y de operaciones de TI. Sin embargo, la mayoría de los equipos consideran que comprender los principios de la priorización basada en el riesgo es la parte más fácil. Es precisamente al aplicarlas de forma coherente en entornos empresariales donde surgen retos adicionales.
El concepto es sencillo. Es en la ejecución donde los programas fallan.
Tres deficiencias en las infraestructuras explican la mayoría de los fallos del RBVM:
- Visibilidad incompleta de los activos de : Las puntuaciones de riesgo calculadas a partir de datos parciales sobre vulnerabilidades dan lugar a una protección parcial. Si los terminales no están gestionados, no se han sometido a análisis o proporcionan datos obsoletos, la cola de riesgos presenta un punto ciego que ningún modelo de priorización puede subsanar.
- Resultados no validados del escáner: Los resultados del escáner no equivalen a una exposición confirmada. En entornos con datos de análisis obsoletos o una gestión deficiente de los activos, las tasas de falsos positivos pueden ser tan elevadas que el equipo de operaciones de TI pierda la confianza en la cola y la respuesta se ralentice en todos los ámbitos.
- No existe un modelo de traspaso regulado: « » Security se encarga de identificar y priorizar. El departamento de operaciones de TI se encarga de solucionar los problemas. Sin una responsabilidad clara, sin acuerdos de nivel de servicio (SLA) clasificados por niveles de riesgo y sin una gestión de excepciones, los hallazgos se acumulan en el limbo.
El requisito previo de cobertura
La precisión de las puntuaciones de riesgo cibernético depende exclusivamente de la exactitud del inventario de activos y de los datos sobre el estado de los terminales a partir de los cuales se calculan. La cobertura no se mide únicamente por el número de activos. Depende de que se conozcan en todo momento su configuración más reciente, el estado de sus parches y su nivel de exposición. Sin ello, los modelos de priorización se basan en una representación incompleta del riesgo.
Dónde se producen las lagunas en la cobertura
Los entornos empresariales generan lagunas de cobertura en lugares previsibles. Los dispositivos no gestionados, los ordenadores portátiles de los contratistas, los dispositivos móviles, los contenedores, los activos de OT e ICS, los dispositivos IoT, la «TI en la sombra» y los terminales con agentes obsoletos o que no envían informes quedan todos excluidos del análisis estándar.
Los activos de OT e ICS requieren una estrategia de cobertura diferente. Muchos no pueden dar soporte a los agentes tradicionales; los análisis agresivos entrañan el riesgo de provocar interrupciones operativas, y es habitual encontrar software obsoleto para el que no hay parches disponibles. En el caso de estos activos, los controles compensatorios se convierten en la principal herramienta para reducir el riesgo, y no las medidas correctivas, por lo que la planificación de la cobertura debe reflejarlo desde el principio.
Los entornos de desarrollo presentan un punto ciego similar: las vulnerabilidades que se introducen a través de los flujos de trabajo de CI/CD de DevOps suelen pasar desapercibidas hasta que llegan al entorno de producción, donde su corrección resulta mucho más disruptiva.
Una vulnerabilidad que aparece en 200 terminales gestionados también podría existir en 50 dispositivos no gestionados que nunca pasan a la cola de riesgos. La imagen parece completa, pero la exposición real es mayor de lo que se aprecia.
Por qué el retraso en la lectura de la imagen afecta negativamente a la puntuación
Los análisis periódicos generan resultados de puntuación que reflejan una situación pasada, no la superficie de ataque actual. En entornos dinámicos en los que los ciclos de parches, las implementaciones y los cambios de configuración se producen de forma continua, incluso un breve retraso en el análisis puede suponer que la puntuación de riesgo ya no refleje la exposición real.
La visibilidad en tiempo real de los terminales reduce el retraso que provocan los análisis periódicos, lo que proporciona una base más precisa para las puntuaciones de riesgo. Las plataformas diseñadas para la supervisión continua de proporcionan datos de telemetría de los terminales que se actualizan con frecuencia, de modo que las decisiones sobre prioridades reflejen las condiciones reales y no una instantánea de días anteriores.
La visibilidad de los activos no es un proyecto puntual. Es una disciplina en constante evolución. Sin ello, incluso el modelo de puntuación más sofisticado genera clasificaciones que no reflejan las condiciones reales de riesgo.
Una vez que se ha logrado la visibilidad en tiempo real, la siguiente pregunta es: ¿cómo se elabora una puntuación de riesgo en la que los equipos puedan confiar?
Cómo se calculan realmente las puntuaciones de riesgo
Una puntuación de riesgo en la que nadie confía es peor que no tener ninguna puntuación. Una evaluación eficaz de los riesgos comienza con una metodología clara y transparente, en la que tanto los equipos de seguridad como los de operaciones de TI comprendan los datos de entrada, la ponderación y la lógica de puntuación. Para generar confianza es necesario que quede claro cómo se combinan esos datos y esas ponderaciones para obtener una puntuación.
Igualmente importante es que los equipos tengan la certeza de que los datos subyacentes reflejan el estado real del sistema en tiempo real, y no instantáneas obsoletas, de modo que las decisiones sobre prioridades sean viables.
¿Cuáles son los cuatro datos principales que se utilizan para calcular las puntuaciones de riesgo del modelo RBVM?
Las puntuaciones de riesgo de RBVM combinan la gravedad base del CVSS (gravedad del fallo técnico), la probabilidad de explotación del EPSS (probabilidad de que se produzca una explotación en el mundo real), el estado KEV de la CISA (confirmación de explotación activa) y la criticidad del activo (función empresarial y sensibilidad de los datos) para priorizar el riesgo en el mundo real.
| Entrada | Qué mide | Por qué es importante |
|---|---|---|
| Gravedad base según el CVSS | Gravedad técnica de la vulnerabilidad | Ofrece un punto de referencia de gravedad, pero la puntuación base no tiene en cuenta el contexto real ni la posibilidad de explotación* |
| Probabilidad de explotación del EPSS | Probabilidad de explotación en el medio natural | Señal dinámica que refleja el comportamiento actual de los actores maliciosos y que evoluciona a medida que se observan nuevas actividades de explotación. |
| Estado de CISA KEV | Si la vulnerabilidad está siendo explotada de forma activa | Indicador binario de la utilización de armas en el mundo real |
| Importancia crítica de los activos | Función empresarial, sensibilidad de los datos, exposición | Determina el radio de la explosión en caso de que el activo se vea comprometido |
* El CVSS v3.x incluye modificadores de puntuación temporales y ambientales diseñados para aportar contexto, pero estos rara vez se aplican a gran escala en los programas empresariales.
Estos datos resultan más eficaces cuando se actualizan continuamente con información actualizada sobre vulnerabilidades, incluidos datos sobre exploits recientemente revelados, técnicas emergentes de los atacantes y puntuaciones actualizadas de probabilidad de explotación. El contexto de las amenazas —incluidos los sectores que están siendo objeto de ataques activos y los kits de explotación que se encuentran en circulación— puede permitir ajustar con mayor precisión la ponderación de las puntuaciones en su entorno específico.
El potencial de movimiento lateral —es decir, la posición en la red y las vías de exposición del activo afectado— también actúa como un modificador de riesgo adicional. Una vulnerabilidad en un servidor de pruebas aislado conlleva un riesgo distinto al de la misma vulnerabilidad en un controlador de dominio o en un servidor de aplicaciones que se encuentre en una ruta de red con acceso a datos confidenciales de los clientes.
¿Cuál es un ejemplo de enfoque basado en el riesgo?
Considere estas dos vulnerabilidades:
Vulnerabilidad A: CVSS 9.8 (crítica), EPSS 0.02 (baja probabilidad de explotación), no figura en la lista KEV de la CISA; afecta a un servidor de pruebas aislado sin vías de movimiento lateral.
Vulnerabilidad B: CVSS 7.5 (alta), EPSS 0.85 (alta probabilidad de explotación), incluida en la lista KEV de la CISA, afecta a un servidor de producción dedicado al procesamiento de pagos que dispone de acceso lateral a la base de datos de clientes.
El CVSS por sí solo daría prioridad a A sobre B. Sin embargo, un modelo basado en el riesgo eleva correctamente la prioridad de B, ya que un servidor de pagos en producción con vías de movimiento lateral hacia datos sensibles representa el tipo de objetivo de alto valor y accesible que, como es sabido, suelen perseguir las campañas de ransomware y extorsión.
Ese cambio de enfoque constituye precisamente el objetivo fundamental de la priorización de vulnerabilidades en un programa basado en el riesgo.
Sin embargo, la mera priorización no reduce el riesgo a menos que dé lugar a medidas correctoras que se lleven a cabo y se verifiquen.
Las proporciones específicas varían según la organización y la tolerancia al riesgo, pero se mantiene el principio general: las señales dinámicas de amenazas y el contexto empresarial pueden y deben prevalecer sobre la gravedad estática.
La puntuación también influye en la gestión de la ejecución de las medidas correctoras, y no solo en el establecimiento de prioridades. A medida que los programas avanzan hacia la automatización, la puntuación de confianza puede ayudar a determinar qué acciones se pueden implementar de forma segura a gran escala sin necesidad de revisión humana y cuáles requieren implementaciones por fases o aprobación manual.
Una vulnerabilidad con una puntuación de riesgo elevada, pero sobre la que existe incertidumbre respecto a la estabilidad del parche en una versión concreta del sistema operativo, puede justificar una implementación por fases en lugar de una aplicación inmediata. La adaptación de los umbrales de confianza a los flujos de trabajo de corrección es la forma en que las organizaciones amplían la automatización sin aumentar el riesgo operativo.
Sin embargo, incluso una puntuación bien elaborada solo resulta útil si el hallazgo subyacente es real. Ahí es donde entra en juego la validación.
Comprobar las exposiciones antes de actuar
Un resultado del escáner no equivale a una exposición confirmada. Actuar basándose en conclusiones no verificadas supone un desperdicio de la capacidad de corrección y socava la confianza entre equipos de la que dependen los programas de RBVM. La validación es la forma en que los equipos subsanan esa brecha antes de que se agrave.
Qué significa «validación»
Una exposición confirmada es un hallazgo cuya presencia en el punto final se ha verificado y que aún no ha sido mitigado mediante controles compensatorios, según los datos actuales sobre el estado y la configuración del punto final. La validación responde a tres preguntas:
- ¿Se encuentra realmente instalada y en ejecución la versión del software vulnerable « »?
- ¿Existe ya un control compensatorio que mitigue el riesgo? La segmentación de la red, las reglas del WAF y el refuerzo de la configuración pueden reducir la vulnerabilidad a los ataques.
- ¿Sigue estando activo y accesible el activo?
Con este nivel de confianza, las organizaciones pueden automatizar con total seguridad los pasos de corrección sin introducir nuevos riesgos en el proceso.
Por qué los falsos positivos minan la confianza
En entornos empresariales, las tasas de falsos positivos varían considerablemente en función de la configuración del escáner, el estado de los activos y la actualidad de los análisis. Independientemente de la cifra exacta, incluso una tasa de falsos positivos moderada a gran escala puede desbordar la capacidad de las operaciones de TI si los resultados no se validan antes de que entren en la cola de corrección. A ello contribuyen los análisis de vulnerabilidades obsoletos, los controles compensatorios que no se han tenido en cuenta y los activos que ya han sido dados de baja.
Cada falso positivo que llega al departamento de operaciones de TI supone una pérdida de tiempo que se podría haber dedicado a subsanar el riesgo. Con el paso del tiempo, los equipos de TI empiezan a mostrarse escépticos respecto a la cola. La respuesta se ralentiza y la cola pierde credibilidad.
La gestión de excepciones es lo que distingue una cola ordenada de una caótica. Los flujos de trabajo formales que excluyen los riesgos aceptados, las exposiciones compensadas y los resultados relativos a los activos fuera de servicio garantizan que la cola activa refleje únicamente las exposiciones reales y sin resolver. Sin este mecanismo, incluso las colas con una jerarquía de prioridades bien definida acumulan ruido que, con el tiempo, socava la confianza del equipo de operaciones de TI.
Para recuperar la confianza, las organizaciones necesitan algo más que mejores modelos de clasificación. Necesitan tener la certeza de que los problemas detectados reflejan la situación actual y de que las medidas correctoras son eficaces.
Esto significa hacer un seguimiento para comprobar si las medidas correctivas dan lugar a cambios verificados en el estado del sistema, y no solo al cierre de un ticket o a una actualización de su estado.
Cómo contribuye Tanium a la gestión de vulnerabilidades basada en el riesgo
La mayoría de las organizaciones ya saben qué vulnerabilidades son las más importantes. El mayor reto consiste en actuar en función de ese conocimiento de forma rápida, coherente y a gran escala. La solución «Tanium Exposure Management» subsana las deficiencias de ejecución que provocan el estancamiento de los programas de gestión de vulnerabilidades basados en el riesgo, al integrar en una única plataforma la visibilidad en tiempo real, la priorización, la corrección y la validación.
Visibilidad de los activos en tiempo real
Tanium supervisa de forma continua los terminales, los dispositivos no gestionados, los registros de contenedores y las cargas de trabajo de Kubernetes en busca de vulnerabilidades y deficiencias de cumplimiento normativo. Tanium Cloud Workloads amplía esta cobertura a los entornos en contenedores mediante la visibilidad del registro de imágenes y el análisis de vulnerabilidades, el análisis de contenedores en tiempo de ejecución y la aplicación de políticas de Kubernetes. Las lagunas en la cobertura se reducen porque la plataforma detecta activos que otras herramientas pasan por alto.
Puntuación de riesgo basada en la situación actual
Las puntuaciones de riesgo a nivel de terminal y a nivel organizativo combinan la gravedad de la vulnerabilidad, la importancia de los activos, los incumplimientos normativos y el riesgo de movimiento lateral —factores que las puntuaciones CVSS estáticas no tienen en cuenta—, junto con una evaluación comparativa con otras empresas del sector. Las puntuaciones reflejan el estado actual de los puntos finales, en lugar de instantáneas periódicas tomadas en un momento determinado. La herramienta de evaluación comparativa de Tanium, « », permite a los responsables de seguridad comparar su situación de riesgo con la de otras empresas del sector, traduciendo los datos sobre vulnerabilidades en métricas orientadas a resultados que necesitan tanto los equipos directivos como los de cumplimiento normativo.
Remediación integrada
Los equipos pasan de la evaluación a la acción en la misma plataforma. Los parches, los cambios de configuración y otras medidas de control pueden aplicarse a gran escala sin necesidad de cambiar de herramienta. Tanium Comply permite realizar evaluaciones de vulnerabilidades y comprobaciones de cumplimiento normativo en sistemas operativos, aplicaciones, la cadena de suministro de software y configuraciones de seguridad, utilizando contenidos SCAP y OVAL, además de la biblioteca de contenidos propia de Tanium, que se actualiza a diario.
Automatización regulada
Tanium Automate permite a los equipos crear guías de actuación sin código o con poco código que automatizan las tareas de corrección repetitivas. Los guiones pueden requerir la autorización de un operador antes de su ejecución, lo que garantiza la rendición de cuentas a gran escala.
Validación en bucle cerrado
Una vez aplicada la corrección, al ejecutar la evaluación de Comply se comprueba si la vulnerabilidad se ha resuelto y se actualiza la puntuación de riesgo en consecuencia. Tanium puede ejecutar esta evaluación bajo demanda, sin necesidad de realizar un ciclo de análisis completo programado.
Espacio de trabajo unificado de TI y seguridad
Ambos equipos trabajan con las mismas puntuaciones de riesgo, los mismos datos de priorización y el mismo estado de corrección, todo ello dentro de una única plataforma unificada. Este modelo operativo compartido contribuye a reducir la carga administrativa derivada de la coordinación que ralentiza la resolución de incidencias cuando los equipos de seguridad y de operaciones de TI dependen de herramientas y fuentes de datos independientes.
Tanium Guardian
Tanium Guardian detecta amenazas emergentes y ofrece orientación elaborada por expertos del Equipo de Respuesta a Emergencias de Vulnerabilidades (VERT) de Tanium, lo que ayuda a los equipos a responder con confianza ante amenazas de día cero y riesgos que requieren una respuesta inmediata. Los equipos pueden llevar a cabo medidas correctivas directamente desde la plataforma de TI autónoma de Tanium.
Estas capacidades se complementan entre sí para acortar el ciclo desde la detección hasta la corrección verificada. Ring Power Corp. utilizó Tanium para evaluar sus Log4j vulnerabilidades en todos los dispositivos finales en aproximadamente 30 minutos, un trabajo que, según estimó el equipo, habría llevado meses con las herramientas anteriores.
Cuando la detección, la priorización y la corrección se integran en una única plataforma, los programas de gestión de vulnerabilidades basados en el riesgo pueden avanzar al ritmo que exige el panorama de amenazas.
Preguntas frecuentes sobre la gestión de vulnerabilidades basada en el riesgo
Incluso los marcos bien conocidos plantean cuestiones prácticas relacionadas con su aplicación, y el RBVM no es una excepción. Las siguientes respuestas abordan algunos de los aspectos que suelen generar más dudas a los equipos a la hora de poner en práctica el modelo RBVM.
¿En qué se diferencia la gestión de vulnerabilidades basada en roles (RBVM) de la gestión tradicional de vulnerabilidades?
La gestión tradicional de vulnerabilidades establece prioridades basándose únicamente en las puntuaciones de gravedad del CVSS, mientras que la RBVM tiene en cuenta la probabilidad de explotación y la importancia de los activos para centrarse en aquellas vulnerabilidades que suponen un riesgo real para la empresa. Por ejemplo, una vulnerabilidad con una puntuación CVSS de 7.5 en un servidor de pagos con un alto nivel de explotabilidad podría tener mayor prioridad que una vulnerabilidad con una puntuación CVSS de 9.8 en un sistema de pruebas aislado.
¿De qué manera mejora la gestión de vulnerabilidades basada en el riesgo las defensas de ciberseguridad?
El RBVM mejora las defensas al destinar los recursos de corrección a aquellas vulnerabilidades que los atacantes están explotando activamente o que tienen más probabilidades de utilizar con fines maliciosos. Esto contribuye a reducir el tiempo medio de corrección de las vulnerabilidades más críticas y permite que las operaciones de TI se centren en los hallazgos que entrañan un riesgo real.
¿Cuáles son las herramientas más adecuadas para implementar una gestión de vulnerabilidades basada en el riesgo?
Los programas eficaces de RBVM suelen requerir capacidades en varias categorías: detección e inventario continuos de activos, análisis y enriquecimiento de vulnerabilidades (incluidas las puntuaciones del EPSS y el estado KEV de la CISA), integración de flujos de trabajo con herramientas de ITSM para la asignación de medidas correctivas, y verificación de que las correcciones implementadas han resuelto el problema detectado.
Algunas organizaciones combinan estas capacidades a partir de diversas herramientas específicas. Otras empresas integran la visibilidad de los activos, la evaluación de riesgos y las medidas correctivas en una única plataforma de flujos de trabajo. El enfoque adecuado depende del conjunto de herramientas existente, de la estructura del equipo y de si la visibilidad de los terminales ya es un problema resuelto.
La plataforma de TI autónoma de Tanium combina la información sobre los terminales en tiempo real con flujos de trabajo integrados y medidas correctivas, con el fin de ayudar a los equipos de seguridad y de TI a trabajar partiendo de una visión compartida y precisa de los riesgos.
Los equipos pueden actuar con mayor rapidez, reducir los retrasos en los traspasos y verificar los resultados de las medidas correctivas en todo el entorno sin tener que recurrir a un seguimiento manual ni a datos obsoletos.
Entender qué vulnerabilidades son las más importantes es solo la mitad de la ecuación. La mayoría de los programas se estancan a la hora de resolverlas con rapidez, de forma coherente y a gran escala.
Concierte hoy mismo una demostración gratuita y personalizada en para descubrir cómo Tanium integra la visibilidad en tiempo real, la priorización y la corrección en una única plataforma.
