El fin de la vida útil del software es un hecho de nuestra acelerada vida tecnológica. Los equipos técnicos saben que deben gestionar el ciclo de vida del software. Los equipos también saben que deben evitar a toda costa ejecutar software fuera de soporte.

Sin embargo, a veces las organizaciones acaban en apuros por culpa del software que ha llegado al final de su vida útil, y a veces no es culpa suya.

En este artículo, hablaremos de estrategias para gestionar el software que llega al final de su vida útil, centrándonos en los sistemas operativos, aunque nuestros consejos también son válidos para cualquier tecnología que llegue al final de su vida útil, ya sea hardware o software.

¿Qué significa el final de la vida?

Para seguir el ritmo de los cambios tecnológicos, la mayoría de las soluciones de software se renuevan cada dos años. Se espera que los usuarios migren a versiones más recientes del software, pero también necesitan tiempo para completar esa migración, sobre todo cuando se trata de algo como un sistema operativo.

Por eso, una versión de software que ha sido sustituida por otra más reciente goza de un apoyo continuado: da tiempo a realizar pruebas y migraciones.

Sin embargo, en algún momento, el proveedor de software debe dar por terminadas las versiones antiguas de su software. No es realista seguir dando soporte a un sistema operativo de hace 30 años, por ejemplo.

End of life (EOL) es como describimos este tipo de software, que ya no recibe soporte ni mantenimiento por parte del proveedor. Significa que el fabricante ya no proporcionará actualizaciones, correcciones de errores ni soporte técnico y, en la mayoría de los casos, tampoco habrá actualizaciones de seguridad críticas.

Así que no espere un parche del proveedor si se encuentra un fallo de seguridad grave en un sistema operativo que ha llegado al final de su vida útil. En su lugar, el proveedor espera que, a estas alturas, los usuarios como tú hayan pasado a una versión compatible del sistema operativo.

Como consecuencia, cualquiera que confíe en un software que haya llegado al final de su vida útil y que no cuente con el apoyo del proveedor estará expuesto a brechas de seguridad, ya que no podrá aplicar un parche proporcionado por el proveedor para protegerse de las vulnerabilidades recién descubiertas.

¿Por qué es un problema el software obsoleto?

La frase "fin de vida" lo dice todo, y los administradores de sistemas no deberían necesitar mucha más motivación para actualizarse a la última versión de un sistema operativo antes de que sea demasiado tarde. Además, en la práctica, los equipos técnicos tienen suficiente antelación porque los proveedores de software publican los calendarios de soporte con mucha antelación.

Entonces, ¿qué es lo que falla? ¿Por qué es tan común el uso de software al final de su vida útil, a pesar de los riesgos?

Hay varias razones. El software al final de su vida útil es engañosamente estable porque, después de todo, todo sigue funcionando. ¿Por qué desechar una solución que cumple su función a la perfección sólo por problemas de seguridad espurios?

Actualizar un servidor al sistema operativo de última generación es, cuando menos, un engorro, por lo que muchos administradores retrasan el proceso. A veces, simplemente hay muy pocos recursos de personal para migrar de todos modos.

Existe una preocupación por el riesgo: que la versión actual funcione sin problemas no significa que la última versión vaya a funcionar sin problemas. Es posible que el software instalado actualmente no funcione con las versiones más recientes y que los cambios de configuración provoquen interrupciones.

No obstante, migrar a una versión compatible y parcheada de un sistema operativo es una responsabilidad primordial de los equipos técnicos y, en la mayoría de los casos, puede y debe hacerse a tiempo.

CentOS como ejemplo de precaución

Hemos dicho "en la mayoría de los casos" porque tener problemas con el software EOL no es necesariamente culpa de administradores de sistemas con exceso de trabajo o negligentes. Puede haber una variedad de razones detrás de las implicaciones prácticas de ejecutar software al final de su vida útil, incluidas las decisiones del proveedor.

Eso es lo que ha ocurrido con CentOS. CentOS es una distribución de Linux muy utilizada que se basa en Red Hat Enterprise Linux (RHEL). CentOS fue célebre por ser una alternativa gratuita y de código abierto a RHEL que se adaptaba bien a los centros de datos y otras aplicaciones de nivel empresarial.

