TÉCNICO-GERENCIAL · MÉTRICAS · GESTIÓN DE VULNERABILIDADES
Ayer describí los seis frenos que explican por qué el parche existe y nadie lo aplica. Hoy el ángulo es distinto: cómo saber si el programa de vulnerabilidades está funcionando, con métricas que tengan sentido no solo para el equipo técnico sino para la gerencia que tiene que respaldar las decisiones de inversión y priorización que el programa requiere.
Porque hay un problema estructural en cómo la mayoría de los programas de vulnerabilidades reportan su estado: reportan volumen; Cuántos CVEs se detectaron esta semana; Cuántos son críticos; Cuántos son altos. Esa información es útil para el equipo técnico, pero no le dice nada a la gerencia sobre si la organización está mejorando su postura de seguridad o empeorando. El número de CVEs detectados depende en gran medida de cuánto escaneas y de cuánto crece la superficie de ataque. No es una métrica de gestión; es una métrica de inventario.
Las métricas de gestión miden qué está haciendo la organización con lo que el escáner encuentra. Y hay tres que, en mi experiencia, son las más útiles para llevar la conversación a nivel ejecutivo.
MTTR: EL TIEMPO QUE DICE TODO
El Mean Time to Remediate es el tiempo promedio entre la detección de una vulnerabilidad y su cierre, medido por nivel de criticidad. Es la métrica más directa del programa porque mide velocidad de respuesta real, no actividad.
Los benchmarks de referencia más citados establecen objetivos de 7 días para vulnerabilidades críticas, 30 días para altas y 90 días para medias. Esos números no son absolutos; dependen del sector, del tamaño de la organización y del nivel de madurez del programa. Pero sirven como punto de referencia para una conversación honesta sobre en qué punto está la organización.
Lo que el MTTR revela cuando se analiza con criterio no es solo el número promedio. Es la distribución. Un MTTR promedio de 25 días para vulnerabilidades críticas puede esconder que el 80% se cierran en 5 días y el 20% llevan más de 90. Ese 20% es exactamente donde están los frenos que describí ayer: los sistemas que no se pueden tocar, el EOL sin presupuesto de reemplazo, la dependencia del proveedor. El promedio los oculta. La distribución los expone.
Para organizaciones que recién empiezan a medir el MTTR, el primer número que aparece suele ser sorprendente. He visto MTTRs reales para vulnerabilidades críticas que superan los 60 días en organizaciones que creían tener un programa razonablemente activo. La sorpresa es útil: es el punto de partida para una conversación honesta sobre qué está frenando la remediación.
PORCENTAJE DE CVEs CERRADOS EN SLA: LA MÉTRICA DE CUMPLIMIENTO
Si el MTTR mide velocidad promedio, el porcentaje de CVEs cerrados dentro del SLA mide consistencia. ¿Qué fracción de las vulnerabilidades detectadas se está cerrando en el plazo que el programa comprometió?
Esta métrica solo tiene sentido si existe un SLA definido. Y ese es el primer diagnóstico que hace: si la organización no puede calcular este número porque no tiene SLAs de remediación establecidos, el programa tiene una brecha fundamental antes de cualquier discusión sobre herramientas o recursos.
Los rangos orientativos que uso como referencia: un programa maduro debería cerrar al menos el 85% de sus vulnerabilidades críticas y altas dentro del SLA comprometido. Un programa aceptable, el 70%. Por debajo del 60%, hay algo estructural que está fallando, ya sea el SLA es irreal para la capacidad del equipo, los frenos organizacionales no están siendo gestionados, o las excepciones no tienen proceso formal.
La razón por la que esta métrica es especialmente útil para la conversación ejecutiva es que conecta directamente con compromisos. Cuando la gerencia aprueba un programa de vulnerabilidades con SLAs definidos, el porcentaje de cumplimiento es la evidencia de que el compromiso se está honrando o no. Eso es un lenguaje que los directivos entienden sin necesidad de conocer los detalles técnicos del CVE.
DENSIDAD DE VULNERABILIDADES POR ACTIVO CRÍTICO
El número total de CVEs abiertos en la organización es un número que crece naturalmente con el tiempo y con la superficie de ataque, y que no es comparable entre organizaciones de distinto tamaño. La densidad de vulnerabilidades por activo crítico es un indicador más fino: cuántas vulnerabilidades abiertas tiene cada uno de los sistemas más importantes de la organización.
Definir qué es un activo crítico es el primer paso, y ese ejercicio en sí mismo es valioso: obliga a la organización a nombrar explícitamente cuáles son los sistemas cuyo compromiso tendría mayor impacto. El firewall perimetral. El servidor de autenticación. El sistema de respaldo. El ERP. La plataforma de gestión de clientes. Esos activos deberían tener densidad de vulnerabilidades abiertas igual a cero para CVEs críticos, y una tendencia decreciente para los demás.
Cuando un activo crítico tiene un CVE crítico abierto hace más de 30 días, eso no es un indicador técnico. Es una señal de gobernanza: algo en el proceso está fallando específicamente en ese activo, y alguien con autoridad necesita saberlo y actuar. La densidad por activo crítico es la métrica que hace esa señal visible en el nivel correcto.
ERROR COMÚN
Reportar a la gerencia el número total de vulnerabilidades detectadas como indicador de actividad del programa. Ese número sube cuando escaneas más, no necesariamente cuando la postura empeora. Peor aún, puede generar la percepción de que el programa está "encontrando más problemas", lo que lleva a cuestionarlo en lugar de reforzarlo. Las métricas de gestión, MTTR, SLA y densidad, muestran qué está haciendo la organización con lo que encuentra, que es la pregunta que importa.
¿CÓMO PRESENTAR ESTAS MÉTRICAS A LA GERENCIA?
El formato importa tanto como los números. Lo que he visto funcionar mejor en organizaciones medianas de la región es un reporte ejecutivo mensual de no más de una página, con tres elementos: el estado de los tres indicadores clave contra el objetivo, la tendencia respecto al mes anterior, y los dos o tres ítems que requieren una decisión que excede la autoridad del equipo de TI.
Ese tercer elemento es el más importante para construir el vínculo entre el programa técnico y la gobernanza ejecutiva. "El servidor X tiene un CVE crítico abierto hace 45 días porque requiere una ventana de mantenimiento que el área de negocio no ha aprobado" es una decisión que la gerencia necesita tomar, no que TI puede resolver solo. Hacerla visible en el reporte convierte el programa de vulnerabilidades en una conversación organizacional, no en una lista técnica de pendientes.
DECISIÓN QUE DEBE TOMAR EL CIO
Definir las tres métricas, establecer los SLAs de remediación por criticidad, y comprometerse con un reporte mensual ejecutivo que las incluya. Ese compromiso no requiere nueva tecnología: la mayoría de las herramientas de gestión de vulnerabilidades disponibles en el mercado, incluyendo integraciones con el ecosistema Fortinet o soluciones open source sobre pfSense, pueden exportar los datos necesarios para calcular estas métricas. Lo que requiere es la decisión de hacerlo y la disciplina de mantenerlo.
¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?
Un programa de vulnerabilidades sin métricas de gestión es un programa que no puede demostrar su valor ni identificar sus propias fallas. El equipo técnico puede tener una percepción cualitativa de si las cosas están mejorando o empeorando, pero esa percepción no escala a la gerencia y no produce los cambios organizacionales que los frenos de ayer requieren.
Mañana voy a ver el caso TechCorp Latam: qué vulnerabilidades estaban identificadas antes del incidente de ransomware, qué frenó su remediación, y qué habrían mostrado estas tres métricas si alguien las hubiera estado midiendo.
Sin métricas, la gestión de vulnerabilidades es una actividad técnica que vive dentro de TI. Con métricas que llegan a la gerencia, se convierte en una conversación de riesgo organizacional. La diferencia define si el programa obtiene el respaldo que necesita para funcionar.
Artículo núcleo de la semana: Gestión de vulnerabilidades: la brecha entre saber y actuar. Mañana: el caso TechCorp Latam.
#GestiónDeVulnerabilidades #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #pfSense #TechCorpLatam #CyberLeadership #Liderazgo #Chile #MTTR #CVE #NISTCSF #ISO27001 #KPIs
Comentarios
Publicar un comentario