La corrección de vulnerabilidades es una de las disciplinas que plantean mayores exigencias operativas en el ámbito de la ciberseguridad. Sin embargo, la identificación de vulnerabilidades rara vez es el punto débil de los programas. Para muchas organizaciones, el verdadero reto radica en aplicar las medidas correctivas de forma coherente y verificar que las soluciones sean eficaces dentro de unos plazos muy ajustados.
Este artículo se centra en los mecanismos de ejecución: convertir una lista de prioridades en un plan de implementación, decidir cuándo aplicar soluciones definitivas y cuándo optar por medidas de mitigación, gestionar la automatización de forma segura, coordinar a los distintos equipos y confirmar que las correcciones han eliminado la vulnerabilidad. Comprender el proceso de corrección de vulnerabilidades de principio a fin, y no solo los pasos individuales, es lo que distingue a los programas que reducen el riesgo de forma sistemática de aquellos que generan actividad sin resultados cuantificables.
En qué consiste realmente la corrección de vulnerabilidades
Los distintos tipos de vulnerabilidades con los que se encuentra su programa —entre los que se incluyen fallos de software, configuraciones erróneas y otras vulnerabilidades de seguridad— requieren, cada uno de ellos, enfoques de corrección diferentes. La corrección de vulnerabilidades es el proceso de eliminar estas deficiencias de seguridad en los sistemas, las aplicaciones o las configuraciones tras su identificación y priorización.
Representa las fases de ejecución y validación del ciclo de vida de la gestión de vulnerabilidades , en las que los hallazgos priorizados se traducen en medidas correctivas y resultados validados. En el panorama general de la ciberseguridad, la corrección constituye el vínculo fundamental entre saber qué elementos están expuestos y reducir el riesgo.
Aunque en teoría resulta sencillo, es aquí donde la mayoría de los programas empiezan a perder terreno.
La corrección de fallos suele fracasar cuando los procesos de identificación, priorización y ejecución no están integrados. Su escáner ha detectado una vulnerabilidad CVE crítica. El hallazgo aparece en un panel de control de seguridad, mientras que el departamento de operaciones de TI trabaja con un sistema de gestión de incidencias independiente, sin que exista una transferencia coherente de información entre ambos. Pasan los días. La vulnerabilidad sigue sin estar solucionada, y ese retraso amplía directamente el margen de tiempo de que disponen los atacantes para aprovecharla.
El traspaso de responsabilidades entre TI y SecOps supone otro punto de fallo habitual. Los equipos de seguridad identifican y establecen prioridades. El departamento de operaciones de TI es el responsable de los sistemas y se encarga de aplicar las correcciones. Sin una visión común tanto del estado de la implementación como de los resultados de la validación, los tickets se cierran prematuramente en ambas partes. Sin una coordinación adecuada, incluso las vulnerabilidades que se han priorizado correctamente pueden seguir expuestas.
Además, existe la brecha de validación. Se implementa un parche. Se cierra la venta de entradas. Pero, ¿ha desaparecido realmente la vulnerabilidad del terminal, o sigue siendo accesible o explotable a través de otra vía? Muchos programas marcan los incidencias como resueltas una vez que se han tomado medidas, y no tras comprobar que la solución ha logrado el resultado previsto.
Una vez que se han priorizado las vulnerabilidades, el problema pasa de consistir en decidir qué es lo importante a aplicar las soluciones de forma fiable y a gran escala.
Cómo convertir una lista de vulnerabilidades priorizadas en un plan de corrección
Dispone de una lista de vulnerabilidades clasificadas por puntuación. El siguiente paso consiste en convertir esa lista en una acción coordinada.
Decisiones sobre la secuencia
Las puntuaciones de prioridad sirven de referencia para la secuenciación, pero no la determinan. Antes de la secuenciación, también conviene filtrar los falsos positivos: los resultados del escáner que no reflejan la exposición real en su entorno aumentan el volumen de trabajo pendiente y desvían los esfuerzos de corrección. Una vulnerabilidad con una puntuación CVSS de 9.8 en un servidor de pruebas aislado tiene menor prioridad en su cola de implementación que una vulnerabilidad con una puntuación CVSS de 7.5 en un controlador de dominio.
La priorización combina la gravedad con la importancia crítica de los activos, la exposición (por ejemplo, sistemas conectados a Internet frente a sistemas internos), las señales de explotación activa y las limitaciones operativas, como las franjas horarias de mantenimiento y las dependencias del sistema. Se trata, en esencia, de una evaluación de riesgos aplicada a nivel de vulnerabilidad, en la que se sopesa la probabilidad de que se produzca un ataque frente al posible impacto empresarial de un ataque que tenga éxito.
La información sobre amenazas , procedente de fuentes como el catálogo de «Vulnerabilidades explotadas conocidas» (KEV) de la CISA y las puntuaciones del «Sistema de puntuación de predicción de exploits» (EPSS), ayuda a identificar qué vulnerabilidades se están explotando activamente en el entorno real. Los resultados de su escáner deben cruzarse con una base de datos de vulnerabilidades, como la Base de Datos Nacional de Vulnerabilidades (NVD), para garantizar que los metadatos CVE, las puntuaciones de gravedad y las recomendaciones de corrección estén actualizados y se interpreten con precisión en su contexto. Las vulnerabilidades críticas que se encuentran en la intersección entre «explotadas activamente» y «en un activo crítico» deben ocupar el primer lugar en su lista de prioridades.
El catálogo KEV de la CISA establece plazos de corrección para los organismos federales; muchas de las vulnerabilidades críticas deben subsanarse dentro de unos plazos definidos en función del riesgo de explotación.
El mero hecho de establecer prioridades no garantiza la eficiencia en la ejecución. Para que los programas de corrección sean eficaces, es necesario establecer una correlación entre los resultados de las evaluaciones de vulnerabilidad y los parches, los cambios de configuración o las actualizaciones específicos necesarios para subsanarlas. Sin esa conexión, los equipos suelen perder tiempo a la hora de convertir los CVE en soluciones prácticas. Las plataformas que vinculan directamente los datos sobre vulnerabilidades con las medidas correctivas, como —que identifica los parches que faltan— —vinculados a vulnerabilidades activas—, pueden reducir las fricciones entre los equipos de seguridad y de TI, y acelerar el tiempo de resolución al convertir los riesgos priorizados en tareas ejecutables dentro del mismo flujo de trabajo.
Una vez que se han tomado las decisiones relativas a la secuencia, la planificación de la ejecución pasa a centrarse en la asignación de responsabilidades y la dotación de recursos.
Asignación de recursos y titularidad
Antes de que se implemente el primer parche, aclare quién es el responsable de la ejecución en cada nivel de prioridad. Las vulnerabilidades de día cero constituyen el nivel de mayor prioridad y suelen requerir un flujo de trabajo acelerado con plazos reducidos. Los elementos de nivel crítico suelen requerir un proceso acelerado de aprobación de cambios , y recursos específicos. Es posible que las tareas de nivel medio se agrupen en las franjas horarias de mantenimiento semanales.
Cada elemento de su cola suele generar o asociarse a un ticket de ITSM en el que ya figuran el alcance, los activos afectados, el plazo y los requisitos de aprobación. Ese ticket se convierte en el principal punto de coordinación entre los servicios de seguridad y las operaciones de TI. En el caso de los incidencias de alta gravedad, también sirve como registro de comunicación para las partes interesadas que necesitan conocer el progreso y los plazos de la corrección.
Ejemplo de flujo de trabajo: . Una vulnerabilidad CVE con puntuación CVSS 9.8 aparece en la lista KEV de la CISA en 9 a.m. . La clasificación de prioridad la asigna al nivel «crítico». Se genera automáticamente un ticket de ITSM con la lista de activos afectados. El Anillo 1 se implementa en 50 terminales piloto. Se lleva a cabo un nuevo escaneo de validación con una periodicidad definida, que suele oscilar entre unas horas y un día, dependiendo de las herramientas y la escala. Ring 2 se implementa en el entorno de producción. Para dar por concluido el proceso, se requiere evidencia de auditoría que confirme que se ha subsanado el problema.
Una vez establecido el plan de implementación, la siguiente decisión consiste en determinar qué tipo de respuesta se adapta mejor a cada vulnerabilidad.
Corrección, mitigación o excepción
No todas las vulnerabilidades reciben la misma respuesta. La decisión depende de la disponibilidad de soluciones, de las limitaciones operativas y de la tolerancia al riesgo.
| Tipo de respuesta | Para qué sirve | Cuándo utilizarlo |
|---|---|---|
| Remediación | Elimina la vulnerabilidad desde su origen | Existe un parche del proveedor que puede implementarse dentro de los plazos establecidos en su SLA |
| Mitigación | Reduce la vulnerabilidad a los ataques sin eliminar la causa principal | Aún no hay ningún parche disponible, o su implementación requiere pruebas más exhaustivas |
| Excepción | Acepta formalmente el riesgo sin subsanarlo ni mitigarlo | Está previsto el desmantelamiento del sistema, o bien los controles compensatorios reducen el riesgo a niveles aceptables |
La elección del tipo de respuesta adecuado es precisamente donde los programas suelen fallar. Evite recurrir por defecto a la aplicación de parches cuando las limitaciones operativas lo hagan inviable, y evite recurrir por defecto a excepciones cuando exista una solución.
La corrección es la solución más completa cuando resulta viable, ya que elimina la vulnerabilidad en su origen. Esto incluye la aplicación de parches, el refuerzo de las configuraciones o la sustitución de software que ya no recibe soporte, pero también requiere coordinación, pruebas y una disciplina en la implementación para tener éxito a gran escala.
Las medidas de mitigación permiten ganar tiempo. Reduce la vulnerabilidad sin eliminar el problema subyacente, lo que limita el alcance del impacto mientras los equipos esperan un parche o completan la validación. Esto lo hace útil desde el punto de vista operativo, pero arriesgado si se considera como una solución a largo plazo.
Las excepciones generan deuda técnica. Aceptar una vulnerabilidad traslada la responsabilidad a los órganos de gobierno: documentar la justificación, mantener controles compensatorios y revisar la decisión a lo largo del tiempo. Sin esa disciplina, los riesgos asumidos tienden a acumularse sin que uno se dé cuenta.
Llevar a cabo medidas correctoras a gran escala
La implementación de correcciones en miles de terminales sin provocar interrupciones del servicio requiere un enfoque disciplinado, no solo herramientas.
Aplicación de parches de los proveedores
La implementación de parches sigue un modelo por fases. Obtenga el parche, prepárelo para su distribución y pruébelo en un entorno que no sea de producción antes de proceder a su implantación generalizada. Una gestión eficaz de los parches de garantiza que este proceso sea repetible y auditable, y no se limite a reaccionar ante las vulnerabilidades CVE individuales a medida que surgen.
El grupo piloto detecta los problemas en una fase temprana. Si un parche altera una dependencia de una aplicación, afecta a su funcionamiento o provoca una disminución del rendimiento, lo que desea es saberlo en 50 terminales, no en 5,000. Los intervalos entre los toques le permiten observar las señales de estabilidad antes de continuar.
Los terminales desconectados o sin conexión a Internet plantean un reto específico. Muchas plataformas permiten a los equipos definir medidas correctivas con antelación, pero su ejecución sigue dependiendo de que el terminal se vuelva a conectar y reciba dichas instrucciones. Hasta que se restablezca la conexión, los puntos finales expuestos siguen estando en riesgo.
Corrección de errores de configuración
La corrección de la configuración va más allá de «cambiar el ajuste». Está detectando desviaciones respecto a su línea de referencia, creando scripts o aplicando la corrección mediante una política, y verificando que el cambio se mantenga tras las aplicaciones posteriores de la política.
Entre los objetivos habituales se incluyen:
- Credenciales predeterminadas: . Nombres de usuario y contraseñas configurados de fábrica que los atacantes saben que deben probar en primer lugar.
- Puertos abiertos innecesarios: Puntos de acceso a la red que amplían la superficie de ataque
- Controles de acceso excesivamente permisivos: Configuraciones que conceden un acceso más amplio del que necesitan los usuarios
Cada uno de ellos representa un patrón de vulnerabilidad habitual que los atacantes buscan y aprovechan de forma activa, lo que convierte al refuerzo de la configuración en una de las medidas correctivas más eficaces de las que disponen la mayoría de los equipos. Las herramientas de gestión de la configuración aplican los cambios a gran escala, pero la verificación confirma que dichos cambios se han aplicado correctamente.
Actualización o sustitución de software al final de su ciclo de vida
El software al final de su ciclo de vida (EOL) ya no recibe parches de seguridad de . La corrección consiste en actualizar a una versión compatible, sustituir el software o retirarlo por completo del servicio. Esto se aplica tanto a los componentes comerciales como a los de código abierto. En muchos entornos existen bibliotecas de código abierto que han llegado al final de su vida útil (EOL) y que están integradas en las aplicaciones, por lo que es fácil pasarlas por alto durante los ciclos habituales de aplicación de parches.
La remediación de EOL es compleja desde el punto de vista operativo. El mapa de dependencias muestra qué elementos dejan de funcionar al actualizar. Las pruebas garantizan que la nueva versión funcione correctamente en su entorno. La aprobación por parte de la empresa confirma el plazo para el cambio en la producción. A pesar de su complejidad, las vulnerabilidades relacionadas con el fin de vida útil (EOL) constituyen objetivos de corrección de gran impacto, ya que representan una exposición persistente.
Implantación de controles compensatorios
Cuando no es posible aplicar de inmediato medidas correctoras directas, los controles compensatorios reducen el riesgo mientras tanto. Esto reviste especial importancia en el caso de los sistemas que almacenan o tratan datos sensibles, en los que una exposición no mitigada puede acarrear consecuencias normativas y empresariales que van más allá del riesgo técnico. Medidas de control como la segmentación de la red, las restricciones de acceso y una supervisión reforzada contribuyen a limitar el movimiento lateral, reducir la superficie de ataque y mejorar la detección en caso de que se produzca una explotación.
Aunque los controles compensatorios suelen ser temporales, en algunos casos pueden mantenerse a largo plazo y requieren un seguimiento continuo para que sigan siendo eficaces a medida que cambia el entorno. Es importante realizar un seguimiento de ellas junto con las excepciones, revisarlas periódicamente y sustituirlas por soluciones definitivas cuando se disponga de una corrección.
Gestión de la corrección automatizada
La automatización agiliza la ejecución. Además, puede propagar errores de configuración o fallos en la aplicación de parches a miles de terminales en cuestión de minutos. La respuesta no es reducir la automatización. Se trata de una automatización regulad :: la velocidad se equilibra con controles que detectan los problemas antes de que alcancen la escala de producción.
Puntuación de confianza y requisitos de implementación
La puntuación de confianza ofrece información contextual basada en datos para ayudar a los equipos a evaluar la seguridad de un parche o un cambio de configuración antes de su implementación. En lugar de tomar decisiones de forma automática, ayuda al operador a formarse una opinión al poner de manifiesto indicadores como el éxito de implementaciones anteriores, los resultados en materia de estabilidad y el impacto en el rendimiento.
Los cambios con mayor nivel de fiabilidad pueden ser mejores candidatos para una implantación más amplia, mientras que los cambios con menor nivel de fiabilidad suelen requerir una validación adicional, pruebas o una aprobación explícita conforme a la política de la organización.
La implementación basada en anillos como estrategia de gestión de riesgos
Implementación en anillos : se lleva a cabo la implantación en grupos de terminales cada vez más amplios. Un patrón típico: «canary» (5–10 puntos finales), «pilot» (50–200) y «broad» (el resto).
El tiempo de espera entre los timbres es importante. Está prestando atención a las tasas de fallo de las actualizaciones, a los errores de compatibilidad de las aplicaciones y a los indicadores de estabilidad de los terminales. Los umbrales de fallo por anillo definen cuándo se debe detener o revertir el proceso. Unos criterios de escalamiento claros determinan quién tiene la autoridad para seguir adelante con una implementación o detenerla.
La implementación en anillo es el mecanismo que contribuye a que la automatización sea más segura a escala empresarial.
Ejecución basada en un manual de estrategias
Los guiones definen la lógica de corrección automatizada, incluyendo qué tipo de corrección se debe aplicar, cuál debe ser el alcance de la misma y cómo avanza la implementación en los distintos grupos de terminales.
La ejecución suele incluir fases de aprobación e implementaciones por etapas, lo que permite a los equipos revisar los cambios y validar los resultados antes de proceder a una implantación más amplia.
La ejecución del manual de estrategias también puede integrarse con los flujos de trabajo existentes, incluidos los procesos de gestión de incidencias y de gestión de cambios, de modo que las medidas correctivas y las aprobaciones se adapten a la forma en que los equipos ya operan.
El problema de la coordinación entre TI y SecOps
El hecho de saber qué hay que arreglar y cómo hacerlo no garantiza que se arregle. El fallo suele producirse en el traspaso de responsabilidades entre el departamento de seguridad y el de operaciones de TI.
Dónde falla la coordinación
Los equipos de seguridad identifican y priorizan las vulnerabilidades. Los equipos de operaciones de TI se encargan de los sistemas y llevan a cabo las correcciones. Sin una visión común del progreso de la implementación, los resultados de la validación y la responsabilidad de los responsables, las medidas correctivas pueden parecer completadas antes de que se hayan confirmado realmente las correcciones, lo que deja vulnerabilidades sin resolver y las pruebas de auditoría incompletas.
Entre los puntos de fallo concretos se incluyen:
- El departamento de seguridad cierra un ticket cuando se «recomienda» una solución: . El departamento de TI aún no la ha implementado.
- El departamento de TI cierra un ticket cuando se «implementa» un parche: . El departamento de seguridad aún no ha comprobado que la corrección haya solucionado la vulnerabilidad.
- No hay cola compartida: Security funciona a partir de un escáner de vulnerabilidades de . El departamento de TI trabaja con un sistema de gestión de incidencias de gestión de servicios de TI (ITSM). No existe ninguna traducción automática entre ambos idiomas.
- Discrepancia en el SLA: Security espera que las vulnerabilidades críticas (CVE) se corrijan en un plazo de 48 horas. El departamento de TI cuenta con ventanas de gestión del cambio que se llevan a cabo semanalmente.
El traspaso de responsabilidades entre los equipos de TI y de operaciones de seguridad (SecOps) es el punto en el que muchos programas de corrección pierden terreno, no porque los equipos carezcan de buenas intenciones, sino porque los flujos de trabajo no están coordinados.
La integración de ITSM como capa de coordinación
La integración de los flujos de trabajo de ITSM desempeña un papel fundamental a la hora de subsanar las deficiencias en los traspasos. Los hallazgos de vulnerabilidades pueden configurarse para generar o vincularse a tickets de ITSM con el alcance, la prioridad y el plazo ya rellenados. El estado de la implementación se transmite desde el departamento de TI al equipo de seguridad.
La visibilidad compartida no es opcional en los programas consolidados. Ambos equipos pueden ver en tiempo real el estado de la corrección de una vulnerabilidad. Los procesos de aprobación abarcan a ambos equipos: quién aprueba antes de la implementación y quién lo confirma después.
Modelos de propiedad compartida
Los programas de alto rendimiento establecen de forma explícita las normas de rendición de cuentas. Un acuerdo de nivel de servicio (SLA) sobre la corrección de incidencias, acordado entre los responsables de SecOps y de TI, define las expectativas. Los procedimientos de escalado sirven para abordar los incumplimientos de plazos. Una única fuente de información fiable permite realizar un seguimiento del estado de las medidas correctivas.
Las métricas revelan dónde se producen los cuellos de botella. El tiempo medio de resolución (MTTR), analizado por fase (desde la detección hasta la apertura del ticket, desde la apertura del ticket hasta la implementación y desde la implementación hasta la validación), permite determinar si los retrasos se deben a la identificación o a la ejecución.
Comprobación de que la medida correctiva ha surtido efecto
El hecho de que se haya implementado un parche no implica necesariamente que la vulnerabilidad se haya solucionado. La validación permite confirmar si la exposición se ha reducido o eliminado realmente, y no solo si se ha abordado en el proceso.
Muchos programas corrigen las vulnerabilidades una vez que se han tomado medidas, y no tras confirmar que la solución ha funcionado. Esa distinción genera una confianza errónea en el nivel de seguridad y da lugar a lagunas en las pruebas de auditoría.
La validación suele requerir un análisis de vulnerabilidades de los terminales afectados o la verificación del estado de los mismos una vez aplicada la corrección. Para aplicar el parche, compruebe que el CVE ya no aparezca en los análisis y que la vulnerabilidad ya no esté presente ni sea accesible. En el caso de los cambios de configuración, compruebe que la configuración se haya conservado y que no haya sido anulada por una aplicación posterior de la política.
En entornos distribuidos, compruebe todos los activos afectados, y no solo una muestra, para garantizar que la corrección se haya aplicado de forma exhaustiva. En otros entornos, la validación también requiere confirmar que la medida correctiva haya abordado directamente la vulnerabilidad original, y no solo que se haya producido un cambio.
La distinción es importante: «acción realizada» se refiere a la finalización del proceso. «La reducción efectiva del riesgo» es el resultado que realmente importa en lo que respecta al cumplimiento normativo, las pruebas de auditoría y el nivel general de seguridad.
Una vez establecida la validación, la última cuestión es cómo evaluar si su programa está funcionando.
Evaluación del estado de los programas de rehabilitación
Las métricas le indican si la aplicación de las medidas correctivas está dando resultado y en qué aspectos debe intervenir cuando no sea así.
Tiempo medio de resolución
El MTTR mide el tiempo transcurrido desde la detección de la vulnerabilidad o la creación del ticket (según la definición del programa) hasta la corrección validada, clasificado por nivel de gravedad.
Un aumento del MTTR en los elementos de nivel crítico indica que se ha producido un fallo en algún punto del flujo de trabajo. La comparación entre el tiempo transcurrido desde la detección del problema hasta la apertura del ticket, el tiempo transcurrido desde la apertura del ticket hasta la implementación y el tiempo transcurrido desde la implementación hasta la validación permite determinar si el retraso se debe a la priorización, a la ejecución o a la validación. El MTTR registrado a nivel de programa no permite identificar dónde se producen los retrasos. Segmente por fase.
Remediation coverage rate
La tasa de cobertura mide el porcentaje de vulnerabilidades identificadas que se han subsanado dentro del plazo que haya establecido.
Un MTTR elevado, junto con una tasa de cobertura elevada, indica una lentitud sistemática, pero no un fallo en la clasificación de casos. Una tasa de cobertura baja indica un fallo en el establecimiento de prioridades o limitaciones en la capacidad de los recursos. Realice un seguimiento de la tasa de cobertura por categoría de activos. El hecho de que los activos críticos reciban una cobertura inferior a la de los terminales estándar pone de manifiesto un problema de priorización.
Índice de cumplimiento del SLA
El cumplimiento del SLA mide el respeto de los plazos de corrección establecidos según el nivel de gravedad. Los objetivos de nivel de servicio (SLO) habituales son los siguientes: «crítico» en un plazo de 24–48 horas, «alto» en un plazo de 7–14 días y «medio» en un plazo de 30 días.
Los patrones de incumplimiento del SLA, clasificados por niveles de gravedad, permiten identificar en qué nivel de su flujo de trabajo de ejecución hay una falta de recursos o una gestión deficiente. El cumplimiento del SLA es el indicador principal en las auditorías de cumplimiento. Los marcos normativos y los mandatos de seguridad interna suelen establecer plazos específicos para la corrección de incidencias en función del nivel de gravedad. Lo que cumple dichos requisitos es disponer de pruebas documentadas tanto de la implementación como de la validación, y no solo del cierre del ticket.
El MTTR le indica lo lento que es. La tasa de cobertura le indica en qué medida ha completado el proceso. El cumplimiento del SLA le indica en qué aspectos no está cumpliendo sus compromisos. Cualquier programa de corrección que funcione sin estos tres elementos está midiendo los resultados, no el estado de la ejecución. Esa brecha se agrava con el paso del tiempo, ya que continuamente se descubren nuevas vulnerabilidades.
Cómo ayuda Tanium a acelerar la corrección de vulnerabilidades
Las deficiencias en la ejecución que se describen en este artículo —entre las que se incluyen la fragmentación de las herramientas, los retrasos en los traspasos y una validación limitada— suelen deberse a flujos de trabajo inconexos y a una visibilidad incompleta de los terminales.
La plataforma de TI autónoma Tanium de ayuda a integrar la identificación de vulnerabilidades, las medidas correctivas y los flujos de trabajo de validación mediante la visibilidad en tiempo real de los terminales y el control de los mismos, lo que reduce la dependencia de herramientas fragmentadas.
En la práctica, esto se manifiesta a través de capacidades* tales como:
- Visibilidad en tiempo real de los terminales, combinada con evaluaciones bajo demanda de vulnerabilidades y configuraciones: . Abarca sistemas operativos, aplicaciones y configuraciones, con el respaldo de bibliotecas de contenidos que se actualizan periódicamente.
- Alertas en tiempo real sobre vulnerabilidades críticas y emergentes: . Se envían a través de Tanium Guardian , con el respaldo de las investigaciones del Equipo de Respuesta a Emergencias de Vulnerabilidades (VERT) dentro de la consola de Tanium, y suelen incluir medidas correctivas recomendadas y orientación.
- Flujos de trabajo de corrección integrados: Actúe ante las vulnerabilidades detectadas e inicie flujos de trabajo de corrección dentro de la misma plataforma para reducir la necesidad de cambiar de una herramienta a otra
- Puntuaciones de confianza: Utilice indicadores como las tasas de éxito en la instalación, los resultados de estabilidad y el impacto en el rendimiento para fundamentar las decisiones sobre la aplicación de parches antes de proceder a una implantación más amplia
- Implementación progresiva por fases: Comienza con un pequeño grupo de terminales, comprueba los resultados y amplía la implementación a medida que cada fase cumple los criterios de éxito.
- Guías prácticas de automatización «low-code» y «no-code»: Utiliza Tanium Automate para coordinar los flujos de trabajo de los terminales y de corrección bajo la supervisión de los operadores
- Funcionalidades de validación tras la implementación: . Ayudan a verificar el estado de los parches e identificar los sistemas en los que las medidas correctivas no se han aplicado según lo previsto.
- Integración con , ServiceNow y otros flujos de trabajo clave: . Proporciona a los equipos de TI y de seguridad acceso a datos coherentes sobre los terminales dentro de los procesos existentes.
- Casos de uso de la evaluación de la configuración y la gestión de vulnerabilidades: . En consonancia con marcos normativos comunes como PCI, HIPAA y SOX
- Visibilidad de la corrección: Muestra las vulnerabilidades que pueden corregirse, los parches que faltan y el estado de la implementación para ayudar a los equipos de seguridad y operaciones a realizar un seguimiento del progreso de la corrección y coordinar su ejecución
*Las capacidades y los resultados descritos se basan en la documentación de los productos de Tanium, en casos prácticos de clientes validados y en el uso real. Los resultados reales pueden variar en función del entorno de implementación, la configuración y el grado de madurez de la organización.
Con Tanium, la validación puede integrarse en los mismos flujos de trabajo que se utilizan para aplicar medidas correctivas. Los equipos pueden verificar el estado de los terminales —por ejemplo, el estado de instalación de los parches o los cambios de configuración— y volver a evaluar la exposición para determinar si las medidas correctivas han logrado el resultado previsto.
Ese cambio, que consiste en pasar de hacer un seguimiento de las medidas de remediación a confirmar la reducción del riesgo, es lo que distingue a los programas maduros de los programas reactivos.
La mayoría de las herramientas de cumplimiento normativo le indican qué es lo que falla. Son pocos los que le indican qué hacer al respecto, y casi ninguno le permite actuar desde la misma pantalla. La visibilidad de las medidas correctivas en Tanium Comply cambia esta situación. En la charla técnica n.º 121 de « » (), Margie Sills, arquitecta de dominio de riesgo y cumplimiento normativo de Tanium, explica cómo esta función asocia las vulnerabilidades con parches aplicables, clasificados según su impacto en la reducción del riesgo, y cómo los equipos pueden pasar de la detección a la corrección sin necesidad de cambiar de herramienta ni esperar a que se produzca un traspaso de tareas.
Preguntas frecuentes sobre la corrección de vulnerabilidades
La ejecución de las medidas correctoras plantea cuestiones prácticas que no encajan perfectamente en la documentación del proceso. A continuación se recogen las preguntas más habituales que suelen plantear los equipos a la hora de traducir los resultados de los análisis en medidas concretas.
Mi escáner de vulnerabilidades ha detectado cientos de CVE. ¿Por dónde empiezo?
La puntuación CVSS por sí sola no es suficiente para establecer un orden de prioridad. Un CVSS 7.5 en su controlador de dominio es un objetivo de ejecución de mayor prioridad que un CVSS 9.0 en un sistema de pruebas aislado.
Filtre su lista según dos criterios: el estado de explotación activa (señales KEV y EPSS de la CISA) y la importancia de los activos. Los elementos que se encuentran en la intersección entre «explotados activamente en el entorno real» y «en un activo crítico» conforman su primera cola de ejecución.
¿Por qué la puntuación CVSS no es suficiente para establecer las prioridades a la hora de decidir qué corregir primero?
El CVSS mide la gravedad básica y la gravedad contextual en condiciones definidas, pero no tiene en cuenta la explotación activa ni el contexto empresarial. Evalúa la explotabilidad y el impacto en condiciones ideales para el atacante, sin tener en cuenta si la vulnerabilidad se está explotando activamente en la red ni si el sistema afectado es relevante para su empresa.
Un CVSS 9.8 en un software que no se está ejecutando en su entorno tiene menor prioridad que un CVSS 6.5 en un sistema que está siendo objeto de ataques activos y que está conectado a Internet. Una secuencia de ejecución eficaz combina el CVSS con el EPSS (probabilidad de explotación) y la importancia de los activos, y no se basa únicamente en la puntuación de gravedad.
¿En qué se diferencia la remediación de la mitigación?
La corrección aborda la vulnerabilidad en su origen mediante parches o ajustes de configuración, mientras que la mitigación reduce temporalmente la posibilidad de que se aproveche la vulnerabilidad mediante controles como la segmentación de la red o las restricciones de acceso, hasta que se disponga de una solución permanente.
¿Cuál es un ejemplo de corrección de una vulnerabilidad?
La aplicación de un parche proporcionado por el proveedor para corregir una vulnerabilidad CVE conocida, el refuerzo de una regla de cortafuegos mal configurada o la actualización de un software al final de su ciclo de vida a una versión compatible se consideran medidas correctivas, ya que abordan la vulnerabilidad en su origen, en lugar de limitarse a reducir la exposición.
La corrección de vulnerabilidades no consiste únicamente en subsanarlas, sino en confirmar que el riesgo se ha reducido efectivamente. Los programas que integran la priorización, la ejecución y la validación en un flujo de trabajo continuo « » están mejor posicionados para reducir los periodos de exposición y mantenerse al día con la evolución de las amenazas cibernéticas.
Concierte una demostración para descubrir cómo puede optimizar y validar la corrección de vulnerabilidades en todo su entorno con Tanium.