En diciembre de 2021, Red Hat anunció abruptamente que dejaría de dar soporte a CentOS, creando un precipicio de fin de vida para algunas distribuciones de CentOS.

El repentino anuncio del fin de la vida útil de CentOS dejó a muchas organizaciones sin un sistema operativo estable y fiable, ya que recuperar el soporte del proveedor significaba desembolsar importantes sumas para RHEL o probar y cambiar a una alternativa como AlmaLinux o RockyLinux.

El resultado neto es que un número significativo de organizaciones están ejecutando máquinas CentOS 6 o CentOS 8 al final de su vida útil sin soporte del proveedor. Y esto realmente importa porque las organizaciones que tenían estrategias pobres en torno al software al final de su vida útil terminaron en una situación muy difícil.

Por qué es importante: Seguridad

Bien, veamos con más detalle por qué es tan importante utilizar un sistema operativo que ha llegado al final de su vida útil. Con mucho, la mayor amenaza de utilizar un sistema operativo EOL son las vulnerabilidades encontradas después de la fecha de caducidad del soporte. ¿Por qué? Porque el proveedor no publicará parches para ellas.

Por ejemplo, el kernel 2.6.32 de Linux hace tiempo que se retiró, pero se han descubierto muchas vulnerabilidades desde que llegó al final de su vida útil, incluso en fechas tan recientes como 2019. Cualquier servidor Linux que ejecute distribuciones basadas en el kernel antiguo sería vulnerable a ataques de denegación de servicio.

Dejar instalado un sistema operativo EOL significa que no recibirás más parches de seguridad, por lo que cada anuncio público de vulnerabilidad convierte a tu servidor en un blanco abierto. Sin parches, los administradores no pueden proteger la infraestructura.

La probabilidad de ataque también es mayor de lo que se piensa: como muchos servidores están a disposición del público y los atacantes utilizan herramientas de escaneado automatizadas, existe un riesgo real de que los atacantes acaben detectando que los servidores son vulnerables.

Esencialmente, los atacantes toman las huellas dactilares de su arquitectura 24 horas al día, 7 días a la semana, y se abalanzan sobre un sistema operativo vulnerable y sin soporte. Las consecuencias pueden ser nefastas.

Por qué es importante: Riesgo de cumplimiento

Las normas que regulan la información financiera y sanitaria exigen procedimientos específicos de ciberseguridad que protejan los datos de los clientes. La ejecución de software no compatible y sin parches va directamente en contra de los mandatos de varias de estas normas de cumplimiento.

Esto incluye la aplicación de parches a vulnerabilidades críticas en un plazo determinado. Pero, ¿y si no puede obtener un parche? Del mismo modo, la normativa de cumplimiento estipula que las organizaciones cubiertas tienen prohibido utilizar software que no esté cubierto por el soporte del proveedor o de terceros.

Por ejemplo, los requisitos PCI DSS cubren a las empresas que manejan datos de tarjetas de pago e incluyen una exigencia específica de que las vulnerabilidades críticas se parcheen en un plazo de 30 días. Las organizaciones que no cumplan ese plazo serán declaradas no conformes con PCI DSS.

Un software obsoleto puede dar lugar a cuantiosas multas y demandas residuales que podrían prolongarse durante años después de una filtración de datos. Por ejemplo, una demanda de 40 millones de dólares por la filtración de datos de Target en 2013 no se resolvió hasta 2016.

Por qué es importante: Lo mejor del resto

Si la preocupación por la ciberseguridad y el cumplimiento de las normativas en torno a la ejecución de software al final de su vida útil no es lo suficientemente alarmante, le sugerimos que tenga en cuenta también las siguientes razones:

