Actualización de seguridad (patch management)
En operaciones de seguridad, la actualización de seguridad es el proceso de llevar las correcciones del fabricante a producción de forma fiable y rápida, en todos los sistemas que ejecutan código de otro. El hueco entre que un fallo se publica y que su parche está desplegado es donde vive el atacante, y la longitud de ese hueco es una propiedad del proceso, no de la vulnerabilidad.
Cómo funciona
El proceso tiene cinco piezas y falla por la que falte. Un inventario de activos de qué corre y dónde, porque no se puede parchear lo que no está en una lista. La entrada de los avisos del fabricante, cruzada contra ese inventario. Una decisión sobre la urgencia. El despliegue por un camino probado y con vuelta atrás. Y la verificación de que la corrección está de verdad en las máquinas, que es un paso distinto de que la herramienta de despliegue diga que fue bien.
Lo que se actualiza no es solo el sistema operativo. Son también las aplicaciones, el antivirus, los cortafuegos y cualquier otro componente que ejecute código de un tercero, y casi siempre llega como parche o como versión nueva publicada por el propio fabricante.
Y corren dos calendarios a la vez. Un ciclo rutinario se ocupa del flujo mensual. Una vía de emergencia existe para los pocos fallos que no esperan, y su valor está entero en haberla usado antes: un camino que se estrena durante un incidente es un plan, no una capacidad.
Qué sale mal
El parque nunca es uniforme. Los puestos y los servidores corrientes se parchean bien; lo que se queda atrás es todo lo demás, y todo lo demás es por donde entramos. Electrónica de red, hipervisores, controladoras de gestión fuera de banda, cabinas de almacenamiento, impresoras, sistemas del edificio, appliances virtuales que entrega un proveedor y el servidor de aplicaciones que un contrato dice que no se toca. Con frecuencia son justo los componentes expuestos a internet y con más privilegio.
La verificación es el otro hueco constante. Una consola de despliegue que da cumplimiento total mientras el servicio no se llegó a reiniciar, una imagen de contenedor reconstruida sin bajarse la capa base ya corregida, o una biblioteca parcheada en el sistema operativo mientras la aplicación se trae su propia copia dentro, son estados que encontramos y demostramos. Cuando una corrección de verdad no se puede aplicar, la respuesta es un control compensatorio escrito, con dueño y con fecha, y no una aceptación de riesgo que se renueva sola durante cuatro años.
La prioridad debería salir de señales de explotación y no del CVSS a solas: el catálogo KEV es la lista útil más corta que existe. Y lo que hay al otro lado de no hacerlo no es teórico: un exploit contra un fallo ya publicado y todavía sin parchear es la vía de entrada más barata que tiene un atacante.
Dónde aparece esto en una auditoría
Los parches que faltan se informan como alcanzables o no alcanzables, porque son dos trabajos distintos y mezclarlos es lo que produce una cola que nadie termina. Cuando explotamos uno, el hallazgo lleva la evidencia y la identidad que obtuvimos, no solo el número de versión. La cifra más útil que devolvemos suele ser la edad de la corrección más vieja que falta en una máquina alcanzable, que dice más del proceso del cliente que cualquier recuento. Es parte de cómo demostramos qué parches pendientes son de verdad alcanzables.