ENS desde dentro (XXIII): Gestión del cambio (op.exp.5) — qué modificación necesita papeles y cuál no

Actualizar el firmware de tres servidores físicos de virtualización no suena a algo que necesite una petición formal. Y sin embargo, es exactamente el tipo de modificación que op.exp.5 quiere ver documentada.

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-mantenimiento-actualizaciones-seguridad-op-exp-4/

Si op.exp.4 se ocupaba de decidir cuándo aplicar un parche, op.exp.5 amplía esa misma lógica a cualquier modificación del sistema: qué cuenta como cambio, cómo se evalúa su riesgo, quién lo autoriza y qué evidencia queda de todo el proceso. Aquí es donde la gestión de cambios deja de ser una buena intención y se convierte en un procedimiento con plantilla.

Qué cuenta como cambio (y qué no)

No todo lo que se toca en producción es un cambio a efectos de este control. Se considera cambio cualquier modificación que incorpore nuevas funcionalidades, introduzca nuevas categorías de información a tratar, afecte a las medidas de seguridad implementadas, altere la arquitectura de seguridad o suponga una actualización de versión principal del software. Actualizar el firmware de un host de virtualización, mover un servicio a otra arquitectura o desplegar una versión mayor de un ERP entran claramente en esta categoría.

Lo que queda fuera, y esto es tan importante como la lista anterior, son las actuaciones rutinarias de operación, el mantenimiento ordinario o las tareas repetitivas ya autorizadas que no tienen impacto significativo sobre la seguridad, la disponibilidad o la arquitectura. No todo necesita un ticket de cambio: si lo tuviera, el proceso se ahogaría en burocracia y nadie lo seguiría.

Cómo se registra: un ticket con tres datos mínimos

Toda petición de cambio queda registrada, ya sea mediante ticketing o mediante un anexo de petición de cambio, y necesita como mínimo tres cosas: un identificador único de la solicitud, una descripción del cambio y una evaluación del riesgo. El responsable que detecta la necesidad del cambio registra la solicitud, y es el personal responsable quien la evalúa, completando el análisis de riesgo, las medidas adicionales necesarias y el mecanismo de reversión previsto.

Una vez ejecutado el cambio y validado, toda esa documentación se archiva con una nomenclatura única y localizable —algo tan simple como identificar cada carpeta con el año y un número de cambio correlativo ya resuelve el problema de encontrar la evidencia seis meses después, cuando el auditor pregunta por ella.

Evaluar el riesgo con una plantilla, no a ojo

Aquí está el punto que más diferencia a una organización madura de una que improvisa: el riesgo del cambio no se decide por intuición, se calcula con un cuestionario cerrado de diez preguntas de sí/no —¿implica tratar nuevas tipologías de datos?, ¿interconecta con nuevos sistemas?, ¿cambia los mecanismos de autenticación?, ¿afecta a la seguridad de otros sistemas?, entre otras—. El número de “sí” obtenido clasifica el cambio en bajo (tres o menos), medio (entre cuatro y seis) o alto (más de seis).

Un ejemplo real: una actualización de firmware, BIOS y controladora de gestión remota en los servidores físicos que sostienen la plataforma de virtualización, ejecutada en ventanas de mantenimiento planificadas, obtuvo un único “sí” —podía afectar a la seguridad de otros sistemas, por depender de ella toda la infraestructura virtualizada— y se clasificó como riesgo bajo. Ese resultado no exime de documentar el cambio; simplemente determina qué nivel de autorización y qué medidas adicionales aplican. Los cambios de riesgo alto, en cambio, necesitan la aprobación explícita del Comité de Seguridad, no basta con la autorización habitual del responsable técnico.

Antes de tocar nada: probar y prever la vuelta atrás

Siempre que es posible, el cambio se prueba primero en un entorno de preproducción equivalente al de producción, al menos en los elementos concretos que va a afectar. Y antes de desplegar, se genera una copia de las configuraciones y versiones estables de los activos implicados —backups, snapshots de máquinas virtuales, exportación de configuraciones o procedimientos de recuperación ya documentados— con el objetivo de poder volver al estado anterior en el menor tiempo posible si algo sale mal.

Dos ejemplos reales ilustran cómo se aplica esto en la práctica. En una actualización de los entornos de un ERP corporativo (desarrollo y calidad), antes de tocar nada se coordinó la intervención con la consultora externa responsable, se detuvieron los servicios de forma controlada, se deshabilitaron temporalmente las alertas de monitorización para evitar ruido, se generaron snapshots y copias de seguridad con los servicios ya parados, y se confirmó que había espacio suficiente en el almacenamiento antes de empezar. Solo después de verificar que todo funcionaba correctamente se reactivaron las alertas y se dio el cambio por cerrado.

El segundo caso es la actualización de la plataforma corporativa de copias de seguridad para corregir una vulnerabilidad crítica de severidad alta (CVE pública, con puntuación 9.9). Antes del cambio se coordinó con el proveedor externo la secuencia de actualización —primero el servidor central, después los agentes en los servidores afectados—, se confirmó la compatibilidad de versiones y se dispuso de un snapshot previo como red de seguridad. Durante el proceso apareció un fallo puntual en los backups de logs que se resolvió solo al finalizar la actualización; el snapshot no llegó a necesitarse, pero estar ahí es lo que convierte un incidente menor en una anécdota en vez de en una noche sin dormir.

Autorización según el riesgo, no según la costumbre

Una vez evaluado el riesgo, se decide si el cambio se implementa o se desestima, y esa decisión requiere autorización conforme al procedimiento de gestión de autorizaciones, en función de los elementos afectados. La única regla que no admite excepción: cualquier cambio de riesgo alto necesita el visto bueno explícito del Comité de Seguridad, no solo el del responsable técnico que lo ejecuta.

La lección práctica

Si algo me llevo de este control es que la plantilla de evaluación de riesgo no es papeleo, es lo que evita que "esto seguro que no afecta a nada" se convierta en la frase que precede a un incidente. Rellenar diez preguntas de sí/no lleva cinco minutos; reconstruir qué se rompió y por qué, sin haber pensado antes en el mecanismo de reversión, puede llevarte toda una noche.

Mi recomendación: no reserves la plantilla de riesgo para los cambios que "obviamente" son grandes. Los cambios que salen mal casi nunca son los que parecían arriesgados desde el principio —son los rutinarios que nadie paró a evaluar.

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.