• Software incompatible: Cuando un sistema operativo deja de recibir soporte, los desarrolladores de aplicaciones de terceros también dejan de dar soporte al sistema antiguo. Es posible que las actualizaciones de las aplicaciones actuales provoquen problemas con el sistema operativo antiguo, o que el software simplemente deje de funcionar con el sistema operativo EOL.
• Mal rendimiento: No es raro que el software antiguo se ejecute en hardware antiguo. Esto significa que los cuellos de botella pueden deberse a una infraestructura más antigua en la red. Al confiar en un sistema operativo obsoleto, también se pierden las mejoras de rendimiento inherentes a las últimas versiones del sistema operativo.
• Fiabilidad: Como las aplicaciones más antiguas ya no reciben soporte, los fallos y errores tampoco se parchean. Si el software falla, su servidor podría dejar de arrancar, lo que afecta a los SLA y al tiempo de actividad.
• Costes elevados: Poner tiritas constantemente para arreglar y mantener un software que ya no recibe soporte del proveedor se convierte rápidamente en algo costoso, y nunca se sabe cuándo un fallo inesperado le va a afectar al bolsillo. Los desarrolladores de software EOL cobran una prima por soporte por dispositivo, lo que puede resultar caro para una gran organización.

Así que sí, puede parecer que tus sistemas operativos EOL funcionan perfectamente, pero la verdad es mucho más siniestra, y lo más probable es que te topes con un muro más pronto que tarde. Para empezar, hay que saber dónde estamos expuestos en términos de software al final de su vida útil.

Empezar por establecer el statu quo

Si aún no dispone de una estrategia de inventario, es hora de que la adopte. No se trata sólo de software; el hardware también puede llegar a un punto en el que sea hora de retirarlo. La gestión del inventario ayudará a identificar qué infraestructura y software deben actualizarse y qué infraestructura debe retirarse.

Un proceso de inventario pone de manifiesto qué software ha llegado al final de su vida útil y permite a los departamentos de TI identificar de forma rápida y sencilla qué software ya no recibe soporte del proveedor, si es el caso, y hacer planes para actualizarlo o sustituirlo lo antes posible.

Basándose en su inventario, identificará qué máquinas o nodos ejecutan un SO que está próximo al final de su vida útil, y dónde tiene tiempo de sobra para abordar el fin de su vida útil. Su proceso de inventario también debe identificar qué instancias del SO que han llegado al final de su vida útil (o están a punto de hacerlo) son las más críticas, para que pueda priorizar las acciones de eliminación, retirada o sustitución de las instancias.

Con un proceso de inventario en marcha, las organizaciones pueden planificar la sustitución o actualización eficiente del software que llega al final de su vida útil, reduciendo el riesgo de tiempos de inactividad inesperados o fallos de seguridad.

Migre tan rápido como pueda, si puede

Actualizar el software y los sistemas operativos a las últimas versiones puede convertirse rápidamente en una bola de nieve. La migración debe completarse lo antes posible para evitar una reacción en cadena de actualizaciones retrasadas, y para evitar migrar con prisas, lo que puede acabar rompiendo cosas.

Por tanto, la planificación es fundamental. Con un inventario exhaustivo en la mano y trabajando con los calendarios EOL de los proveedores, los equipos técnicos deben ser capaces de programar la migración de una manera que reduzca la presión, pero que también haga el trabajo a tiempo.

Es necesario actualizar la infraestructura de misión crítica, pero siempre hay que probar primero un nuevo sistema operativo. Una réplica de la producción en un entorno de ensayo puede ayudar a eliminar cualquier problema imprevisto durante la migración.

Retirarlo también es una opción. Con el tiempo, si no actualizas un servidor, puede que haya llegado el momento de retirarlo. Una alternativa es trasladar los equipos retirados a la nube y migrar a un entorno virtualizado.

Considere la posibilidad de contratar asistencia ampliada

Migrar a tiempo no siempre es una opción. Puede ocurrir que lo único que necesite sean unos meses más para probar a fondo su plan de migración. Afortunadamente, en muchos casos se dispone de asistencia ampliada del proveedor o de terceros.

Este precio suele ser por dispositivo y puede resultar caro. Por ejemplo, el fin de vida útil de Windows 7 era enero de 2020 y el primer año de soporte cuesta 25 dólares/dispositivo y 100 dólares/dispositivo. En cuanto a las distribuciones de Linux, proveedores como Ubuntu y Red Hat Enterprise Linux ofrecen soporte ampliado, pero sólo a los clientes que se suscriben a planes integrales para empresas (con un coste significativo).

