Aplicación de parches en un entorno pequeño

En los departamentos de TI empresariales, la aplicación de parches a los sistemas es un proceso complicado que implica grandes cantidades de sistemas de prueba que reflejan los sistemas de producción, de modo que cada nuevo parche que llega de los proveedores de sistemas operativos y de software pueda probarse en un entorno real para ver cómo interactúa con las combinaciones de hardware y software disponibles en la organización. En un mundo ideal, cada departamento contaría con un proceso gestionado de aplicación de parches que respondiera de inmediato a los parches recién publicados, los probara al instante y los aplicara tan pronto como se considerara que el parche era seguro y aplicable. Pero el mundo no es ideal y en la vida real tenemos que arreglárnoslas con recursos limitados: físicos, temporales y financieros.

Por lo general, los parches se publican por algunas razones clave: seguridad, estabilidad, rendimiento y, en ocasiones, para incorporar nuevas funciones. Salvo por la incorporación de nuevas funciones, que normalmente se gestiona mediante un proceso de publicación diferente, los parches representan la corrección de un problema conocido. Esto no es un escenario de “si no está roto, no lo arregles”, sino un escenario de “está roto y aún no ha fallado por completo”, que exige atención, cuanto antes mejor. Adoptar un enfoque de “sentarse a esperar” con los parches es imprudente, ya que la existencia de un nuevo parche significa que los hackers maliciosos tienen una “solución” que analizar e, incluso si no existía un exploit previamente, existirá muy pronto. La propia publicación del parche puede ser el detonante de la necesidad inmediata de dicho parche.

Este ecosistema de parches crea la necesidad de una mentalidad de “aplicar parches rápidamente”. Los parches nunca deben quedarse en espera; deben aplicarse, a menudo, tan pronto como se publican y se prueban. Esperar para aplicar los parches puede significar operar con fallos de seguridad críticos o mantener los sistemas innecesariamente poco fiables.

Los departamentos de TI pequeños rara vez, si es que alguna vez, cuentan con entornos de prueba, ya sea para servidores, equipos de red o incluso equipos de escritorio. No es lo ideal pero, siendo realistas, aunque esos entornos estuvieran disponibles, pocos departamentos pequeños cuentan con el excedente de recursos humanos de TI necesario para ejecutar esas pruebas de manera oportuna.

Esto no es tan desalentador como parece. Las pruebas que se realizan para la mayoría de los parches son redundantes con la aplicación de parches que el proveedor ya ha probado. Los proveedores no pueden probar todas las interacciones de hardware y software que pudieran llegar a producirse con sus productos, pero por lo general prueban amplios rangos de combinaciones y examinan las áreas donde las interacciones son más probables. Es raro que un proveedor importante inutilice su propio software con parches defectuosos. Sí, ocurre, y contar con buenas copias de seguridad y planes de reversión es importante, pero en las operaciones del día a día, la aplicación de parches es un proceso relativamente seguro que es mucho más importante realizar con prontitud que esperar oportunidades que pueden o no presentarse.

Como cualquier cambio en un sistema, los parches se aplican mejor en dosis frecuentes y pequeñas. Si los parches se aplican con prontitud, normalmente solo hay que aplicar uno o unos pocos parches al mismo tiempo. En el caso de los sistemas operativos, es posible que aún tenga que lidiar con varios parches a la vez, especialmente si solo aplica parches semanalmente, pero rara vez tendrá que parchear docenas o cientos de archivos al mismo tiempo cuando se hace de esta manera. Cuando se hace así, resulta muchísimo más fácil evaluar los parches en busca de efectos adversos y revertirlos si un proceso de aplicación de parches sale mal.

El peor escenario para una pequeña empresa que carece de un flujo de trabajo adecuado para probar parches es esperar para aplicarlos. Esperar significa que los sistemas pasan largos periodos de tiempo sin el cuidado necesario y, cuando finalmente se aplican los parches, suele ser en procesos de parcheo masivos y de gran volumen. Aplicar muchos parches a la vez aumenta las probabilidades de que algo salga mal y, cuando ocurre, identificar cuál o cuáles parches son los responsables y trazar una ruta de solución puede resultar mucho más difícil.

La aplicación tardía de parches es un proceso que aporta poca o ninguna ventaja, ni para TI ni para la empresa, pero que sí conlleva un riesgo considerable para la seguridad, la estabilidad y el rendimiento. Las mejores prácticas para la aplicación de parches en un entorno pequeño consisten en permitir que los sistemas se autoparcheen lo más rápido posible o en programar un proceso de aplicación de parches periódico, quizá semanal, durante un momento en el que la empresa esté mejor preparada para que la aplicación de parches falle y se gestione su corrección. Tanto si opta por aplicar parches de forma automática como si simplemente lo hace de forma periódica mediante un proceso manual, aplique los parches con frecuencia y prontitud para obtener los mejores resultados.