Lecciones para el proceso de vulnerabilidades

Un proceso de vulnerabilidades típico mide el tiempo desde que hay parche hasta que se instala, y aplica el mismo plazo a todo lo que tiene la misma gravedad. Para un equipo de borde con explotación activa ese reloj llega tarde: el fallo se explota antes del aviso, la mitigación es lo único disponible durante días o semanas, y el equipo suele quedar fuera del agente de protección y del SIEM. Lo que importa medir es otra cosa: cuánto tarda la casa en saber qué equipos tiene afectados, en mitigarlos y en buscar señales anteriores.

La revisión posterior sirve si termina en cambios concretos del proceso, con dueño y fecha, y no en una lista de culpables.

Abre la consola y ejecuta SELECT * FROM tiempos. Entre los equipos expuestos a internet, uno tardó bastante más que los demás en recibir la mitigación, y no por falta de manos: entró tarde al inventario. Calcula las horas desde el aviso hasta su mitigación.

Ejecuta SELECT * FROM politica_vigente y SELECT * FROM brechas. Algunas brechas vienen de reglas que funcionan bien para un servidor cualquiera y mal para un equipo de borde comprometido. Una de ellas habría dado el caso de tec-vpn-04 por resuelto con el intruso todavía dentro.

Ejecuta SELECT * FROM propuestas. Una buena propuesta corrige varias brechas a la vez porque va a la causa. Las demás suenan firmes pero no habrían cambiado nada de lo que pasó: otro fabricante tendrá otro aviso, ningún fabricante avisa primero a un cliente, y un plazo general más corto sigue contando desde el parche.