Coqueteando con el desastre: Por qué utilizar software EOL y EOSL es una mala idea

Puntos clave

• El software que ha entrado en EOL o EOSL ha perdido parte o todo el soporte del desarrollador, respectivamente, introduciendo un gran riesgo de vulnerabilidades de seguridad, incompatibilidad y obsolescencia
• Las empresas que permanecen con software EOL/EOSL tienden a pagar en exceso a los consultores cuando intentan mantener la solución funcional y, en última instancia, no abordan todas las lagunas/vulnerabilidades críticas.
• Las empresas que permanecen con tecnología obsoleta experimentan de media un 47% más de pérdidas que las que se mantienen al día (Kaspersky)
• La protección de datos y la ciberseguridad son categorías en las que el software es de misión crítica, muy complejo (por ejemplo, la necesidad de soportar muchas integraciones de terceros y la necesidad de evolucionar para hacer frente a amenazas modernas como el ransomware) y, por tanto, demasiado arriesgado para utilizarlo pasado el EOL/EOSL.
  

  ---

 

Fin de vida útil (EOL) y Fin de vida útil (EOSL) son dos términos que a veces entran en juego cuando un proveedor de software ha decidido poner fin a un producto.

En el espacio de la protección de datos, por ejemplo, hay dos productos de monitorización/análisis de copias de seguridad llamados Servergraph (Rocket Software) y NetBackup OpsCenter (Veritas). Estos productos entraron en “Fin de soporte limitado” y EOSL, respectivamente, a finales de mayo de 2024.

Los profesionales de TI entienden estos conceptos lo suficiente como para saber que tendrán que encontrar un sustituto para un producto que el proveedor de software haya programado para EOL y EOSL, aunque esa fecha esté muy lejana.

Pero, ¿cuándo es necesaria una sustitución?

¿Cuáles son las diferencias fundamentales entre EOL y EOSL, y tienen siquiera importancia en categorías críticas como la ciberseguridad y la protección de datos?

Para abordar estas cuestiones críticas, repasemos primero qué implican la EOL y la EOSL.

 

Final de la vida

He aquí algunas implicaciones para un producto que ha alcanzado el EOL, una fase que suele producirse antes del EOSL.

• No más desarrollo: La empresa dejará de desarrollar nuevas funciones o mejoras para el software.
• Asistencia limitada o nula: La asistencia oficial al cliente, incluida la resolución de problemas y la asistencia técnica, se reducirá o se interrumpirá por completo. Es posible que los usuarios ya no reciban ayuda con los problemas que encuentren.
• No habrá actualizaciones de seguridad: La empresa dejará de publicar parches o actualizaciones, incluidas las correcciones de seguridad críticas. Esto puede hacer que el software sea vulnerable a amenazas de seguridad.
• Problemas de compatibilidad: El software puede no estar actualizado para funcionar con nuevos sistemas operativos, hardware u otro software, lo que puede provocar problemas de compatibilidad.
• Animación a migrar: Normalmente se anima a los usuarios a migrar a versiones más recientes del software o a soluciones alternativas ofrecidas por la empresa u otros proveedores.
• Implicaciones en los costes: Seguir utilizando el software EOL puede suponer un aumento de los costes de mantenimiento, ya que el usuario puede tener que contratar consultores externos para el soporte o para garantizar que el software sigue siendo seguro y funcional.
• Riesgo de obsolescencia: Con el tiempo, el uso de software EOL puede provocar una degradación del rendimiento y una reducción de la eficacia, ya que se queda obsoleto.

Por tanto, aunque es posible utilizar un producto que ha alcanzado el EOL, hacerlo conlleva un mayor riesgo de vulnerabilidades de seguridad, incompatibilidad y obsolescencia.

También hay una paradoja interesante que suele ocurrir cuando las organizaciones deciden utilizar software pasado el EOL.

La decisión de utilizar un software después de su fin de vida se basa en la percepción de un ahorro de costes por no tener que comprar un software de sustitución. (Es decir, “Compré una licencia perpetua hace 10 años y no quiero tener que comprar software de sustitución”).

Aunque este planteamiento puede tener sentido en algunos casos, por ejemplo que un diseñador gráfico decida utilizar un software de diseño más allá de su fecha de caducidad, ciertas categorías críticas entrañan mucho más riesgo.

En ciberseguridad y protección de datos (copia de seguridad y recuperación), por ejemplo -funciones en las que las organizaciones sencillamente no pueden arriesgarse a fallos inoportunos del software-, la realidad es que las organizaciones que utilizan software más allá del EOL suelen gastar más en (1) pagar a consultores y desarrolladores externos en lo que a menudo acaban siendo esfuerzos fallidos para abordar las lagunas y problemas críticos que surgen más allá del EOL, y (2), limpiar el desastre cuando se explotan las lagunas.

Respecto a este último punto, Kaspersky descubrió que las empresas que utilizan tecnología obsoleta experimentan, de media, un 47% más de pérdidas globales (o unos 389.000 dólares más) por cada violación de datos.(fuente)

