ENS desde dentro (XXII): Mantenimiento y actualizaciones de seguridad (op.exp.4) — parchear sin dejar de dormir tranquilo

Cómo aplicar actualizaciones de seguridad sin que cada parche se convierta en una apuesta

Este artículo forma parte de la serie ENS desde dentro.

👉 Puedes ver la guía completa aquí:

https://www.handersonboratto.com/ens-desde-dentro/

👉 Si es tu primera vez en la serie, empieza por aquí:

https://www.handersonboratto.com/blog/que-es-ens/

👉 O continúa con el artículo anterior:

https://www.handersonboratto.com/blog/ens-gestion-configuracion-seguridad-op-exp-3/

Un fabricante publica un aviso de seguridad un jueves por la tarde: vulnerabilidad crítica en un componente que corre en media docena de servidores. La tentación es aplicar el parche esa misma noche y olvidarse. Pero antes hay preguntas que responder: ¿afecta a alguna función que tenemos deshabilitada? ¿lo hemos probado en algún sitio antes de tocar producción? ¿y si algo se rompe, cómo volvemos atrás?

Ese es exactamente el terreno de op.exp.4 — Mantenimiento y actualizaciones de seguridad. Si op.exp.3 — Gestión de la configuración se ocupaba de detectar cuándo algo cambia sin permiso, op.exp.4 se ocupa del cambio que sí queremos hacer nosotros: el parche, la actualización de firmware, la nueva versión de un producto. La pregunta que exige responder no es "¿lo has instalado?", sino "¿puedes demostrar que decidiste cómo y cuándo instalarlo, y que podías deshacerlo si salía mal?"

Dos velocidades: puestos y servidores

En los puestos de usuario la respuesta es sencilla porque está automatizada: las actualizaciones de seguridad se instalan solas, y solo los administradores de sistemas tienen permiso para tocar esa configuración. Nadie decide caso por caso si un puesto se parchea o no. La única excepción que exige más cuidado es un cambio de versión del sistema operativo, que ya no se trata como una actualización rutinaria sino que pasa por el procedimiento de gestión de cambios.

En servidores y elementos de red la historia es distinta, porque ahí sí hay que decidir, y esa decisión hay que poder justificarla después.

El proceso en servidores y elementos de red

Al menos una vez al mes se revisa qué parches y actualizaciones de sistema operativo, software y firmware han publicado los fabricantes. No basta con enterarse de que existe una actualización: el Responsable de Seguridad, o los administradores en quien delegue, leen las notas de la actualización y valoran su impacto real sobre el funcionamiento y la seguridad del sistema.

De ese análisis salen dos caminos distintos. Si la actualización afecta a una función que ya tenemos deshabilitada, se puede retrasar su instalación sin mayor urgencia. Si es una actualización crítica de seguridad, se aplica de inmediato, sin esperar a la ventana de mantenimiento habitual. Y cuando toca desplegarla, se hace en el horario en que menos afecte a los servicios: nadie parchea un servidor de producción a media mañana si puede evitarlo. Como en los puestos, un cambio de versión completo del sistema operativo se escapa de este proceso y entra en gestión de cambios.

Probar antes de tocar producción

Antes de poner en producción una versión nueva o parcheada, la instalamos primero en un entorno de pruebas que sea consistente en configuración con el de producción, y comprobamos que todo sigue funcionando y que ninguna función necesaria para el trabajo diario pierde eficacia. Solo después de esa comprobación, y con la autorización correspondiente conforme al procedimiento PS01 de gestión de autorizaciones, la actualización pasa a producción.

Es el mismo principio que aplicamos en otros controles de la serie: la prueba no vale si se hace “de memoria” en la propia máquina de producción cruzando los dedos. Tiene que existir un entorno separado, y tiene que quedar constancia de que se usó.

La red de seguridad: poder volver atrás

El tercer pilar, y probablemente el que más tranquilidad da el día que algo sale mal, es tener previsto cómo deshacer el cambio antes de aplicarlo, no después. El procedimiento contempla tres mecanismos, que se combinan según el tipo de activo: copias de seguridad del sistema y su configuración, snapshots en el caso de máquinas virtuales, y procedimientos manuales de reversión ya documentados y probados de antemano para lo que no se puede snapshotear.

En la práctica, en nuestro caso esto se traduce en algo muy concreto: siempre que se aplica una actualización sobre una máquina virtual, se genera antes un snapshot, y queda constancia por escrito —normalmente un correo— de que se ha hecho antes de tocar nada. El día que un parche deja un servicio en mal estado, la vuelta atrás no depende de que alguien recuerde cómo estaba configurado el sistema; depende de un punto de restauración que ya existía antes del problema.

La lección práctica

Si algo me llevo de este control es que op.exp.4 no evalúa si parcheas rápido, evalúa si puedes demostrar que sabías qué podía romperse y cómo lo ibas a arreglar antes de darle al botón. Aplicar un parche crítico el mismo día que se publica está bien y es lo correcto; hacerlo sin haber probado antes en un entorno de calidad y sin un snapshot reciente es jugar con ventaja solo en apariencia.

Mi recomendación, si estás montando esto desde cero: no dejes el snapshot o la copia como un paso “si hay tiempo”. Convierte la constancia de esa copia previa —el correo, el ticket, la captura— en un requisito bloqueante dentro de tu propio procedimiento de despliegue. Es la evidencia más barata de las tres, y la que más dolores de cabeza te ahorra el día que la necesitas de verdad.

Este post forma parte de la serie “ENS desde dentro”, donde comparto cómo se implementan y auditan en la práctica las medidas del Esquema Nacional de Seguridad. Si te está siendo útil, puedes suscribirte a la newsletter para recibir cada entrega, o descargar el checklist “Documentación para una auditoría ENS” con los 8 bloques de evidencia que un auditor va a pedirte.