La mayoría de los programas de gestión de vulnerabilidades se autodenominan «continuos». En realidad, son pocos los que lo son. La diferencia es importante: un programa que realiza análisis semanales pero que se autodenomina «continuo» genera una falsa sensación de seguridad, dejando vulnerabilidades sin cubrir entre un ciclo y otro, mientras que los responsables dan por hecho que la cobertura es completa.
La gestión continua de vulnerabilidades, o CVM, es un proceso continuo y automatizado que consiste en detectar, analizar, priorizar y subsanar las deficiencias de seguridad en toda la infraestructura informática de una organización. A diferencia de los ciclos periódicos de análisis y generación de informes, CVM mantiene una visibilidad en tiempo real del estado de los activos y de su nivel de vulnerabilidad, lo que reduce el margen de tiempo del que disponen los atacantes para aprovechar las vulnerabilidades recién reveladas.
Este artículo ofrece un marco de diagnóstico para evaluar si su programa actual cumple con el estándar operativo que implica el término «continuo», y abarca las condiciones específicas, los indicadores y las estructuras de coordinación que distinguen a los programas verdaderamente continuos de los que solo lo son de forma esporádica.
Qué significa realmente «continuo» y por qué la mayoría de los programas no cumplen los requisitos
La mayoría de los programas que se autodenominan «continuos» siguen funcionando con ciclos de análisis semanales o mensuales. Establecen prioridades por lotes, crean incidencias manualmente y dan por hecho que la corrección ha funcionado sin verificarlo. Mientras tanto, la superficie de ataque de no deja de cambiar: se activan nuevos activos, las configuraciones se desvían y las vulnerabilidades (CVE) recién reveladas crean ventanas de exposición que los ciclos de análisis semanales no pueden cerrar.
Los programas periódicos programan análisis, establecen prioridades por lotes y generan tickets de forma manual. Los programas continuos mantienen un seguimiento del estado en tiempo real, activan la priorización cuando cambian las condiciones y verifican la corrección mediante comprobaciones de bucle cerrado.
Un programa verdaderamente continuo cumple todos los requisitos siguientes:
- Los nuevos activos se detectan y se registran en cuestión de horas, no de días
- Las vulnerabilidades recientemente detectadas se evalúan en relación con el inventario completo de activos, dentro de los límites de un SLA definido
- El estado de la remediación se verifica mediante un proceso programático, no se da por supuesto.
La mayoría de los programas no cumplen al menos una de estas propiedades, y el motivo suele estar relacionado con el punto en el que se sitúan en el espectro de madurez de la supervisión.
Tres niveles de continuidad de la monitorización: periódica, de alta frecuencia y en tiempo real
Comprender en qué punto del espectro de la supervisión continua de vulnerabilidades se encuentra su programa ayuda a aclarar cuál es el coste real de la «continuidad» y qué carencias persisten.
Nivel 1: Escaneo periódico. Los análisis programados se ejecutan semanalmente, mensualmente o trimestralmente. La latencia en la detección de vulnerabilidades se mide en días o semanas. Existen lagunas de cobertura entre un ciclo y otro. Este enfoque resulta eficaz en entornos estables y con pocos cambios, pero no detecta las vulnerabilidades que surgen a mitad del ciclo.
Nivel 2: Escaneo de alta frecuencia. Los ciclos de análisis diarios o casi diarios reducen la latencia de detección a unas pocas horas. La cobertura mejora en entornos dinámicos; sin embargo, los activos efímeros, como los contenedores y las instancias en la nube con escalado automático (incluidas las cargas de trabajo que se ejecutan en clústeres de Kubernetes y que pueden iniciarse y terminarse en el transcurso de un único intervalo de análisis), pueden seguir existiendo entre las ventanas de análisis y pasar desapercibidos.
Nivel 3: Supervisión del estado en tiempo real basada en agentes. Los agentes persistentes informan de forma continua sobre el estado y la configuración de los activos. La latencia de detección se reduce a unos minutos. Se incluyen los activos efímeros y aquellos que se vuelven a conectar sin conexión. La contrapartida es la carga que supone el despliegue y la gestión de los agentes.
| Nivel | Latencia de detección | Cobertura de activos | La mejor opción |
|---|---|---|---|
| Periódico | De días a semanas | Intervalos entre ciclos | Entornos estables y con pocos cambios |
| De alta frecuencia | Horario | Activos efímeros que se pierden | Una infraestructura dinámica, pero predecible |
| En tiempo real | Acta | Abarca los activos fuera de línea o efímeros | Entornos de gran tamaño, distribuidos o en rápida evolución |
La mayoría de los programas empresariales funcionan en el Nivel 1 o 2 y dan por sentado que son «continuos». La arquitectura de agente único de Tanium proporciona datos de estado en tiempo real que eliminan el retraso inherente a los análisis de vulnerabilidades programados . La cuestión no es qué nivel es «el mejor». Se trata de determinar qué nivel se ajusta al perfil de riesgo y a la velocidad de cambio de su entorno.
El nivel de supervisión determina la rapidez con la que se detectan las vulnerabilidades. Lo que suceda a continuación determinará si es importante encontrarlos.
Por qué fracasan los programas de CVM en las empresas: la falta de coordinación entre TI y SecOps
La detección sin medidas correctivas no es más que una costosa campaña de sensibilización. El mayor fallo de continuidad en el CVM empresarial no es un problema tecnológico. Se trata de un problema de coordinación que impide a los equipos subsanar las vulnerabilidades detectadas con la rapidez que exige el programa. Esa falta de coordinación tiene consecuencias reales: los estudios demuestran sistemáticamente que muchas filtraciones de datos no se deben a vulnerabilidades no detectadas, sino a vulnerabilidades conocidas que quedaron sin corregir porque nadie se hacía cargo del traspaso de responsabilidades entre los equipos de seguridad y de TI.
Los equipos de seguridad detectan vulnerabilidades. La corrección de incidencias depende de equipos de operaciones de TI con prioridades, acuerdos de nivel de servicio (SLA) y procesos de control de cambios distintos. La brecha entre «lo hemos detectado» y «lo hemos solucionado» es donde reside el riesgo.
Fallos en la integración del sistema de venta de entradas. Cuando los hallazgos de vulnerabilidades requieren la creación manual de un ticket, es habitual que se produzcan retrasos de varios días. La gestión integrada de incidencias funciona de otra manera: los resultados generan automáticamente incidencias que incluyen el nivel de gravedad, el contexto del activo y las instrucciones para su resolución. Los traspasos manuales generan dificultades que se acumulan a lo largo de miles de hallazgos.
Desalineación del SLA. El departamento de seguridad determina el nivel de gravedad mediante el CVSS o la puntuación de riesgo. El departamento de TI determina la prioridad en función de la disponibilidad de las ventanas de cambio y del impacto en el negocio. Sin niveles de SLA compartidos, las vulnerabilidades críticas quedan en espera mientras los equipos discuten sobre la programación.
Una estructura práctica de un SLA podría tener el siguiente aspecto:
- Nivel 1 (crítico, objeto de explotación activa): Acuerdo de nivel de servicio (SLA) de resolución en 24 horas
- Nivel 2 (alto, existe una vulnerabilidad): SLA de 7 días (alcanzable a gran escala mediante la aplicación automatizada de parches; ajustar en función de la complejidad del entorno)
- Nivel 3 (medio/bajo): Ventana de mantenimiento programada o en la que se acepta el riesgo
Ambigüedad en cuanto a la titularidad. Cuando nadie asume la responsabilidad del resultado de la corrección de principio a fin, las vulnerabilidades se acumulan en las colas de incidencias. Un proceso de resolución de incidencias claramente definido responde a tres preguntas: ¿Quién es el responsable del ticket? ¿Quién es el responsable de la verificación? ¿A quién corresponde la responsabilidad en caso de que se aplace la corrección?
Entonces, ¿cómo es realmente un programa verdaderamente continuo? En la siguiente sección se desglosa en cinco condiciones comprobables.
Las cinco condiciones que debe cumplir un programa verdaderamente continuo
Considere lo siguiente como una lista de verificación, no como un ciclo de vida. Cada condición se cumple o no se cumple. El crédito parcial no reduce la exposición.
1. Inventario completo de activos en tiempo real
El programa mantiene un inventario del estado actual que recoge los activos efímeros, remotos y sin conexión. No se trata de una CMDB que vaya con días o semanas de retraso respecto a la realidad.
Prueba: ¿Puede confirmar en el plazo de una hora si una vulnerabilidad CVE crítica recientemente revelada afecta a algún activo de su entorno? Si la respuesta es «tendríamos que realizar un análisis primero», existe una brecha de continuidad.
2. Detección basada en eventos
Las nuevas vulnerabilidades activan los flujos de trabajo de detección inmediatamente tras su divulgación, y no en la siguiente ventana de análisis. Para ello, es necesaria una integración activa con fuentes de inteligencia sobre amenazas de , y avisos de seguridad de los proveedores, incluidas las actualizaciones KEV de la CISA, las publicaciones del NVD y los boletines específicos de cada proveedor, como el «Patch Tuesday» de Microsoft y los avisos de las distribuciones de Linux, de modo que los incidentes de divulgación activen automáticamente la evaluación de los activos, en lugar de esperar a que se realice un análisis programado.
Prueba: Cuando se publica una vulnerabilidad CVE crítica, ¿cuánto tiempo tarda su programa en evaluar todos los activos en relación con ella? El horario es ininterrumpido. Days es frecuente. Las semanas son periódicas.
3. Priorización contextual integrada en el flujo de trabajo
La priorización se basa en la criticidad de los activos, en indicadores de vulnerabilidad como el EPSS y el KEV de la CISA, y en la inteligencia sobre amenazas (incluidas las amenazas emergentes que, aunque quizá aún no tengan puntuaciones CVSS elevadas, ya se están utilizando activamente en el entorno real). El Sistema de Puntuación de Predicción de Aprovechamiento de Vulnerabilidades (EPSS) estima la probabilidad de que una vulnerabilidad sea aprovechada en entornos reales en un plazo de 30 días, lo que proporciona una indicación prospectiva que la gravedad del CVSS por sí sola no puede reflejar. Este es el dominio de , dedicado a la gestión de vulnerabilidades basada en el riesgo, donde se describe la metodología.
4. Corrección con verificación en bucle cerrado
Cada medida correctiva se verifica mediante un proceso automatizado. La vulnerabilidad no se marcará como «resuelta» hasta que una comprobación de seguimiento confirme que se ha solucionado. El artículo « » (Corrección automatizada de vulnerabilidades) aborda los distintos enfoques de implementación.
5. Medición y presentación de informes continuas
El programa realiza un seguimiento de sus propios indicadores de rendimiento y los comunica a las partes interesadas con una periodicidad definida. No solo cuando lo soliciten los auditores. Si no puede responder a la pregunta «¿Cuál es nuestro tiempo medio de corrección de vulnerabilidades críticas?» sin generar un informe personalizado, el programa genera informes bajo demanda, en lugar de realizar mediciones de forma continua.
El incumplimiento de cualquiera de estas condiciones supone un riesgo. Un programa con una detección perfecta, pero sin verificación, informa sobre la actividad, no sobre los resultados.
De las cinco condiciones, la verificación es la que la mayoría de los equipos omiten por completo. Veamos por qué es importante.
Validación: el paso del CVM que la mayoría de los programas omiten
La mayoría de los equipos marcan las vulnerabilidades como «resueltas» cuando se implementa un parche, y no cuando se confirma que la vulnerabilidad ha quedado eliminada. Esa diferencia entre «aplicamos la solución» y «la solución funcionó de verdad» es la causa de una confianza infundada.
Antes de la rehabilitación
Confirmación previa a la remediación
Antes de asignar una vulnerabilidad para su corrección, confirme que el hallazgo del escáner represente una exposición real y susceptible de ser explotada. No se trata de un falso positivo ni de un artefacto de configuración. Este paso también detecta errores de configuración que los escáneres identifican como vulnerabilidades: problemas que pueden requerir un cambio de configuración en lugar de un parche, y que se canalizan de forma incorrecta cuando se omite la clasificación previa a la corrección. Omitir este paso supone un desperdicio de recursos de TI y, con el tiempo, merma la confianza en el programa de máquinas virtuales.
Una vez que se haya implementado la corrección
Verificación posterior a la remediación
Una vez que se haya implementado un parche de seguridad o un cambio de configuración, compruebe mediante código que la vulnerabilidad se ha solucionado efectivamente. Un nuevo análisis o una comprobación del estado mediante un agente confirma que el activo ya no presenta dicha vulnerabilidad. «El ticket está cerrado» no constituye una verificación.
Para activos de gran valor
Validación adversaria
En el caso de activos de gran valor o hitos críticos de la remediación, las pruebas de penetración aportan un nivel de validación frente a amenazas que la verificación automatizada no puede igualar. Las nuevas inspecciones programadas confirman que se ha subsanado una condición de vulnerabilidad concreta; una prueba específica va más allá. Las comprobaciones automáticas confirman que una operación se ha cerrado. No pueden confirmar que la exposición haya desaparecido.
Cuando no es posible la remediación
Gestión de excepciones
En el caso de las vulnerabilidades que no puedan subsanarse, como los sistemas heredados o las aplicaciones críticas para el negocio sujetas a restricciones de cambios, establezca un proceso formal de excepciones. Documente la aceptación de riesgos, los controles compensatorios, la periodicidad de las revisiones y las fechas de vencimiento. Las excepciones sin fecha de caducidad se convierten en una exposición permanente.
Un programa de CVM que no pueda demostrar la eficacia de las medidas correctivas solo mide el volumen de actividad, no la seguridad.
La verificación permite comprobar si las correcciones individuales han surtido efecto. Las métricas permiten determinar si el programa en sí está funcionando. A continuación le indicamos cómo distinguirlas.
Cómo evaluar si su programa de CVM está dando resultados
Las métricas son la única forma de distinguir un programa que es verdaderamente continuo de otro que simplemente es frecuente. Realice un seguimiento de los siguientes aspectos, informe sobre ellos periódicamente y utilícelos para impulsar la mejora. En conjunto, estos indicadores ofrecen a la dirección una visión cuantificable del estado de seguridad de la organización: no solo una instantánea de los incidencias abiertas, sino una línea de tendencia que muestra si el programa está reduciendo realmente el riesgo cibernético a lo largo del tiempo.
| Sistema métrico | Qué mide | Referencia de salud |
|---|---|---|
| Porcentaje de cobertura de escaneo | Proporción de activos conocidos sometidos a seguimiento activo | Cerca del 100 %, con excepciones documentadas |
| Horas transcurridas entre la publicación de la CVE y la confirmación del impacto | Horas para las vulnerabilidades críticas (CVE), no días | |
| Tiempo medio de resolución (MTTR) | Tiempo transcurrido desde la detección hasta el cierre verificado, según la gravedad | Dentro de los niveles de SLA establecidos |
| Tasa de falsos positivos | Porcentaje de hallazgos que no son aprovechables | En descenso con el paso del tiempo |
| Índice de excepciones | Porcentaje de incidencias aceptadas como riesgo frente a las que se han subsanado | Estables o en descenso, todo ello documentado |
| Índice de validación de la remediación | Porcentaje de observaciones «resueltas» verificadas mediante procedimientos programáticos | Se acerca al 100 % en el nivel «crítico/alto» |
La «antigüedad de las vulnerabilidades» es una séptima métrica opcional: ¿cuánto tiempo permanecen abiertas las vulnerabilidades en todo el entorno a lo largo del tiempo? Una distribución adecuada se inclina hacia una resolución rápida, con una antigüedad máxima aceptable definida para cada nivel de gravedad y unas expectativas claras en cuanto a los plazos de resolución.
Si los responsables solo consultan los datos sobre vulnerabilidad cuando el departamento de cumplimiento normativo se lo solicita, el programa se limita a elaborar informes bajo demanda, en lugar de realizar mediciones continuas o gestionar el riesgo de forma proactiva.
Las métricas le permiten saber si el programa está funcionando. No tienen en cuenta las realidades operativas que dificultan la puesta en práctica. La forma en que un programa cumple estos requisitos varía cuando el propio entorno es complejo y está distribuido.
La gestión del valor para el cliente (CVM) en entornos complejos y regulados
Los entornos complejos no eximen a un programa del cumplimiento de las condiciones de continuidad definidas anteriormente. Añaden limitaciones operativas que el programa tiene en cuenta.
- Terminales distribuidos y sin conexión: . Los agentes remotos pueden funcionar con conexión intermitente. Los programas continuos gestionan esto mediante la sincronización de estados al restablecerse la conexión, las acciones correctivas en cola y el seguimiento de las interrupciones de cobertura en los activos que permanecen fuera de línea más allá de un umbral definido.
- Terminales convergentes de OT/TI: . Los análisis pueden alterar el funcionamiento de los sistemas de tecnología operativa. Los programas continuos se adaptan mediante la supervisión pasiva, en modos sin agentes o con agentes de solo lectura cuando el entorno de tecnología operativa (OT) lo permita, con flujos de trabajo independientes de detección y corrección para los activos de OT, y políticas de exclusión explícitas con controles compensatorios.
- Sectores regulados (NIST, PCI DSS, HIPAA): CVM genera pruebas listas para auditoría, correlacionadas con los marcos de cumplimiento, mediante la recopilación continua de pruebas, la asignación automatizada de los resultados a los requisitos de control y la gestión documentada de las excepciones en el contexto normativo.
La norma de continuidad no cambia. La implementación se adapta.
Una vez abordada la complejidad del entorno, la pregunta final es cómo se integra CVM con el resto de elementos de su infraestructura de seguridad y de TI.
Integración de CVM en sus flujos de trabajo actuales de seguridad y TI
Un programa continuo se integra con sus herramientas de seguridad y de TI actuales, en lugar de sustituirlas. Su valor depende de la calidad de la integración.
- SIEM/SOAR: Los hallazgos sobre vulnerabilidades se integran en los flujos de trabajo de las operaciones de seguridad mediante alertas automatizadas para hallazgos críticos, contexto enriquecido en los eventos de SIEM y guías de actuación de SOAR que activan acciones de aplicación de parches y configuración.
- ITSM/gestión de incidencias: Las medidas correctoras se integran en el proceso de gestión de cambios del departamento de TI. En este caso se aplican los requisitos del SLA y de gestión de incidencias que se indican en la sección sobre deficiencias de coordinación.
- Procesos de CI/CD y DevOps: . En el caso de las organizaciones con ciclos de lanzamiento rápidos, las comprobaciones de vulnerabilidades se integran en los procesos de implementación, en lugar de realizarse tras la misma. En un modelo DevSecOps, el enfoque «shift-left» permite detectar problemas de seguridad durante la fase de desarrollo.
- Gestión de parches: Un programa continuo depende de un flujo de trabajo de gestión de parches que funcione correctamente para convertir los hallazgos en vulnerabilidades resueltas. La aplicación de parches al sistema operativo abarca la mayor parte de los activos; la aplicación de parches a las aplicaciones se centra en el software de terceros, los navegadores y las suites ofimáticas, que representan una parte significativa de las vulnerabilidades explotadas, pero que a menudo quedan excluidos de los flujos de trabajo centrados en el sistema operativo. Sin procesos estructurados de aplicación de parches en ambas capas, los datos de detección se acumulan sin que se produzcan resultados en materia de corrección.
- Gestión de terminales: La plataforma CVM comparte datos con la gestión de terminales o funciona en la misma infraestructura de agentes que esta, lo que elimina la necesidad de contar con agentes de análisis independientes y permite aplicar medidas correctivas desde la misma consola que detectó la vulnerabilidad.
Cómo contribuye Tanium a la gestión continua de vulnerabilidades
Todo lo anterior describe los requisitos que debe cumplir un programa continuo. El intervalo que transcurre entre la detección de una vulnerabilidad y la confirmación de que se ha resuelto es precisamente donde la mayoría de los programas pierden continuidad, y donde la arquitectura de la plataforma determina si el programa cumple realmente con lo prometido.
Las herramientas de detección identifican el problema. La corrección depende de un equipo distinto, una herramienta distinta y una lista de prioridades distinta. Esa transferencia de responsabilidades, que se repite en miles de resultados, es lo que convierte un programa «continuo» en uno periódico.
La plataforma de TI autónoma Tanium de subsana esa carencia al integrar la detección, la priorización, la corrección y la verificación en un único conjunto de datos. Los equipos de seguridad y de TI trabajan a partir de los mismos datos en tiempo real de los terminales, lo que elimina el retraso entre «lo hemos detectado» y «lo hemos solucionado». Cuando se publica un CVE crítico, Tanium está diseñado para proporcionar a los equipos una visibilidad casi instantánea de la corrección de vulnerabilidades ( ) en todo el entorno, con el fin de ayudarles a pasar directamente de la identificación a la aplicación de parches.
Desde el punto de vista operativo, esto se refleja a lo largo de todo el ciclo de vida del CVM:
- La información sobre los activos en tiempo real sustituye a los datos de análisis obsoletos: Tanium obtiene el estado actual directamente de los terminales, incluyendo dispositivos gestionados, no gestionados y aquellos que se vuelven a conectar tras estar sin conexión. Esto significa que el inventario de activos refleja lo que realmente existe en este momento, y no lo que existía en la última ventana de análisis.
- La corrección se lleva a cabo allí mismo donde se produce la detección: . Los resultados se incorporan directamente a los flujos de trabajo de aplicación de parches y configuración dentro de la misma plataforma. Sin creación manual de incidencias, sin retrasos en el traspaso de responsabilidades, sin ambigüedad en cuanto a quién es el responsable entre los departamentos de seguridad y de TI.
- La verificación en bucle cerrado confirma las correcciones, no solo las implementaciones: Tanium verifica la corrección de forma programada sin necesidad de programar un nuevo análisis. Los datos de estado basados en agentes confirman si la condición de vulnerabilidad persiste, por lo que una vulnerabilidad solo se marca como resuelta cuando se confirma la corrección en el terminal. No cuando se cierre la venta de entradas.
La implementación inicial de agentes en una flota de gran tamaño requiere planificación, sobre todo en entornos con un control de cambios estricto; sin embargo, la carga operativa continua se compensa al eliminar la necesidad de mantener múltiples herramientas de análisis y corrección.
No se trata de distinciones teóricas. Recovery Centers of America utilizó Tanium para detectar 400,000 vulnerabilidades en sus 2,200 terminales, vulnerabilidades que hasta entonces habían pasado desapercibidas. A continuación, Tanium ayudó a la organización a reducir esa cifra en un 80 % en poco más de dos semanas. RCA también aprovechó la integración de Tanium con ServiceNow para consolidar herramientas independientes e incorporar datos de los terminales en tiempo real a los flujos de trabajo de gestión de incidencias, gestión de cambios y gestión de activos. Lea el caso práctico «».
La arquitectura de plataforma unificada de Tanium aborda el problema estructural que impide que la mayoría de los programas de gestión de riesgos de ciberseguridad (CVM) alcancen una continuidad auténtica: la brecha entre la detección y la corrección verificada.
Al mantener datos en tiempo real sobre el estado de los terminales y permitir que los equipos de seguridad y de TI detecten, prioricen, corrijan y verifiquen desde un único sistema, Tanium elimina los retrasos en la coordinación y la sobrecarga que supone cambiar de herramienta, factores que convierten los programas «continuos» en programas esporádicos. Las organizaciones adquieren la capacidad operativa para determinar en cuestión de horas si una vulnerabilidad CVE recién revelada afecta a su entorno y para confirmar de forma automatizada cuándo se ha completado la corrección, las dos condiciones que distinguen a los programas continuos de los meramente aspiracionales.
Preguntas frecuentes sobre la gestión continua de vulnerabilidades
La verdadera continuidad depende de que se reduzca la brecha entre la detección y la corrección verificada. Las siguientes preguntas abordan las dificultades más habituales a las que se enfrentan los equipos a la hora de evaluar o desarrollar un programa de CVM.
¿En qué consiste la gestión continua de vulnerabilidades?
La gestión continua de vulnerabilidades es un proceso continuo y automatizado de detección, análisis, priorización y corrección de las deficiencias de seguridad en toda la infraestructura informática de una organización, que mantiene una visibilidad en tiempo real del estado de los activos y del estado de las vulnerabilidades, en lugar de basarse en ciclos de análisis periódicos.
¿Cómo se integra la gestión continua de vulnerabilidades con las herramientas de seguridad existentes?
La gestión continua de vulnerabilidades se integra con las herramientas de seguridad y de TI existentes a través de plataformas SIEM/SOAR para la automatización de alertas y flujos de trabajo de respuesta, sistemas ITSM/de gestión de incidencias para el seguimiento de las correcciones, plataformas de gestión de parches para la implementación y verificación automatizadas, y una infraestructura de gestión de terminales para eliminar agentes redundantes y consolidar la detección y la corrección en un único conjunto de datos.
¿Cómo encaja la gestión continua de vulnerabilidades en una estrategia de ciberseguridad?
La gestión continua de vulnerabilidades constituye la capa operativa que traduce la estrategia de seguridad en una reducción cuantificable del riesgo, al mantener una visibilidad en tiempo real de la superficie de ataque, priorizar las medidas correctivas en función de la explotabilidad y el contexto empresarial, y proporcionar una medición continu e de las tendencias de exposición que sirve de base para la toma de decisiones más amplias en materia de gestión de riesgos.
¿De qué manera la gestión continua de vulnerabilidades mejora el nivel de seguridad?
La gestión continua de vulnerabilidades mejora el nivel de seguridad al reducir el intervalo de tiempo entre la divulgación de una vulnerabilidad y su corrección verificada, al eliminar las lagunas de cobertura que generan los análisis periódicos y al proporcionar a la dirección pruebas cuantificables de la reducción del riesgo mediante métricas como el tiempo medio de detección ( ), el tiempo medio de corrección () y las tendencias de antigüedad de las vulnerabilidades.
¿Cómo se mide el éxito de la gestión continua de vulnerabilidades?
El éxito se mide en función de si el programa reduce de manera demostrable la exposición a lo largo del tiempo. Los seis indicadores clave mencionados anteriormente en este artículo (porcentaje de cobertura del análisis, tiempo medio hasta la detección, tiempo medio hasta la corrección, tasa de falsos positivos, tasa de excepciones y tasa de validación de la corrección) proporcionan la evidencia cuantificable. Un programa funciona cuando los responsables pueden observar una tendencia que muestra una reducción de los plazos de exposición, y no solo una instantánea de los tickets pendientes.
La gestión continua de vulnerabilidades no es una categoría de productos. Se trata de una norma operativa. La cuestión no es si sus herramientas de realizan análisis. La cuestión es si su programa puede indicar, en este mismo momento, qué activos están expuestos y si las correcciones de ayer han surtido efecto realmente. Esa es la diferencia entre «frecuente» y «continuo».
La plataforma unificada de Tanium proporciona a los equipos de seguridad y de TI la visibilidad en tiempo real y la verificación de ciclo cerrado necesarias para cumplir con ese estándar, eliminando las deficiencias de coordinación que impiden que la mayoría de los programas alcancen una continuidad auténtica. Concierte una demostración personalizada para ver cómo puede adaptarse a su entorno:.
