Programa de gestión de vulnerabilidades en una compañía de servicios financieros

La compañía no partía de cero: había escaneos, había informes y había buena voluntad. Lo que no había era un proceso. Los análisis se lanzaban de forma irregular, los resultados llegaban como listados de cientos de hallazgos ordenados por criticidad técnica — sin distinguir un servidor expuesto a internet de una máquina de pruebas aislada — y la resolución dependía de que algún equipo interno encontrara hueco entre sus prioridades. El resultado era conocido: vulnerabilidades críticas que cumplían meses abiertas y nadie capaz de decir cuántas, ni desde cuándo, ni de quién eran.

En un negocio financiero eso no es solo un problema técnico: es un riesgo que reguladores, auditores y clientes institucionales preguntan por escrito. La compañía necesitaba pasar de escanear de vez en cuando a gestionar de forma continua — con plazos, dueños y métricas que se pudieran enseñar.

1. Inventario y línea base — antes de escanear mejor, saber qué se escanea: inventario de infraestructura y aplicaciones, identificación de los activos expuestos a internet y de los que sostienen procesos de negocio críticos, y una primera foto completa del estado real. Esa línea base marcó los SLAs de remediación por severidad que gobiernan el programa desde entonces.
2. Escaneo recurrente de infraestructura y aplicaciones — ciclos mensuales sobre todo el parque, con frecuencia reforzada en el perímetro expuesto y análisis adicionales tras cambios relevantes. Sin fotos anuales: el parque cambia cada semana y las vulnerabilidades se publican cada día.
3. Priorización por riesgo real, no por CVSS a secas — cada hallazgo se pondera con tres lentes: criticidad técnica, exposición (¿se llega desde internet? ¿desde dónde?) y contexto de negocio (¿qué proceso sostiene ese activo?). Una crítica en una máquina aislada puede esperar; una media en el perímetro del negocio, no. Esa lista corta y ordenada es la que se trabaja — no un listado de cientos de entradas que nadie lee.
4. Resolución coordinada con equipos internos y proveedores — cada vulnerabilidad priorizada sale con dueño, plazo según SLA y el detalle técnico que quien parchea necesita. Nosotros coordinamos: perseguimos vencimientos, escalamos bloqueos, documentamos mitigaciones compensatorias cuando el parche no es viable y verificamos cada cierre en el ciclo siguiente.
5. Comité mensual con métricas que dirección entiende — cada mes, un comité de seguimiento con las cifras que importan: tiempo de exposición por severidad, cumplimiento de SLAs, antigüedad del backlog y riesgos aceptados pendientes de revisión. En lenguaje de negocio, con decisiones encima de la mesa — no un anexo técnico que nadie abre.
6. Mejora continua del propio programa — los SLAs se revisan con los datos de cada ejercicio, los falsos positivos alimentan el ajuste de los escaneos y las lecciones de cada ciclo — qué proveedor va lento, qué plataforma concentra hallazgos — se convierten en acciones preventivas. El programa del tercer año detecta mejor y molesta menos que el del primero.

El cambio más visible está en la métrica que de verdad protege: el tiempo de exposición. Las vulnerabilidades críticas que antes cumplían meses abiertas hoy se resuelven dentro de SLA, y las que superan los 30 días son casos contados, cada uno con su mitigación compensatoria documentada y su fecha de revisión. Cuando un auditor o un cliente institucional pregunta, la respuesta ya no se improvisa: se imprime.

El cambio menos visible es cultural. Tres años y doce comités anuales después, la gestión de vulnerabilidades ha dejado de ser un proyecto con principio y fin para ser parte del gobierno de la compañía: dirección conoce sus cifras, los equipos conocen sus plazos y el programa sobrevive a vacaciones, picos de trabajo y cambios de personal — que es exactamente lo que un proceso debe hacer.