Gestión de vulnerabilidades.

Un ciclo, no un escaneo

La gestión de vulnerabilidades suele reducirse a «ejecutar el escáner», pero el escaneo es la parte fácil. La disciplina es un ciclo que se repite: mantener un inventario preciso de lo que se posee, descubrir las debilidades de esos activos, priorizar el puñado que realmente importa, remediarlas y verificar que la corrección se mantuvo. Un escáner moderno te entregará miles de hallazgos sobre un parque mediano. Tratar esa lista como una cola de tareas es la forma en que los equipos se agotan mientras su exposición real sigue abierta. El valor está en el embudo, desde miles de hallazgos en bruto hasta el pequeño conjunto sobre el que actúas esta semana.

También depende de algo que la mayoría de los equipos subestima: conocer tu parque. Una vulnerabilidad en un servidor expuesto a Internet que ejecuta una aplicación de negocio crítica es un problema distinto del mismo defecto en una máquina de pruebas aislada. Sin inventario de activos ni propiedad, la priorización no tiene nada en lo que apoyarse, por lo que el ciclo comienza con el descubrimiento y la identificación en lugar de con el escaneo en sí.

El vocabulario: CVE, CVSS y KEV

Tres puntos de referencia sostienen la mayor parte de la conversación sobre priorización, y los profesionales los usan en combinación más que de forma aislada.

El error común es ordenar por puntuación CVSS y trabajar de arriba hacia abajo. Un CVSS alto en un activo que nadie puede alcanzar importa menos que un defecto de gravedad media que figura en un catálogo de vulnerabilidades conocidas por estar siendo explotadas en un sistema expuesto. Los programas maduros combinan la gravedad teórica con señales reales: existe un exploit funcional, se está explotando activamente la vulnerabilidad, y cuán expuesto y crítico es el activo afectado. Esa combinación, no la puntuación en bruto, es lo que impulsa la cola.

La priorización es todo el trabajo

El planteamiento honesto es que la priorización es el producto de la gestión de vulnerabilidades. Las entradas son la criticidad del activo, la disponibilidad de un exploit y la exposición del negocio, y la salida es una decisión defendible sobre qué se corrige primero y qué espera. Aquí es donde la función justifica su valor, porque ningún equipo puede ni debe remediarlo todo a la vez.

1. Criticidad del activo: qué hace el sistema para el negocio y qué puede alcanzar si se ve comprometido.
2. Disponibilidad de un exploit: si existe un exploit funcional y si el defecto se está usando en la práctica.
3. Exposición del negocio: si el activo está expuesto a Internet, qué datos contiene y qué controles compensatorios ya se interponen delante de él.

Dónde encaja en la gobernanza

La gestión de vulnerabilidades rara vez es opcional una vez que estás dentro de un marco reconocido. Un SGSI ISO/IEC 27001 espera un proceso definido para gestionar las vulnerabilidades técnicas, y los auditores pedirán ver el ciclo en funcionamiento, no solo una licencia de escáner. El NIST Cybersecurity Framework considera la identificación y gestión de vulnerabilidades como algo central de las funciones Identify y Protect, y normativas como NIS2 y DORA dan por sentado que las organizaciones encuentran y remedian activamente las debilidades en lugar de esperar a que un incidente las revele. En todos los casos, la evidencia que quiere un evaluador tiene la misma forma: cómo descubres, cómo priorizas, los SLA con los que remedias y las métricas que demuestran que el ciclo se está cerrando.