Hay una frase que aparece con bastante frecuencia cuando se revisa la infraestructura tecnológica de una empresa: “Ese servidor es viejo, pero todavía funciona”. En principio, no parece una mala noticia. Si el servidor responde, las aplicaciones funcionan y los usuarios pueden trabajar, ¿para qué cambiarlo? Pero, en infraestructura tecnológica que algo siga funcionando no significa necesariamente que siga siendo seguro.
Un servidor, un firewall, un switch o incluso una aplicación pueden continuar operativos durante muchos años y, al mismo tiempo, convertirse en uno de los puntos más débiles de la red. El riesgo aparece especialmente cuando el fabricante dejó de proporcionar soporte, ya no existen parches de seguridad o el equipo depende de tecnologías que dejaron de considerarse seguras.
Eso es, en términos generales, lo que ocurre con la infraestructura legacy. Y no siempre se trata de equipos de hace 15 o 20 años. En algunos casos, un sistema relativamente reciente puede convertirse en legacy mucho antes de lo que la empresa esperaba.
¿Qué entendemos realmente por infraestructura legacy?
El término legacy se utiliza para identificar tecnología antigua que continúa formando parte de una operación, aunque ya no represente el estándar tecnológico actual. Puede ser un servidor con una versión antigua de Windows Server, una solución desarrollada sobre una versión descontinuada de Java, un firewall que ya no recibe actualizaciones de firmware o incluso un sistema ERP que depende de componentes que dejaron de tener soporte.
Microsoft, por ejemplo, ha tenido durante años diferentes ciclos de soporte para sus sistemas operativos Windows Server. Cuando una versión llega a su fin de soporte, la infraestructura no deja de funcionar mágicamente al día siguiente. El servidor continúa encendiendo, las aplicaciones siguen ejecutándose y los usuarios probablemente ni siquiera noten la diferencia.
Pero cambia algo importante: el fabricante deja de garantizar que las nuevas vulnerabilidades serán corregidas. Ahí empieza el problema.
Un equipo viejo no necesariamente es un equipo inseguro
Aquí vale la pena hacer una precisión. No sería técnicamente correcto afirmar que cualquier equipo antiguo representa automáticamente un riesgo de ciberseguridad. La edad es solamente una variable.
Un servidor antiguo que está aislado de Internet, correctamente segmentado, con acceso restringido y con controles compensatorios puede representar menos riesgo que un equipo nuevo mal configurado, expuesto directamente a Internet y con credenciales débiles.
Por eso, cuando se hace una evaluación de infraestructura, normalmente hay que mirar varias cosas al mismo tiempo:
- Estado de soporte del fabricante.
- Sistema operativo y versión.
- Firmware.
- Vulnerabilidades conocidas.
- Exposición a Internet.
- Servicios habilitados.
- Nivel de segmentación.
- Tipo de información que procesa.
- Criticidad para el negocio.
- Posibilidad real de reemplazo.
La combinación de estos factores es mucho más importante que simplemente saber cuántos años tiene el equipo.
El verdadero problema aparece cuando deja de recibir parches
Uno de los mayores riesgos de mantener infraestructura legacy es trabajar con sistemas que ya no pueden actualizarse.
El caso de Windows XP es bastante ilustrativo. Aunque Microsoft terminó oficialmente su soporte general en 2014, durante años siguieron existiendo organizaciones que dependían de computadores con este sistema operativo porque determinadas aplicaciones o equipos especializados todavía lo necesitaban.
El ataque WannaCry, ocurrido en 2017, demostró por qué mantener sistemas antiguos sin una estrategia de seguridad adecuada puede convertirse en un problema serio. El ransomware explotó una vulnerabilidad relacionada con el protocolo SMB y afectó a organizaciones de diferentes sectores. Uno de los casos más conocidos fue el del NHS británico, donde numerosos servicios se vieron afectados por el ataque. La lección no fue simplemente “Windows XP era viejo”.
Fue algo más importante: una vulnerabilidad conocida, combinada con sistemas sin las condiciones adecuadas de actualización y segmentación, puede terminar convirtiéndose en un problema operativo real. Y ese principio sigue siendo completamente válido hoy.
Cuando el fabricante dice “End of Life”
En infraestructura empresarial, una de las fechas que deberían tenerse muy presentes es el End of Life (EOL) de un producto. Fabricantes como Cisco, Fortinet, Dell, HPE, VMware y Microsoft publican ciclos de soporte para sus diferentes productos y versiones. Cuando una plataforma entra en EOL, la organización debería preguntarse qué va a hacer con ella.
No necesariamente significa que haya que apagarla inmediatamente. En muchos casos existen razones técnicas o económicas para mantenerla durante algún tiempo. Pero debería existir un plan.
El problema es cuando pasan dos, tres o cinco años después del EOL y el equipo continúa funcionando exactamente igual, sin una estrategia de migración. En ese momento ya no estamos hablando solamente de una decisión tecnológica. Estamos hablando de gestión de riesgo.
El caso de VMware muestra que el problema también puede ser estratégico
Un ejemplo más reciente es el ecosistema VMware después de su adquisición por Broadcom. La adquisición y los posteriores cambios en el modelo de licenciamiento y comercialización obligaron a muchas organizaciones a revisar decisiones que durante años parecían bastante estables.
Esto demuestra algo importante: la obsolescencia no siempre llega porque el hardware deje de funcionar.
También puede llegar por cambios en:
- Licenciamiento.
- Soporte.
- Modelo comercial.
- Compatibilidad.
- Costos de mantenimiento.
- Integraciones.
- Disponibilidad de especialistas.
Una plataforma puede seguir siendo técnicamente funcional y, sin embargo, dejar de ser conveniente desde el punto de vista estratégico o financiero.
El problema oculto: nadie sabe exactamente cómo funciona
Este es probablemente uno de los escenarios más delicados. Hay empresas donde un servidor antiguo funciona perfectamente, pero nadie quiere reiniciarlo porque nadie está completamente seguro de qué servicios tiene instalados. Puede sonar exagerado, pero sucede.
Con los años, un servidor puede acumular configuraciones, scripts, servicios, usuarios, reglas de firewall y conexiones con otros sistemas. El administrador que originalmente lo configuró puede ya no trabajar en la compañía. Entonces aparece una especie de “conocimiento tribal” de la infraestructura: Alguien sabe que el servidor existe, otra persona sabe para qué sirve, otra recuerda que “no se puede tocar porque ahí corre el sistema de facturación”. Y posiblemente nadie tenga documentado todo el mapa de dependencias.
Desde el punto de vista de ingeniería, esto es una señal clara de deuda técnica.
La infraestructura legacy también puede convertirse en una puerta de entrada
Supongamos que una empresa mantiene un servidor antiguo que necesita utilizar un protocolo de comunicación que actualmente se considera inseguro. Para que la aplicación continúe funcionando, el equipo de TI termina creando una excepción en el firewall.
Después aparece otra excepción para permitir que determinado usuario acceda desde otra red. Y posteriormente se habilita un servicio adicional porque una integración antigua lo necesita. Individualmente, cada decisión puede tener sentido. El problema aparece cuando se acumulan.
La arquitectura termina construyéndose alrededor de las limitaciones del sistema legacy, en lugar de que el sistema forme parte de una arquitectura diseñada bajo criterios actuales de seguridad. Es ahí donde la deuda técnica comienza a convertirse en superficie de ataque.
¿Hay que cambiar todos los equipos antiguos?
No, definitivamente esto no es necesario. De hecho, intentar reemplazar absolutamente todo puede ser una mala estrategia. Lo correcto es establecer prioridades.
Un switch antiguo que solamente conecta dispositivos de una red aislada puede tener una prioridad relativamente baja. Un firewall que controla la conexión principal de una empresa y ya no recibe actualizaciones debería tener una prioridad completamente diferente. Lo mismo ocurre con los servidores.
Un servidor antiguo que almacena información histórica y no está conectado directamente a sistemas críticos puede administrarse de una manera. Un servidor legacy que maneja autenticación, bases de datos, archivos corporativos o sistemas financieros requiere otra estrategia.
Una buena evaluación debería cruzar al menos cuatro variables: criticidad + exposición + vulnerabilidad + posibilidad de actualización. Con esa información se puede construir un roadmap de renovación mucho más racional.
¿Qué hacer cuando no es posible reemplazarlo todavía?
Este escenario es bastante común: sistemas industriales, equipos médicos, aplicaciones propietarias o plataformas desarrolladas internamente que no pueden migrarse rápidamente. En esos casos existen controles compensatorios.
La segmentación de red es uno de los más importantes. También pueden aplicarse restricciones de acceso, reglas específicas de firewall, monitoreo de tráfico, autenticación robusta y eliminación de servicios que no sean necesarios.
Por ejemplo, un equipo legacy que no necesita comunicarse con toda la red corporativa no debería tener acceso indiscriminado a ella. La idea es sencilla: si no podemos modernizar inmediatamente el activo, debemos reducir al máximo lo que un atacante podría hacer si consigue comprometerlo.
Eso sí, los controles compensatorios no deberían convertirse en una excusa para mantener indefinidamente una tecnología obsoleta.
La pregunta correcta no es “¿todavía funciona?”
Cuando se revisa una infraestructura antigua, esta probablemente sea la pregunta menos útil. Un equipo puede funcionar durante diez años más. La pregunta realmente importante es otra: ¿Podemos seguir confiando en este equipo dentro de nuestra arquitectura de seguridad actual?
Para responderla, una empresa debería conocer como mínimo qué equipos tiene, qué versiones utilizan, qué componentes están fuera de soporte, cuáles tienen vulnerabilidades conocidas y qué sistemas dependen de ellos. A partir de ahí es posible construir un inventario tecnológico y establecer prioridades. No todo debe reemplazarse mañana. Pero todo activo crítico debería tener un horizonte.
Modernizar antes de que la emergencia obligue a hacerlo
Una de las peores estrategias de infraestructura es esperar a que un equipo falle para empezar a pensar en su reemplazo. Cuando un servidor crítico falla de manera inesperada, la empresa no solamente tiene que comprar hardware o contratar un servicio nuevo.
También debe recuperar información, reconstruir configuraciones, migrar aplicaciones, validar integraciones y, sobre todo, mantener funcionando el negocio mientras todo esto ocurre. Por eso la modernización de infraestructura debería formar parte de una estrategia de continuidad y ciberseguridad, no únicamente de un presupuesto de renovación tecnológica.
La tecnología legacy no es mala por el simple hecho de ser antigua. El problema aparece cuando una empresa deja de gestionar conscientemente el riesgo que representa. Porque mientras un equipo viejo puede seguir funcionando durante años, una vulnerabilidad sin corregir solo necesita una oportunidad para dejar de ser un problema técnico y convertirse en un problema para todo el negocio.