Otra opción son los proveedores externos. Siempre que encuentre un proveedor fiable, puede adquirir asistencia ampliada a precios muy razonables. Por ejemplo, el soporte extendido del ciclo de vida de TuxCare de TuxCare para las versiones de CentOS y Ubuntu al final de su vida útil, desde sólo 4,25 USD/servidor/mes.

Los servicios de asistencia ampliada de este tipo también acaban agotándose, ya que los vendedores y proveedores limitan la asistencia ampliada a, por ejemplo, 4 o 5 años. Dicho esto, el soporte ampliado del ciclo de vida permite ganar mucho tiempo en los casos en los que la planificación no ha funcionado..

Opciones de último recurso

Así que sí, a veces simplemente no funciona. No puedes migrar lo suficientemente rápido, no hay soporte extendido disponible o, por alguna razón, tu carga de trabajo simplemente requiere que ejecutes un sistema operativo al final de su vida útil en su estado actual, te guste o no.

Si es absolutamente necesario ejecutar un sistema operativo sin soporte, sin parches y potencialmente vulnerable, es necesario pensar desde una perspectiva de aislamiento y gestión de riesgos:

• Aislamiento de red: utilizan una red separada para evitar que los sistemas que ejecutan un SO no compatible interactúen con cualquier máquina externa. Al bloquear el acceso a otros dispositivos de la red y a Internet, la segmentación de la red puede a veces proteger los dispositivos EOL de posibles amenazas, aunque no es una solución hermética y tiene un precio de eficacia.
• Virtualización para el aislamientoalojamiento de sistemas operativos fuera de uso en entornos virtualizados: el alojamiento de sistemas operativos fuera de uso en entornos virtualizados mejora el control sobre estos activos, facilitando la reimagen si se produce un incidente de seguridad y limitando al mismo tiempo la exposición del sistema fuera de uso al entorno exterior. Los activos en cuestión también pueden aislarse y reinicializarse rápidamente.
• Control de aplicaciones y listas blancas: similar a las sugerencias anteriores, esta estrategia aísla el sistema operativo vulnerable permitiendo que sólo las aplicaciones "buenas" conocidas se ejecuten en él - e interactúen con él. Se trata de un modelo que deniega el acceso por defecto, permitiendo únicamente conexiones preaprobadas.

No obstante, tratar de salirse con la suya ejecutando un SO no soportado segregándolo es sin duda una estrategia arriesgada - hay innumerables vectores de ataque y existe la posibilidad de que un poco de movimiento lateral por parte de un atacante astuto pueda frustrar tus esfuerzos de aislamiento.

Conclusión

Con una planificación suficiente, no debería ser necesario tomar medidas desesperadas, como aislar los equipos que ejecutan sistemas operativos no compatibles. Lo ideal es que un equipo migre a tiempo y ejecute siempre un sistema operativo compatible que se mantenga seguro gracias a parches de proveedores fácilmente accesibles.

Pero la vida tecnológica puede interponerse en el camino, incluidas las decisiones precipitadas de los proveedores, como ilustramos con el ejemplo de CentOS.

En estos casos, obtener ayuda de terceros puede hacer ganar mucho tiempo.. Un plan de soporte del proveedor original podría hacer el trabajo (a un coste elevado). Sin embargo, si estás ejecutando CentOS, Oracle Linux o Ubuntu al final de su vida útil, entonces deberías considerar la compra de soporte extendido de un experto como TuxCare, que ofrece actualizaciones de seguridad continuas por un coste mucho más asequible que los proveedores de distribución.

Resumen

Nombre del artículo

Estrategias para gestionar el final de la vida útil del sistema operativo

Descripción

Hablaremos de estrategias para gestionar el software que llega al final de su vida útil, centrándonos en los sistemas operativos, ya sean hardware o software.

Autor

Stephan Venter

Nombre del editor

TuxCare

Logotipo de la editorial