Gestión de vulnerabilidades: una guía práctica para equipos de TI y proveedores de servicios gestionados (MSP)
La mayoría de las organizaciones cuentan con algún tipo de gestión de vulnerabilidades. Un análisis trimestral, algún tipo de proceso de aplicación de parches, una prueba de penetración anual para cumplir con la normativa. Lo que la mayoría de las organizaciones no tienen es un programa lo suficientemente riguroso como para reducir realmente su exposición.
Un análisis trimestral con un informe que nadie tiene en cuenta no es gestión de vulnerabilidades. Tampoco lo es aplicar parches cuando las cosas fallan. Tampoco lo es una única prueba de penetración anual que sirve para marcar una casilla y luego queda archivada en una carpeta. La gestión eficaz de vulnerabilidades es un proceso continuo, basado en datos, que consiste en detectar, priorizar y subsanar los puntos débiles de un entorno informático antes de que los atacantes los aprovechen, y hacerlo con la suficiente rapidez como para que la ventana de explotación siga siendo reducida.
Según el informe «State of the MSP» de Kaseya de 2026, el 53 % de los MSP señalan los problemas de ciberseguridad como una de sus principales preocupaciones empresariales. Las vulnerabilidades sin parchear son la causa más habitual por la que esas preocupaciones se convierten en incidentes. Descarga el informe completo.
Detecta y soluciona las vulnerabilidades antes de que lo hagan los atacantes.
Kaseya VSA 10 realiza análisis continuos para detectar parches que faltan y vulnerabilidades de software en todos los terminales gestionados, y transmite los resultados directamente a los flujos de trabajo de corrección automatizados.
¿Qué es la gestión de vulnerabilidades?
La gestión de vulnerabilidades es el proceso continuo de identificar, evaluar, tratar e informar sobre las vulnerabilidades de seguridad en todo el entorno informático de una organización. Abarca las vulnerabilidades de software (parches pendientes, CVE sin parchear), las deficiencias de configuración (credenciales predeterminadas, puertos abiertos innecesarios, configuraciones de servicios inseguras) y las lagunas en la visibilidad de los activos (dispositivos presentes en el entorno que no se supervisan ni se gestionan).
El proceso es continuo porque el panorama de vulnerabilidades es continuo. Cada día se publican nuevas CVE. Los activos cambian. El software se instala, se actualiza y se desinstala. El entorno a finales de este mes es sustancialmente diferente del entorno a principios del mismo, y un programa de gestión de vulnerabilidades debe reflejar esa realidad, en lugar de ofrecer una instantánea puntual que ya esté desactualizada antes de que se distribuya el informe.
Esta es la diferencia que distingue un programa de gestión de vulnerabilidades de una evaluación de vulnerabilidades. Una evaluación identifica lo que existe en un momento determinado. Un programa, en cambio, identifica, prioriza, corrige y verifica de forma continua en un entorno cambiante.
El ciclo de vida de la gestión de vulnerabilidades
Todos los programas de gestión de vulnerabilidades, independientemente de las herramientas que utilicen o de su escala, siguen el mismo ciclo operativo.
La detección y el inventario son la base. No se puede proteger lo que no se conoce. Una detección completa de los activos —incluidos los dispositivos que no se han registrado oficialmente, la «TI en la sombra», las instancias en la nube y los dispositivos IoT— es lo que da sentido a los análisis. Una detección que se realiza de forma continua, en lugar de periódica, resulta más eficaz, ya que entre los ciclos de análisis aparecen nuevos activos y nuevas vulnerabilidades, y un análisis basado en un inventario incompleto ofrece una visión incompleta de la situación.
El escaneo y la evaluación comprueban los activos comparándolos con bases de datos de vulnerabilidades conocidas (CVE) y normas de configuración. La distinción entre el escaneo autenticado y el no autenticado es fundamental. El escaneo no autenticado desde el perímetro de la red muestra lo mismo que vería un atacante externo. El escaneo autenticado, en el que el escáner inicia sesión en los sistemas para evaluar su estado interno, ofrece resultados mucho más completos. La mayoría de los programas serios de gestión de vulnerabilidades llevan a cabo ambos tipos de escaneo.
La priorización determina el orden en que se aplican las medidas correctivas. No todas las vulnerabilidades tienen la misma urgencia, y el volumen de hallazgos en cualquier entorno real es tan elevado que la calidad de la priorización es más importante que la cobertura total del análisis. A continuación se describen en detalle los marcos que funcionan.
La corrección es donde el programa aporta valor. La medida de corrección más habitual es la aplicación de parches, pero las vulnerabilidades también pueden abordarse mediante cambios de configuración, controles compensatorios o el aislamiento de los activos afectados cuando no es posible aplicar un parche de forma inmediata. La corrección debe contar con plazos definidos en el acuerdo de nivel de servicio (SLA) según el nivel de riesgo, y no con un único plazo uniforme que trate una CVE crítica con un exploit activo de la misma forma que un hallazgo de configuración de baja gravedad.
La verificación cierra el ciclo. Una vez aplicadas las medidas correctivas, el análisis debe confirmar que las vulnerabilidades se han solucionado de forma efectiva. Los parches que no se han aplicado correctamente, las configuraciones que han vuelto a su estado anterior o los controles compensatorios que no han funcionado como se esperaba hacen que las organizaciones crean que han solucionado algo que, en realidad, no han solucionado. La verificación es lo que convierte la actividad correctiva en una reducción confirmada del riesgo.
Los informes están dirigidos a diversos públicos. Los equipos técnicos que supervisan el progreso de las medidas correctivas necesitan datos detallados y útiles. Los informes de dirección sobre el estado de seguridad requieren datos de tendencias que muestren la exposición a lo largo del tiempo. Los responsables del cumplimiento normativo necesitan pruebas de que se llevan a cabo prácticas continuas de gestión de vulnerabilidades. Un programa que solo genere uno de estos tipos de informes está mermando su propia utilidad.
Análisis de vulnerabilidades frente a pruebas de penetración
Estas dos prácticas son complementarias y a menudo se confunden entre sí; utilizar una en lugar de la otra es un error habitual en el diseño de programas.
El análisis de vulnerabilidades es automatizado, exhaustivo y continuo. Identifica las vulnerabilidades conocidas en todos los activos incluidos en el ámbito de análisis, genera una lista priorizada de hallazgos y proporciona los datos operativos necesarios para el seguimiento de las medidas correctivas. No intenta explotar dichas vulnerabilidades. Te indica dónde existen debilidades, pero no si un atacante experto podría aprovecharlas realmente en tu entorno específico.
Las pruebas de penetración son manuales o semiautomáticas, de alcance limitado y periódicas. Un evaluador experto intenta aprovechar las vulnerabilidades, incluidas las cadenas de problemas de menor gravedad que, por separado, parecen manejables, pero que, al combinarse, permiten obtener un acceso significativo, con el fin de demostrar vías de ataque reales. Las pruebas de penetración comprueban si tus defensas resisten ante un atacante experto, y no solo si existen vulnerabilidades.
Ambos son valiosos y responden a preguntas diferentes. El análisis de vulnerabilidades es el programa operativo continuo que mantiene actualizada la exposición a riesgos. Las pruebas de penetración, que suelen realizarse anualmente o antes de cambios arquitectónicos significativos, permiten determinar si el programa operativo está funcionando realmente. Utilizar una prueba de penetración como sustituto del análisis continuo es un error común: el carácter puntual de una prueba implica que no detecta las vulnerabilidades introducidas después de la fecha de la prueba, que en un entorno típico son la mayoría de ellas en un plazo de 90 días.
Establecimiento de prioridades: cómo decidir qué se soluciona primero
El objetivo de la priorización no es alcanzar el menor número total de CVE. Se trata de reducir las vulnerabilidades con mayor probabilidad de ser explotadas antes de que se puedan corregir todas, ya que, en cualquier entorno real, no es posible corregirlas todas al mismo tiempo.
Las dos variables más importantes son la explotabilidad y la criticidad del activo. Una puntuación CVSS es un punto de partida útil, pero por sí sola constituye una señal incompleta. Una vulnerabilidad con una puntuación CVSS de 9 para la que no existe ningún exploit público es menos urgente que una vulnerabilidad con una puntuación CVSS de 7 que el catálogo de vulnerabilidades explotadas conocidas (KEV) de la CISA incluya como activamente explotada en la red. El catálogo KEV es la referencia pública más fiable en cuanto al estado de explotación activa, y cualquier vulnerabilidad que figure en él debe tratarse como un elemento de nivel 1, independientemente de su puntuación CVSS.
Un marco práctico de cuatro niveles:
Nivel 1, corrección en un plazo de 24 a 72 horas: vulnerabilidades CVSS críticas en activos conectados a Internet o con privilegios elevados; cualquier entrada del catálogo KEV de la CISA; vulnerabilidades cuya explotación activa se haya confirmado según la información sobre amenazas.
Nivel 2, corrección en un plazo de 7 días: vulnerabilidades con puntuación CVSS alta; vulnerabilidades para las que se hayan publicado exploits de prueba de concepto; cualquier vulnerabilidad en activos que contengan datos confidenciales o que permitan un acceso con privilegios.
Nivel 3, corrección en un plazo de 30 días: vulnerabilidades de gravedad media en terminales estándar.
Nivel 4, tratamiento en el ciclo de mantenimiento: Vulnerabilidades de baja gravedad sin indicios de explotación activa.
Las vulnerabilidades que no puedan solucionarse dentro de los plazos establecidos (por limitaciones de compatibilidad de aplicaciones críticas para el negocio o por los procesos de aprobación de cambios del cliente) deben documentarse formalmente, aplicando controles compensatorios y configurando alertas de antigüedad. Un «ya nos ocuparemos de ello» sin documentar supone un riesgo que va en aumento sin que nadie lo supervise.
Gestión de vulnerabilidades para proveedores de servicios gestionados (MSP)
Los MSP que gestionan programas de gestión de vulnerabilidades en múltiples entornos de clientes necesitan las mismas capacidades básicas que los equipos de TI de una sola organización, además de cumplir tres requisitos adicionales: multitenencia, generación de informes por cliente y una capa de priorización capaz de identificar los elementos más urgentes en el conjunto de entornos.
El reto de establecer prioridades por cliente es donde la escala marca una diferencia real. Un MSP que preste soporte a 40 entornos de clientes y realice un análisis de vulnerabilidades trimestral puede detectar varios cientos de CVE de alta gravedad en el conjunto de entornos. Sin un marco que identifique de inmediato qué hallazgos son entradas del KEV de la CISA y qué activos tienen mayor criticidad, el informe resulta abrumador y el programa recurre por defecto a «aplicar parches a lo que resulte más fácil». Con un marco de este tipo, la lista del primer día resulta manejable: un conjunto específico de hallazgos críticos que requieren una corrección en un plazo de 24 a 72 horas, ordenados por cliente, mientras que todo lo demás se clasifica en colas semanales y mensuales.
La infraestructura práctica para la gestión de vulnerabilidades a escala de MSP incluye políticas de análisis estandarizadas que se aplican de forma coherente en todos los entornos de los clientes, con personalización por cliente en cuanto al momento del análisis, el alcance y las credenciales; paneles de control de vulnerabilidades por cliente que ofrecen a los gestores de cuentas visibilidad sobre la exposición actual y la velocidad de corrección; informes dirigidos a los clientes, adecuados para las reuniones de revisión trimestral (QBR), que traducen las listas de CVE a un lenguaje de riesgo adaptado al contexto empresarial; y un seguimiento de la corrección vinculado al SLA que demuestra la velocidad de aplicación de parches y proporciona pruebas de que se están cumpliendo los plazos acordados.
VulScan, que forma parte de la familia Kaseya a través de RapidFire Tools, ofrece un servicio de análisis de vulnerabilidades de red diseñado específicamente para proveedores de servicios gestionados (MSP), con detección automática e identificación de CVE en las redes de los clientes. Kaseya VSA 10 y Datto RMM se encargan de la implementación de parches, convirtiendo las vulnerabilidades identificadas directamente en flujos de trabajo de corrección. IT Glue contiene el contexto y la documentación de los activos, lo que permite establecer prioridades en función de la criticidad de los mismos con precisión, en lugar de basarse en conjeturas.
Modos de fallo habituales
Los programas de gestión de vulnerabilidades fallan de formas predecibles. Conocer estos patrones facilita evitarlos.
Análisis sin medidas. Los informes de vulnerabilidad que generan hallazgos pero no alimentan un flujo de trabajo de corrección no aportan ningún valor en materia de seguridad. Una larga lista de CVE sin responsables asignados ni plazos de corrección constituye una documentación del riesgo, no una reducción del mismo.
Priorización basada únicamente en el CVSS. Una puntuación CVSS mide la gravedad potencial, no la probabilidad de que se produzca una explotación activa. Considerar que una vulnerabilidad con una puntuación CVSS de 9, para la que no existe ningún exploit público, es más urgente que una con una puntuación CVSS de 7 que figure en la lista KEV de la CISA es un error. Los datos sobre la explotabilidad procedentes del catálogo KEV y de las fuentes de inteligencia sobre amenazas deben formar parte del modelo.
Activos fuera del ámbito de aplicación. Una gestión de vulnerabilidades que analice la red corporativa pero que pase por alto las instancias en la nube, los dispositivos remotos o la infraestructura de OT e IoT presenta lagunas que los atacantes acabarán detectando, ya que estos realizan análisis exhaustivos. El ámbito de aplicación debe reflejar el entorno real, no el entorno tal y como se documentó hace dos años.
Falta de responsabilidad en la corrección. Las vulnerabilidades a las que no se les ha asignado un responsable no se corrigen. Cada vulnerabilidad identificada necesita un responsable concreto, un acuerdo de nivel de servicio (SLA) según el nivel de riesgo y un mecanismo de seguimiento. Asignar la responsabilidad sin fijar un plazo equivale a no asignarla.
Sin verificación. Confirmar que se ha aplicado un parche no es lo mismo que confirmar que se ha subsanado una vulnerabilidad. El análisis de verificación tras la subsanación es lo que convierte esa actividad en una reducción confirmada del riesgo.
Kaseya Intelligence: de la detección a la acción autónoma
Las herramientas tradicionales de gestión de vulnerabilidades identifican las deficiencias y ofrecen recomendaciones. El cuello de botella operativo es siempre el mismo: un técnico tiene que revisar el hallazgo, priorizarlo frente al resto de tareas de la cola y actuar al respecto a un ritmo que no se ajusta a la velocidad a la que se descubren y se aprovechan las vulnerabilidades.
Kaseya Intelligence se basa en más de tres exabytes de datos agregados y anonimizados y en más de 17 millones de terminales gestionados, pasando de la simple detección de vulnerabilidades a la ejecución autónoma de medidas correctivas: aplicación de parches, aislamiento y validación de resultados sin necesidad de intervención manual en cada paso.
Para los MSP que gestionan programas de gestión de vulnerabilidades en docenas de entornos de clientes, el paso de las recomendaciones a la acción autónoma es lo que hace que el programa sea escalable. Un equipo que gestiona 40 clientes no puede clasificar y resolver manualmente cada hallazgo de nivel 1 en un plazo de 72 horas durante una semana de «Patch Tuesday». Con políticas automatizadas de implementación de parches que se ejecutan según criterios basados en niveles, sin necesidad de que un técnico apruebe cada paso individualmente, el sistema cumple el plazo de 72 horas en lugar de que el equipo lo incumpla. Descúbrelo en Kaseya Intelligence.
Una gestión de vulnerabilidades bien hecha pasa desapercibida. Se distribuyen los parches. Los hallazgos se tramitan a través de los distintos niveles. Los análisis de verificación confirman la corrección. Los informes trimestrales muestran una línea de tendencia que avanza en la dirección correcta. Los clientes cuyos entornos se gestionan de esta forma no sufren el tipo de incidentes provocados por vulnerabilidades conocidas y corregibles que permanecen sin solucionar durante meses. Los que no se gestionan así descubren, a través de los incidentes, exactamente cuáles de los modos de fallo mencionados anteriormente presentaba su programa.
Puntos clave
- La gestión de vulnerabilidades es un proceso continuo, no un análisis trimestral ni una prueba de penetración anual. El entorno cambia con tanta rapidez que los enfoques puntuales no pueden seguir el ritmo del panorama de vulnerabilidades.
- Establecer prioridades combinando la puntuación CVSS, el estado de explotación activa según el catálogo KEV de la CISA y la importancia de los activos resulta mucho más eficaz que tratar todas las vulnerabilidades como si tuvieran la misma urgencia. Cualquier vulnerabilidad incluida en el catálogo KEV de la CISA se considera de nivel 1, independientemente de su puntuación CVSS.
- Los análisis de seguridad y las pruebas de penetración responden a cuestiones diferentes. Los análisis de seguridad proporcionan una cobertura operativa continua. Las pruebas de penetración comprueban si los controles y el programa de corrección resisten realmente ante un atacante experto.
- Para los MSP, los marcos de priorización por cliente, las políticas de análisis estandarizadas y el seguimiento de las medidas correctivas vinculadas a los SLA son los elementos que permiten que la gestión de vulnerabilidades sea escalable en un entorno con múltiples clientes sin necesidad de aumentar proporcionalmente la plantilla.
