Gestion de cambios

Uno de los aspectos fundamentales en la gestión de la seguridad (y de cualquier otra cosa) es la gestión de cambios. Todos nos sentimos relativamente cómodos gestionando aquello que no cambia, que es estático. Somos animales de costumbres. El problema es que los cambios son inevitables, y por tanto tenemos que ser capaces de afrontarlos. Una buena gestión de cambios es clave si queremos mantener nuestros niveles de seguridad a lo largo del tiempo...

En primer lugar, es importante identificar los cambios. Cambios que no tienen por qué ser internos o por iniciativa propia, sino que se pueden producir en el entorno. Y el punto crucial es ser capaces de detectarlos. Nuevas amenazas o vulnerabilidades quizás sean el ejemplo más socorrido, pero no tiene por qué ser el único. Cualquier factor del entorno, tanto cercano como lejano, puede cambiar, y nosotros tenemos que ser capaces de identificarlo y evaluarlo.

La segunda parte es, como acabo de indicar, evaluar el impacto de los cambios. Tanto directo como indirecto, tanto inmediato como a largo plazo. Ahora bien, hay que ser prácticos. No podemos evaluar absolutamente todas las consecuencias, muchas veces no sólo es poco rentable sino que es prácticamente imposible. No podemos estar evaluando infinitamente, la gestión de cambios debe seguir. Habrá que evaluar los pros y los contras más evidentes, sopesarlos, y decidir. Que habrá consecuencias que no hayamos previsto? Seguro. Y es que en cualquier decisión estamos asumiendo riesgos. Pero que conste que también lo hacemos si continuamos con nuestra evluación...

Decidir es el punto crítico. Hacer algo, o no hacer nada. Pero debemos tener en cuenta que la decisión de partida es no hacer nada. Mientras estamos evaluando, no estamos reaccionando al cambio. Estamos tomando, de facto, la decisión de no hacer nada. Y esa decisión tiene sus riesgos, al igual que la decisión de reaccionar al cambio. Sea cual sea la decisión, algo debe quedar patente: quién asume la decisión, sus motivos, y sus consecuencias. Y si estos tres factores quedan por escrito, mejor que mejor.

Hasta ahora hemos pensado que nuestra decisión de cambio es como reacción a otro cambio externo. En general suele ser así (reacciones a los cambios del entorno, del negocio, de las estrategias, ...), pero aun en caso de que el cambio sea originado internamente, la situación es idéntica: habrá que especificar quién decide (en base a sus funciones y responsabilidades), sus motivos, y las consecuencias previstas por dicha decisión.

Una vez que hemos recorrido el circuito de decisión del cambio, el resto es fácil. Hay que planificar (pensar) el cambio y cómo se va a llevar a cabo, ejecutarlo, verificarlo y registrarlo. El circuito típico. Sin embargo... cuántas veces se cumple por completo? Además, tenemos que tener en cuenta que dentro del ciclo de "ejecución" del cambio pueden aparecer nuevos factores que realimenten a la fase de decisión, y que puedan llegar a motivar su cambio. Esto no es algo que deba asustarnos, o que debamos evitar: una correcta gestión de cambios debe tenerlo en cuenta. Pero debe tenerlo en cuenta de esta forma, sin necesidad de una planificación "virtual" de todo el ciclo en la fase de decisión. Si no, nunca reaccionaremos a los cambios...

Quizás la mejor forma de ilustrar todo este ciclo es con un ejemplo. Pensemos en la publicación de una vulnerabilidad asociada a una aplicación de nuestro servidor central. El entorno ha cambiado. Cuál es la reacción asociada? Parchear. Qué inconvenientes tiene? Inestabilidad, mal funcionamiento, necesidad de una parada programada... Las ventajas también son claras: reducción del nivel de riesgo, que ha aumentado al publicarse la vulnerabilidad. Quién debe decidir? Supongamos que el director de sistemas, con el asesoramiento del responsable de seguridad y de los técnicos expertos en la aplicación y el servidor central. Qué decide?
Hasta este punto, la historia es más o menos sencilla. Pero... qué ocurre si el director de sistemas no cuenta con un entorno de pruebas para verificar la estabilidad del parche? O si el personal no tiene tiempo para realizar las pruebas? O si no cuenta con la asesoría necesaria? Sencillamente, que el riesgo de tomar la decisión aumenta. Pero esto en ningún caso significa que no pueda tomar la decisión. Y vuelvo a decir que mientras se llevan a cabo las pruebas, o se buscan recursos, se está tomando la decisión de no hacer nada, y por tanto asumir el riesgo asociado a la vulnerabilidad que se acaba de publicar.
Si el director de sistemas decide parchear, lo siguiente será planificar la parada, procedimentar el parcheo si es necesario, ejecutarlo, verificar la estabilidad del sistema tras la operación, registrar las tareas realizadas, ... Y que conste que todas estas fases son necesarias, no vale sólo con la ejecución. Por supuesto, "con cabeza": probablemente la instalación de una nueva fuente TrueTipe no requiera la misma profundidad de gestión que el parcheo de la base de datos Oracle. Aunque sí las mismas fases...

En resumen, una buena gestión de los cambios es clave para la seguridad. Tanto a nivel IT como a cualquier otro: documental, operativo, contractual, ... Nuestra gestión de cambios deberá ser integral, y asegurar que se cumplen todos los pasos en todos los entornos. Y si no, ser conscientes de que estamos asumiendo el riesgo de no realizar una correcta gestión de cambios. Cómo se cuantifica este riesgo? Eso ya es otra historia...