Análisis de vulnerabilidades (gestión de vulnerabilidades)
En operaciones de seguridad, el análisis de vulnerabilidades es el ciclo continuo de encontrar, priorizar, corregir y verificar las vulnerabilidades de todo un parque. Es una disciplina de proceso y no una actividad de escaneo: el escáner produce una lista, y todo lo que determina si el riesgo baja de verdad ocurre después de eso.
Qué es el análisis de vulnerabilidades
El análisis de vulnerabilidades es la evaluación sistemática de sistemas, redes, aplicaciones y dispositivos para identificar las vulnerabilidades por las que podría entrar un atacante, entender su alcance y ordenarlas por severidad. Se hace con herramientas automáticas y también a mano, porque las dos cosas encuentran cosas distintas.
Las vulnerabilidades salen de sitios muy diversos: errores de programación, configuraciones incorrectas, falta de actualizaciones de seguridad o un diseño que nunca previó ese uso. Identificarlas es solo la primera mitad; la segunda es aplicar la corrección y comprobar después que está puesta de verdad en la máquina.
Cómo funciona
El ciclo tiene cinco etapas. El inventario establece qué existe, y es la etapa que pone techo al valor de todas las siguientes, porque una máquina que no está en el inventario no se escanea nunca. La evaluación encuentra vulnerabilidades mediante escaneo autenticado y no autenticado, revisión de configuración y pruebas. La priorización ordena los resultados. La remediación aplica correcciones o controles compensatorios a través de los equipos dueños de los sistemas. Y la verificación confirma la corrección, sobre la máquina, volviendo a probar en lugar de fiarse de un ticket.
La priorización es donde un programa moderno se separa de uno construido hace una década. La severidad del CVSS es una entrada. La probabilidad de explotación del EPSS, la explotación confirmada en el catálogo KEV, la alcanzabilidad y el valor del activo son las otras, y juntas suelen producir un orden de trabajo muy distinto.
Qué sale mal
La cola pendiente es el síntoma que todo el mundo reconoce: decenas de miles de hallazgos abiertos, que crecen más rápido de lo que se cierran, así que nadie trabaja ya desde la lista. La causa es casi siempre priorizar solo por severidad, lo que produce una cola técnicamente defendible y operativamente inútil.
El segundo fallo es tomar el escaneo sin autenticar como cobertura. Un escaneo sin credenciales ve banners e infiere versiones, así que deja fuera por completo los fallos locales e informa de cosas que no están. Después está el hueco de verificación, donde un hallazgo se cierra en el ticket y sigue presente en la máquina, y por eso el retest es una actividad aparte con su propia evidencia.
Por último, el proceso solo cubre lo que tiene identificador. Nada dentro de él va a encontrar un fallo de autorización en tu propia aplicación, y esa es la diferencia entre esta disciplina y un pentesting: una gestiona defectos conocidos a escala, el otro encuentra desconocidos en profundidad.
Dónde aparece esto en una auditoría
Nos piden con frecuencia validar la cola de un cliente, y la salida útil no son más hallazgos, sino menos: cuáles son de verdad explotables aquí, cuáles no son alcanzables y cuáles son falsos. Comparamos además los resultados de sus escaneos con lo que encontramos nosotros, porque esa diferencia mide si la herramienta está bien configurada. Todos los encargos terminan con un retest para que el cierre quede evidenciado y no afirmado. Esto forma parte de en qué se diferencia un hallazgo validado del resultado de un escáner.