Cualquier herramienta moderna de escaneo de vulnerabilidades te puede escupir un informe en PDF de 500 páginas con gráficos de colores. Y para muchos responsables IT, entregar ese PDF a la dirección significa que están «gestionando» el problema. Se equivocan, eso es ruido sin filtro.
Aquí es donde entran los Acuerdos de Nivel de Servicio (SLAs) de remediación y las métricas de seguridad. No sirven para castigar al equipo de sistemas cuando no llegan a tiempo a parchear un servidor; sirven para entender si nuestra capacidad operativa está alineada con el nivel de riesgo que la empresa puede tolerar.
El objetivo de este artículo no es darte una lista de fórmulas matemáticas complejas, sino ayudarte a separar el ruido de la señal. Vamos a ver cómo establecer SLAs que la gente de infraestructura realmente pueda cumplir y qué métricas demuestran si tu postura de seguridad está mejorando o si solo estás apagando incendios.
Índice de contenidos
Por qué el «número total de vulnerabilidades» es una métrica tóxica
Es la métrica favorita de los comités de dirección: «Este mes tenemos 15.000 vulnerabilidades, el mes pasado 12.000. ¡Estamos empeorando!». Esta conclusión es, en la mayoría de los casos, falsa.
El número absoluto de vulnerabilidades siempre tiende a crecer. ¿Por qué? Porque escaneas más activos, porque despliegas más código o simplemente porque se descubren nuevos CVEs todos los días. Medir el éxito de tu programa basándote en esta cifra genera frustración en los equipos técnicos y una falsa sensación de fracaso. Lo que realmente necesitas medir es tu capacidad para identificar, priorizar y mitigar aquellas vulnerabilidades que de verdad importan, en un tiempo razonable.
SLAs de Remediación: De la teoría a la trinchera
Un SLA de remediación (Service Level Agreement) define el tiempo máximo aceptable desde que se descubre una vulnerabilidad hasta que se mitiga o se parchea. Para que un SLA funcione, no puede ser una imposición unilateral del equipo de seguridad; debe ser un pacto con el equipo de operaciones o desarrollo.
Si le exiges a un administrador de sistemas que parchee todo en 24 horas, te mentirá o romperá producción. Ninguna de las dos opciones es buena para la empresa.
Tiempos de resolución estándar (y cuándo ignorarlos)
A modo de referencia, un marco de trabajo habitual suele ser el siguiente:
| Gravedad (Contextualizada) | Tiempo de Remediación (SLA) | Comentarios y matices |
|---|---|---|
| Crítica | 48 horas a 7 días | Sistemas expuestos a internet o vulnerabilidades explotadas activamente (ej. CISA KEV). |
| Alta | 14 a 30 días | Sistemas internos críticos o donde existe un exploit público pero no en uso masivo. |
| Media | 60 a 90 días | Riesgo teórico alto pero que requiere condiciones muy complejas para ser explotado. |
| Baja | 120 días o «Best Effort» | Defectos menores. A menudo se agrupan para parcheos trimestrales. |
El gran error: Basar estos tiempos exclusivamente en la puntuación CVSS.
Un CVSS 9.8 en una máquina de pruebas aislada no tiene el mismo SLA que un CVSS 7.5 en el servidor que procesa las nóminas.
Un buen SLA combina la gravedad técnica con la criticidad del activo y la inteligencia de amenazas (como el EPSS o si está siendo activamente explotado).
Métricas de Seguridad que sí aportan valor
Si queremos dejar atrás el conteo vacío de alertas, debemos centrarnos en métricas operativas. Aquí tienes las que realmente te dirán si tu programa es eficaz.
Tiempo Medio de Remediación (MTTR)
El MTTR (Mean Time to Remediate) mide el tiempo promedio que tarda tu equipo en cerrar una vulnerabilidad desde que se detecta. Es la métrica reina.
- Por qué importa: Te indica la agilidad real de tus equipos. Si tu SLA para vulnerabilidades críticas es de 7 días, pero tu MTTR es de 45, tienes un problema grave de recursos, de procesos o de fricción entre departamentos.
- Cómo usarla: Divídela por criticidad. Un MTTR global no sirve; necesitas saber el MTTR de las críticas frente a las medias.
Tasa de Cobertura del Escaneo
Puedes tener un MTTR de 2 horas en tus servidores Windows, pero si no estás escaneando el entorno Linux o la infraestructura Cloud, tu métrica es una ilusión.
- Por qué importa: Te muestra el porcentaje de tus activos totales que están siendo auditados regularmente.
- La realidad: Llegar al 100% es casi imposible en entornos dinámicos, pero si estás por debajo del 80%, tienes puntos ciegos críticos.
Tasa de Reincidencia (Vulnerabilidades Zombie)
Mide cuántas vulnerabilidades que se dieron por solucionadas vuelven a aparecer en escaneos posteriores.
- Por qué importa: Una alta tasa de reincidencia indica fallos sistémicos. Alguien está revirtiendo snapshots, desplegando imágenes base antiguas en contenedores (Golden Images obsoletas), o aplicando parches de forma manual que se sobrescriben en el siguiente despliegue automatizado.
Volumen de Excepciones y Riesgos Aceptados
No todo se puede parchear. A veces, un parche rompe una aplicación legacy que da de comer a la empresa. En esos casos, se documenta una excepción.
- Por qué importa: Si el 40% de tus vulnerabilidades críticas terminan como «riesgo aceptado» sin controles compensatorios (como un WAF o segmentación de red), tu programa de gestión es en realidad un programa de justificación de la inacción. Las excepciones deben tener fecha de caducidad.
Errores habituales al implementar estas métricas
- Usar las métricas como arma arrojadiza: Si usas el incumplimiento de SLAs para abroncar a los equipos de desarrollo o sistemas, conseguirás que oculten activos o marquen falsos positivos donde no los hay. Las métricas deben diagnosticar cuellos de botella (falta de personal, ventanas de mantenimiento insuficientes), no buscar culpables.
- Medir el «Tiempo de Detección» cuando escaneas una vez al mes: No puedes presumir de detectar rápido si tu ciclo de escaneo es mensual. El tiempo cuenta desde que la vulnerabilidad se hizo pública, no desde que tu escáner se acordó de mirar.
- Ignorar los falsos positivos en el cálculo: Si un analista tarda 3 días en investigar una alerta para descubrir que es un falso positivo, ese tiempo es coste operativo. Mide cuántos recursos pierdes persiguiendo fantasmas; te ayudará a afinar tu herramienta.
Checklist para un programa de métricas realista
Si vas a empezar a medir mañana, asegúrate de cumplir estos mínimos:
- ¿Hemos acordado los tiempos de SLA junto con el equipo que realmente va a aplicar los parches?
- ¿Nuestros SLAs contemplan excepciones para sistemas críticos que no pueden reiniciarse entre semana?
- ¿Estamos priorizando basándonos en si la vulnerabilidad es explotable en la realidad (CISA KEV / EPSS) y no solo en el CVSS base?
- ¿Tenemos un proceso documentado y con caducidad para las «aceptaciones de riesgo»?
- ¿El MTTR se calcula separando por niveles de criticidad?
Conclusión
Las métricas y los SLAs en la gestión de vulnerabilidades son el puente entre la teoría del riesgo y la realidad operativa de tu infraestructura.
Un buen programa no es aquel que elimina todas las vulnerabilidades (eso es un mito), sino aquel que garantiza que los riesgos verdaderamente críticos se mitigan antes de que alguien pueda aprovecharlos, sin paralizar el negocio en el intento.
Mide para entender dónde fallan tus procesos de parcheo, ajusta los SLAs a la realidad de tu plantilla técnica y, sobre todo, deja de enviar informes de 500 páginas sin contexto a la dirección. Menos gráficas de tarta y más MTTR accionable.