En el espacio de la protección de datos y las copias de seguridad, los costes adicionales tras un ataque de ransomware suelen estar asociados a la recreación de aplicaciones/sistemas de los que se debería haber hecho una copia de seguridad pero no se hizo, a menudo debido a una capacidad inadecuada de supervisión de las copias de seguridad.(Lee cómo la debacle del ransomware de varios meses de UnitedHealth Group en 2024 ilustra este punto).

Veamos ahora la EOSL, que suele seguir a la EOL y marca el final definitivo de un producto o línea de productos.

 

Fin de la vida útil (EOSL)

• Suspensión total de la asistencia: La empresa dejará de ofrecer cualquier tipo de soporte técnico, solución de problemas o servicio de atención al cliente para el producto. Los usuarios no tendrán acceso a los canales de asistencia oficiales para obtener ayuda.
• Sin actualizaciones ni parches: No habrá más actualizaciones, parches ni correcciones de errores, incluidas las actualizaciones de seguridad críticas. Esto puede dejar el software vulnerable a nuevas amenazas de seguridad y errores.
• Riesgos de compatibilidad: A medida que salen al mercado nuevas tecnologías, sistemas operativos y hardware, el producto EOSL puede ser cada vez más incompatible, lo que puede provocar problemas de funcionalidad o la imposibilidad total de utilizar el software.
• Asistencia de terceros: Los usuarios pueden tener que recurrir a proveedores externos o a foros de la comunidad para obtener la asistencia necesaria, lo que puede conllevar costes adicionales y distintos niveles de fiabilidad.
• Mayores riesgos de seguridad: Sin actualizaciones de seguridad, el producto puede convertirse en objetivo de ciberataques, y cualquier vulnerabilidad descubierta después de la EOSL quedará sin parchear.
• Urgencia de migración: Se recomienda encarecidamente a los usuarios que migren a versiones más recientes del producto o a soluciones alternativas para evitar interrupciones operativas y mantener la seguridad y la funcionalidad.
• Impacto empresarial potencial: Seguir utilizando el software EOSL puede provocar un aumento de los riesgos y costes operativos, afectando a la eficacia y seguridad generales de la empresa.

 

En relación con el EOL, utilizar un producto EOSL conlleva un riesgo financiero y de seguridad aún mayor debido al cese total del soporte. No hay actualizaciones ni parches, y si el producto no funciona por cualquier motivo -por ejemplo, si se rompe una integración con una aplicación de terceros-, estarás completamente solo y probablemente en un aprieto para sustituir el software.

 

¿Deberías utilizar software EOL/EOSL?

La decisión de utilizar software EOL/EOSL se reduce al apetito de riesgo de tu organización y a la finalidad y complejidad del software.

• Si el software no tiene una función crítica y es lo suficientemente sencillo como para que resulte difícil imaginarlo averiado una vez superada la EOSL, puedes asumir el riesgo calculado de seguir utilizándolo una vez superada la EOSL y no gastar dinero en sustituirlo.
• Sin embargo, si el software tiene una finalidad crítica en tu organización y es complejo (por ejemplo, software para la protección de datos, ciberseguridad, informes de auditorías normativas, facturación, etc.), el riesgo de que un software complejo deje de funcionar una vez superado el EOL o el EOSL es demasiado grande para que lo soporten la mayoría de las organizaciones. En estos casos, lo mejor es sustituir el software antes de la EOL y la EOSL, para evitar pérdidas de datos evitables, decisiones precipitadas (construir o comprar) y elevados honorarios de consultoría cuando el software sin soporte empiece a fallar.

 

Construir o comprar

Una decisión a la que se enfrentan a menudo los responsables de TI de las empresas en situaciones de EOL/EOSL es si “construir o comprar” el software de sustitución.

Al igual que con la decisión de utilizar o no software EOL/EOSL, la decisión de construir internamente o comprar software soportado y disponible en el mercado requiere una comprensión de la función y complejidad del software.

Si la función es de misión crítica (por ejemplo, la protección de datos o la seguridad) y el software es complejo de mantener (por ejemplo, software que requiere soportar integraciones basadas en API con aplicaciones de terceros o mantenerse al día sobre amenazas a la seguridad como el ransomware), crear tu propio software no suele ser sensato para la mayoría de las organizaciones. Aunque crear un sustituto internamente puede dar a las empresas una sensación de control al personalizar la solución, la gestión interna del producto y los recursos de ingeniería necesarios para mantener/actualizar el software complejo suelen dar lugar a gastos generales mucho mayores y a una menor flexibilidad frente a la compra de software listo para usar.

Sin embargo, en raras circunstancias, cuando el software en cuestión encaja perfectamente en el ámbito de desarrollo de tu organización (por ejemplo, si eres Google y estás decidiendo si crear o comprar un componente de tecnología publicitaria), puede haber razones de peso para crear tu propio software.

Una cosa que hay que tener en cuenta es que los expertos internos en la materia (PYME) y los campeones de proyectos van y vienen.

En Bocada, muchos de nuestros clientes de monitorización de protección de datos empresariales habían creado inicialmente una herramienta interna (antes de contratar a Bocada), sólo para experimentar más tarde los costes ocultos de mantenimiento y actualización de la herramienta. En muchos de estos casos, la marcha intempestiva o la jubilación de una PYME fue la gota que colmó el vaso y les obligó a abandonar la herramienta interna y adquirir software estándar de un proveedor establecido y especializado como Bocada.