La gestión de vulnerabilidades es el proceso que decide si tu organización detecta una exposición antes o después de que se convierta en un problema. El informe ColCERT IN-20260325-029 documentó en Colombia lo que ocurre cuando este proceso no existe. Este artículo te explica cómo construirlo.
¿Por qué el parcheo reactivo no es suficiente?
La gestión de vulnerabilidades no es aplicar parches cuando ocurre un incidente o cuando alguien lo recuerda. Eso es apagar incendios.
Un programa de gestión de vulnerabilidades, conocido como VMP por sus siglas en inglés, es un ciclo continuo y sistemático que responde tres preguntas de forma permanente:
¿Qué activos tienes expuestos?
¿Cuáles tienen vulnerabilidades conocidas?
¿Cuáles vas a remediar primero y en qué plazo?
Sin respuesta activa a esas tres preguntas, tu equipo opera a ciegas. El informe ColCERT documentó que el 96% de las entidades afectadas carecía de este proceso, y todas las vulnerabilidades explotadas tenían parche disponible antes del compromiso.
Fase 1. Inventario de activos: el punto de partida de toda gestión de vulnerabilidades
El error más común al arrancar un programa de gestión de vulnerabilidades es comenzar por las herramientas de escaneo. Antes de escanear, necesitas saber qué vas a escanear.
Construye tu inventario de activos. No tiene que ser perfecto desde el primer día, tiene que existir.
Documenta como mínimo:
Nombre del sistema o aplicación
Versión en producción
Sistema operativo y versión
Estado de soporte del fabricante (activo, EOL, fin de soporte próximo)
Responsable técnico
Un spreadsheet funciona para empezar. Lo importante es que el inventario sea mantenido, no que sea elegante.
¿Por qué es la condición previa de todo lo demás? Porque no puedes priorizar vulnerabilidades de sistemas que no sabes que existen. El informe ColCERT identificó instancias de SharePoint 2013 y sistemas con Log4Shell activos años después de su publicación. Esos sistemas no estaban en el radar de nadie.
Fase 2. Escaneo continuo: la diferencia entre una fotografía y visibilidad real
Con inventario en mano, el siguiente paso es identificar vulnerabilidades activas. Tienes dos enfoques complementarios, y ambos deben ser continuos, no puntuales.
Escaneo pasivo
Antes de tocar tus propios sistemas, haz lo que haría un atacante: reconocimiento desde fuentes públicas. A través de motores de búsqueda especializados, registros de certificados públicos y los headers HTTP de tus dominios puedes revelar versiones de software, subdominios expuestos y configuraciones visibles públicamente. Si lo puede ver un atacante, lo tienes que ver tú primero, y de forma continua.
Escaneo activo
Existen soluciones de escaneo activo, tanto comerciales como open source, que identifican CVEs en tus sistemas de forma directa. Lo esencial no es la solución que elijas, es que el escaneo sea continuo. Un escaneo puntual te da una fotografía. Un escaneo continuo te da visibilidad real. La diferencia entre los dos es la diferencia entre saber lo que tenías hace seis meses y saber lo que tienes hoy.
Cada vulnerabilidad identificada llega con una puntuación CVSS. Úsala como punto de partida para priorizar, no como criterio absoluto. Una vulnerabilidad CVSS 9.0 en un sistema interno sin exposición a internet puede ser menos urgente que una CVSS 7.0 en un endpoint público con datos sensibles.
Qué hacer con los resultados
El contexto importa tanto como la puntuación CVSS.
Fase 3. Cómo priorizar vulnerabilidades con criterio real
Tu equipo no puede remediar todo al mismo tiempo. Un programa de gestión de vulnerabilidades necesita un criterio claro y reproducible para decidir el orden:
Prioridad crítica, remediar en 24 a 72 horas
CVEs con CVSS mayor o igual a 9.0 en sistemas expuestos a internet o con datos sensibles.
Prioridad alta, remediar en 7 días
CVEs con CVSS entre 7.0 y 8.9 en sistemas de producción con acceso de usuarios o integraciones externas.
Prioridad media, remediar en 30 días
CVEs con CVSS entre 4.0 y 6.9 en sistemas internos sin exposición directa.
Regla práctica: si el CVE tiene exploit público disponible y tu sistema está expuesto, trátalo como crítico independientemente de la puntuación CVSS.
Fase 4. Remediación y seguimiento: donde la mayoría de los programas fracasan
Identificar y priorizar vulnerabilidades no sirve de nada si la remediación no ocurre. Este es el punto donde más programas de gestión de vulnerabilidades fracasan, no por falta de voluntad técnica, sino por ausencia de proceso formal.
Define SLAs internos y cúmplelos: los mismos plazos que exiges a proveedores aplican internamente
Registra cada vulnerabilidad como un ticket: con responsable, fecha límite y estado visible en tu sistema habitual
Gestiona las excepciones formalmente: con fecha de revisión y medida compensatoria documentada
Una excepción no documentada es una vulnerabilidad ignorada.
Fase 5. Gestión de vulnerabilidades en proveedores externos
Uno de los hallazgos más relevantes del informe ColCERT fue el compromiso de múltiples entidades a través de un proveedor externo común. Cuando el proveedor falló, el impacto se propagó simultáneamente a todas las organizaciones que dependían de él.
Tu programa de gestión de vulnerabilidades tiene que extenderse a tu cadena de suministro tecnológica. En los contratos incluye como mínimo:
- SLA de parcheo explícito: crítico en 24-72h, alto en 7 días, medio en 30 días
- Notificación de incidentes en máximo 24 horas desde la detección
- Derecho de auditoría de seguridad al menos una vez al año
- Responsabilidad contractual por brechas derivadas de negligencia en parcheo
- Prohibición de credenciales compartidas entre distintos clientes del proveedor
Fase 6. Métricas para comunicar el programa a dirección
Un programa de gestión de vulnerabilidades sin visibilidad ejecutiva no sobrevive. Tres métricas que cualquier director puede entender:
Tiempo medio de remediación (MTTR): cuánto tardas en promedio en cerrar una vulnerabilidad. Debe reducirse con el tiempo.
Vulnerabilidades críticas abiertas: cuántas con CVSS mayor o igual a 9.0 tienes activas hoy. El objetivo es tendencia sostenida hacia cero.
Cobertura del inventario: qué porcentaje de tus sistemas está siendo escaneado activamente.
Reporta estos tres números mensualmente. No como alarma, como evidencia de que el programa avanza.
Por dónde empezar hoy con tu programa de gestión de vulnerabilidades
Si tu organización no tiene un VMP activo, el punto de entrada no es el framework más completo ni la solución más sofisticada. Es este orden:
- Levanta el inventario de activos en producción: software, versión, estado de soporte
- Identifica qué sistemas tienen exposición directa a internet
- Realiza un reconocimiento pasivo sobre esos sistemas: registros de certificados, motores especializados y headers HTTP
- Prioriza los CVEs con CVSS mayor o igual a 9.0 y aplica los parches disponibles
- Documenta el proceso y asigna un responsable
Ese es el ciclo mínimo viable. No es perfecto, es suficiente para estar en una posición significativamente mejor que el 96% de las entidades documentadas en el informe ColCERT.
Conclusión: la gestión de vulnerabilidades convierte el riesgo en algo gestionable
La diferencia entre una organización expuesta y una resiliente no siempre es presupuestal. En muchos casos es simplemente tener un ciclo activo de gestión de vulnerabilidades: con inventario actualizado, escaneo continuo, priorización clara y responsables que cierran lo que se abre.
Un VMP no elimina el riesgo. Lo hace gestionable. Y esa diferencia, en la práctica, lo cambia todo.
Referencias y recursos
Informe ColCERT IN-20260325-029: colcert.gov.co/800/w3-article-428924.html
NIST Cybersecurity Framework 2.0: nist.gov/cyberframework
CIS Controls v8: cisecurity.org/controls
Base de datos NVD - CVE: nvd.nist.gov
Fuente principal: ColCERT IN-20260325-029, Informe campaña de exfiltración de información. Enero-Marzo 2026
0 comentarios