c4.8 Construir un equipo de gestión de vulnerabilidades
En este nivel, un equipo dedicado de gestión de vulnerabilidades es dueño del proceso: rastrear nuevas vulnerabilidades, definir criterios de severidad y SLAs de remediación, coordinar las correcciones y dar a cada equipo visibilidad de las vulnerabilidades en sus cargas.
Guía de implementación
De qué es dueño el equipo
Un equipo de gestión de vulnerabilidades convierte el parcheo ad-hoc en un proceso gobernado. Sus responsabilidades incluyen:
- Rastrear nuevas vulnerabilidades y emitir advisories a los equipos de desarrollo.
- Alertar y escalar cuando surgen vulnerabilidades críticas, y coordinar la remediación.
- Definir cómo se clasifica la severidad (CVSS, EPSS, SSVC, VPR) y el plazo en que cada severidad debe corregirse.
- Conseguir que los equipos de DevOps se comprometan con SLAs de remediación (o imponerlos top-down con respaldo del CISO/CIO).
- Medir los tiempos de remediación y dar a cada equipo —y a cada manager— dashboards de las vulnerabilidades en sus cargas.
Defina reglas de auto-corrección vs. escalamiento
Tenga un proceso acordado para corregir desviaciones. Ejemplos a adaptar a su industria y apetito de riesgo:
- Vuln crítica en un SO no productivo: auto-aplicar el parche si no se aplica en X.
- Vuln crítica en un SO productivo: escalar si no se aplica en X.
- Vuln alta/crítica en código: contactar al Security Champion del equipo si no se corrige en X horas; escalar si no se resuelve ese día.
Los dashboards agregados por equipo y por manager impulsan el compromiso en la corrección de vulnerabilidades.
Cómo validar
- ¿Existe un equipo dueño de la gestión de vulnerabilidades con las responsabilidades anteriores?
- ¿Los criterios de severidad y los SLAs de remediación están definidos y acordados con DevOps?
- ¿Hay reglas de auto-corrección o escalamiento configuradas para vulnerabilidades que envejecen?
- ¿Cada equipo tiene visibilidad de las vulnerabilidades en sus cargas?
Amenazas que atiende
- La mayoría de la explotación a gran escala ocurre días o semanas después de que una vulnerabilidad es pública y sigue teniendo éxito porque las organizaciones carecen del equipo, el proceso y las herramientas para parchear a tiempo.
- Parchear todo de inmediato es imposible a escala y el riesgo de no parchear es demasiado alto, así que sin definiciones basadas en severidad y SLAs, se corrigen primero las vulnerabilidades equivocadas, o demasiado tarde.