Gestión de vulnerabilidades y riesgos: cómo construir un programa real, medirlo y comunicarlo a la dirección

Un escaneo de vulnerabilidades no es un programa de seguridad. Es solo el comienzo. La diferencia entre gestionar riesgos y acumularlos está en lo que ocurre después del escaneo, y en si la dirección lo sabe.

El problema real no es la herramienta

Cuando reviso entornos de clientes o cuando converso con colegas del sector, el patrón se repite: hay firewall, hay switches gestionados, hay algún nivel de monitoreo. Fortinet en el perímetro, Cisco en el core, quizás pfSense o OPNsense en alguna sede secundaria, Ubiquiti cubriendo el WiFi. La infraestructura existe. Lo que falta casi siempre es el proceso que la sostiene.

La gestión de vulnerabilidades es uno de esos procesos que las organizaciones medianas implementan a medias. Se contrata una herramienta de escaneo, se genera un reporte lleno de CVEs, alguien lo lee, alguien lo archiva, y en el mejor de los casos se parchea lo más obvio. Eso no es un programa. Es un ritual sin consecuencias.

El problema de fondo es de gobernanza, no de tecnología. Y si ese problema no se resuelve a nivel de dirección, ninguna herramienta (por buena que sea) va a cambiar el resultado.

Qué hace que un programa de vulnerabilidades sea real

Un programa real tiene ciclo de vida. No es un evento, es un proceso continuo con fases definidas, responsables claros y métricas que permiten tomar decisiones. Las fases son cinco, y ninguna es opcional:

1. Descubrimiento e inventario

No puedes gestionar lo que no conoces. El primer paso, y el que más frecuentemente se saltea, es tener un inventario actualizado y dinámico de todos los activos: servidores, equipos de red, endpoints, aplicaciones, dispositivos IoT. En entornos con Ubiquiti y switches Cisco conviviendo, sin gestión centralizada, es habitual encontrar activos "fantasma" que nadie recuerda haber conectado.

El inventario tiene que estar vinculado a la criticidad de negocio. Un servidor de producción con ERP no tiene el mismo peso que una impresora administrativa, aunque ambos aparezcan en el mismo escaneo.

2. Escaneo y detección

Aquí entra la herramienta; lo que importa no es solo la frecuencia del escaneo (semanal o mensual, según el contexto), sino la capacidad de correlacionar hallazgos con el inventario y con fuentes externas de inteligencia de amenazas. Un CVE publicado esta semana en un componente que está en tu red debería disparar una alerta, no esperar al próximo ciclo de escaneo programado.

Los equipos Fortinet, por ejemplo, publican boletines de vulnerabilidades propios con frecuencia. Lo mismo Cisco. Ignorar esos canales y depender solo del escaneo interno es dejar puertas abiertas que el fabricante ya señaló.

3. Priorización basada en riesgo real

Este es el paso donde más se falla. La mayoría de los equipos priorizan por severidad CVSS. El problema es que CVSS mide el riesgo técnico en abstracto, no el riesgo para tu organización específica. Un CVE-9.8 en un servicio que no está expuesto a internet y tiene controles compensatorios es menos urgente que un CVE-6.5 en un sistema accesible públicamente sin autenticación robusta.

La priorización debe cruzar tres variables: severidad técnica, exposición real en el entorno, y criticidad del activo para el negocio. Con esas tres dimensiones, la lista de "todo urgente" se convierte en un backlog gestionable.

4. Remediación con SLA definido

Si no hay plazo, no hay compromiso. Un programa maduro define SLA de remediación por nivel de severidad:

• Crítico: 24 a 72 horas
• Alto: 7 días hábiles
• Medio: 30 días
• Bajo: ciclo trimestral o aceptación formal del riesgo

Esos plazos tienen que estar acordados con la dirección y con las áreas de negocio. No son decisiones técnicas unilaterales. Si el área de TI no puede parchear un sistema crítico en 72 horas porque hay dependencias de producción, ese conflicto tiene que escalar (y ser decidido) por alguien con autoridad para hacerlo.

5. Medición y reporte ejecutivo

El ciclo cierra aquí, y es donde la mayoría de los programas muere en silencio. Sin métricas visibles para la dirección, el programa se convierte en un gasto que nadie puede justificar.

Las métricas técnicas (número de CVEs, distribución por severidad) son necesarias para el equipo operativo. Para la dirección, lo relevante es otro set de indicadores:

• MTTR (Mean Time to Remediate): cuánto tiempo tarda la organización en cerrar vulnerabilidades desde que se detectan
• Reducción de exposición: porcentaje de superficie de ataque cubierta vs. periodo anterior
• Cumplimiento de SLA: qué porcentaje de vulnerabilidades críticas se remediaron dentro del plazo acordado
• Riesgo residual documentado: qué vulnerabilidades están en aceptación formal y por qué

Con esos cuatro indicadores, cualquier CIO puede pararse frente al directorio y tener una conversación de negocio sobre seguridad, sin necesidad de hablar de CVEs ni de exploits.

El reporte ejecutivo: una página que vale más que cien técnicas

Uno de los cambios más difíciles de implementar en equipos TI con perfil técnico es aprender a comunicar hacia arriba. El reporte mensual de vulnerabilidades para la dirección no debería tener más de una página. Debería responder tres preguntas:

1. ¿Cuál es nuestra postura de seguridad este mes comparado con el anterior?
2. ¿Qué riesgos críticos están abiertos y cuál es el plan?
3. ¿Qué necesitamos (recursos, decisiones, presupuesto) para mantener el ritmo?

La dirección no gestiona CVEs; gestiona riesgos de negocio. Si el área de TI no aprende a traducir el lenguaje técnico a esa lógica, va a seguir pidiendo presupuesto sin argumentos que la alta dirección pueda evaluar.

Y eso, en última instancia, es lo que diferencia a un jefe de TI que ejecuta de uno que lidera.

Contexto regional: Chile y la madurez pendiente

En el contexto chileno, la realidad de muchas organizaciones medianas es que la gestión de vulnerabilidades está en etapas muy tempranas. El marco regulatorio va avanzando, la Ley Marco de Ciberseguridad pone presión en sectores críticos; pero la gran mayoría de las empresas fuera del sector financiero o de infraestructura crítica opera sin un programa formal.

Eso representa una oportunidad y una responsabilidad para los equipos TI. La oportunidad es posicionarse como el área que construye ese programa antes de que lo exija una auditoría o, peor, un incidente. La responsabilidad es hacerlo bien: con proceso, con métricas, y con la capacidad de comunicarlo a quienes toman las decisiones.

Conclusión

Gestionar vulnerabilidades no es escanear, es tener un ciclo completo, con inventario, priorización real, SLA de remediación y reporte ejecutivo. Sin esos elementos, cualquier inversión en herramientas (Fortinet, Cisco, pfSense, Qualys, lo que sea) es subutilizada.

El programa no lo construye la herramienta, lo construye quien decide que la seguridad es una función de negocio, no un servicio técnico de soporte.

Esa decisión, en la mayoría de las organizaciones, todavía está esperando que alguien la tome.

---

Luis Bolívar | IT Manager · Network Security Engineer | MBA | Santiago, Chile
+15 años en infraestructura crítica y ciberseguridad | Fortinet · Cisco · pfSense/OPNsense · Ubiquiti