Estimados amigos de Inseguros !!!
Seguimos con el control 7, gestión continua de vulnerabilidades, y hoy toca el 7.2: establecer y mantener un proceso de remediación. Esto es la parte donde la mayoría de empresas se cae, porque escanear es fácil, lo que cuesta es decidir qué arreglas primero, cuándo, quién lo hace, y cómo demuestras que lo estás haciendo.
Aquí hay una idea clave: no puedes remediar todo a la vez, ni puedes vivir apagando fuegos como pollo sin cabeza cada vez que sale un “critical” en un informe. Lo que necesitas es un proceso que convierta vulnerabilidades en trabajo operable. Y eso empieza por un criterio de priorización que tenga sentido para tu negocio. CVSS está bien como base, pero por sí solo engaña. Hay que añadir contexto: criticidad del activo (no es lo mismo un servidor de producción que un portátil de laboratorio), exposición (internet o interno), prevalencia (si está en 2 máquinas o en 400), y si existe explotación real o es teórico. Con todo eso, te montas tu métrica interna y dejas de ir a ciegas.
Luego viene lo que casi nadie escribe, pero es el corazón del 7.2: los plazos. Es decir, tu SLA de remediación. Qué pasa con un crítico, un alto, un medio, un bajo. No me da igual si son 7 días, 14, 30, 90… lo que importa es que esté definido, aprobado, y que se cumpla. Porque si no hay plazos, todo es “ya lo veremos” y ese “ya lo veremos” se convierte en años. Y si tú estás formando a tu equipo con mentalidad corporativa, esto es lo que tienen que entender: la ciberseguridad no es el informe, es el ciclo de vida del informe.
Y ahora el punto más realista: hay cosas que no vas a poder parchear. Porque el fabricante no saca parche, porque es legacy, porque es un sistema industrial, porque si lo actualizas se cae producción, porque depende de otro. Vale. Entonces el 7.2 no te deja en paz: si no puedes parchear, tienes que mitigar. Segmentación, microsegmentación, firewalling, restricciones de acceso, aislamiento, hardening, virtual patching si aplica, monitorización y detección. Y, sobre todo, registro de excepción con revisión y caducidad, para que no se quede eternamente en “es que no se puede”.
La parte operativa, para que esto funcione, es aburrida pero imprescindible: tickets, responsables, evidencias y reporting. Cada vulnerabilidad priorizada debe acabar en un ticket con dueño, fecha objetivo, y resultado. Remediada, mitigada o aceptada con condiciones. Y esto, cuando lo conectas con inventario y con tu ITSM, empieza a parecerse a un programa de verdad y no a una pila de PDFs.
Si estás montando un programa serio y quieres hacerlo con enfoque práctico, este control es de los que más rendimiento te da. Porque un curso de gestión de vulnerabilidades para profesionales IT no debería enseñarte solo a pasar un Nessus o un Qualys, debería enseñarte a priorizar, remediar, mitigar y gobernar el proceso sin morir en el intento. Y si además trabajas en entornos Microsoft e híbridos, esto encaja perfecto con el resto de controles CIS aplicados a empresa.
Si quieres aprenderlo bien, con mentalidad de entorno real (priorización, SLAs, excepciones, mitigaciones y operativa), pásate por www.seguridadsi.com y échale un ojo a los cursos de ciberseguridad para profesionales que tenemos en la academia.
Gracias por leerme !!!
