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.

Una revisión 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 y 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.

¿Qué es la gestión de vulnerabilidades?

La gestión de vulnerabilidades es el proceso continuo de identificar, evaluar, tratar y notificar 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 gestionan).

El proceso es continuo porque el panorama de vulnerabilidades también lo es. Cada día se publican nuevas CVE. Los activos cambian. Se instala, actualiza y desinstala software. El entorno a finales de este mes es sustancialmente diferente del que había a principios de mes, y un programa de gestión de vulnerabilidades debe reflejar esa realidad, en lugar de ofrecer una instantánea puntual que ya estará 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 dado. Un programa identifica, prioriza, corrige y verifica de forma continua en un entorno en constante cambio.

El ciclo de vida de la gestión de vulnerabilidades

Todo programa de gestión de vulnerabilidades, independientemente de las herramientas que utilice o de su envergadura, sigue 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 surgen nuevos activos y nuevas vulnerabilidades, y un análisis basado en un inventario incompleto ofrece una visión incompleta.

El escaneo y la evaluación comparan los activos 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 de corrección. 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 correctiva más habitual es la aplicación de parches, pero las vulnerabilidades también pueden abordarse mediante cambios en la 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 manera 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 se han revertido 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 de corrección 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 gestió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 un proceso automatizado, exhaustivo y continuo. Identifica las vulnerabilidades conocidas en todos los activos incluidos en el alcance, genera una lista priorizada de hallazgos y proporciona los datos operativos necesarios para el seguimiento de las medidas correctivas. No intenta explotar dichas vulnerabilidades. Indica dónde existen los puntos débiles, pero no si un atacante experto podría aprovecharlos realmente en su 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 sus 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 información sobre los riesgos. Las pruebas de penetración, que suelen realizarse anualmente o antes de cambios arquitectónicos significativos, permiten determinar si el programa operativo funciona realmente. Utilizar una prueba de penetración como sustituto del análisis continuo es un error habitual, ya que el carácter puntual de una prueba hace que no detecte las vulnerabilidades introducidas después de la fecha de la prueba, que en un entorno típico son la mayoría de las que surgen en los 90 días siguientes.

Establecimiento de prioridades: cómo decidir qué se soluciona primero

El objetivo de la priorización no es reducir al mínimo el 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 importancia de los activos. Una puntuación CVSS es un punto de partida útil, pero por sí sola constituye una indicación incompleta. Una vulnerabilidad con puntuación CVSS 9 para la que no existe ningún exploit público es menos urgente que una vulnerabilidad con puntuación CVSS 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 sobre el 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, parche en un plazo de 7 días: vulnerabilidades con puntuación CVSS alta; vulnerabilidades para las que se han 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 dispositivos 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 pondremos con 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 servicio 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 los entornos. Sin un marco que identifique de inmediato qué hallazgos corresponden a entradas del KEV de la CISA y qué activos presentan mayor criticidad, el informe resulta abrumador y el programa acaba recurriendo a la estrategia de «aplicar parches a lo que resulte más fácil». Con uno, la lista del primer día es manejable: un conjunto específico de hallazgos críticos que requieren una corrección de 24 a 72 horas, ordenados por cliente, con todo lo demás clasificado 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 manera coherente en todos los entornos de los clientes, con opciones de personalización por cliente en cuanto a el 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 trimestrales de revisión de resultados (QBR), que traducen las listas de CVE a un lenguaje de riesgo adaptado al contexto empresarial; y un seguimiento de las correcciones vinculado al SLA que muestra 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 el contexto y la documentación de los activos, lo que permite establecer prioridades con precisión en función de la criticidad de los activos, en lugar de basarse en conjeturas.

Descubre cómo se integra la gestión de parches de Kaseya VSA 10 con la detección de vulnerabilidades.

Modos de fallo habituales

Los programas de gestión de vulnerabilidades fallan de formas predecibles. Conocer los patrones hace que sea más fácil evitarlos.

Escanear sin actuar. Los informes de vulnerabilidades 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 es 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 incluida 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 cobertura. Una gestión de vulnerabilidades que analiza la red corporativa pero pasa 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 cobertura 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 designado, 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 equivale a confirmar que se ha solucionado una vulnerabilidad. El análisis de verificación tras la corrección es lo que convierte esa acción 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 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 decenas 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 la semana del «Patch Tuesday». Con políticas de implementación automatizada de parches que se ejecutan según criterios basados en niveles, sin necesidad de que un técnico apruebe cada paso, es el sistema el que cumple el plazo de 72 horas, en lugar de que sea el equipo el que lo incumpla. Descubra Kaseya Intelligence.

Una gestión de vulnerabilidades bien hecha pasa desapercibida. Se distribuyen los parches. Los hallazgos se procesan 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 manera no sufren el tipo de incidentes causados por vulnerabilidades conocidas y parcheables que se dejan sin resolver durante meses. Los que no se gestionan así descubren, a través de los incidentes, exactamente cuál de los modos de fallo mencionados anteriormente presentaba su programa.