Controles compensatorios, evaluación periódica y responsabilidades definidas permiten mantener aplicaciones críticas mientras se prepara su modernización.
Ejes de análisis
- Funcionar no significa estar protegida
- Contener el riesgo mientras continúa operando
- La permanencia necesita responsables y límites
Una aplicación puede procesar transacciones, responder a sus usuarios y sostener procesos importantes sin presentar fallas visibles. Esa continuidad genera confianza, pero su funcionamiento operativo no garantiza que siga siendo segura o sostenible.
Detrás de una aplicación estable pueden existir sistemas operativos sin soporte, componentes que ya no reciben actualizaciones, vulnerabilidades que no pueden corregirse o mecanismos débiles de autenticación.
La antigüedad, por sí misma, no determina el riesgo. Una aplicación antigua que permanece aislada y procesa información de baja sensibilidad puede requerir menos atención que otra conectada con servicios críticos. La evaluación debe considerar qué información administra, qué procesos soporta, quiénes acceden y qué consecuencias tendría un incidente.
Identificar el riesgo no conduce necesariamente al reemplazo inmediato. Las restricciones presupuestarias, las dependencias técnicas o la falta de una alternativa pueden prolongar la permanencia de la aplicación. La organización deberá entonces definir cómo protegerla, qué riesgos está dispuesta a aceptar y quién responderá por ellos.
Funcionar no significa estar protegida
El fin del soporte tecnológico es una de las primeras señales de alerta. Cuando un fabricante deja de proporcionar actualizaciones, la organización pierde capacidad para responder ante nuevas vulnerabilidades. La misma condición puede afectar a sistemas operativos, bases de datos y otros componentes de la aplicación.
También deben revisarse las dificultades para aplicar parches y las limitaciones para incorporar autenticación, cifrado, monitoreo o registros de auditoría. Las cuentas compartidas, los privilegios excesivos, los protocolos inseguros y la falta de documentación pueden permanecer ocultos mientras el sistema continúa funcionando.
Las fallas recurrentes, los comportamientos anómalos y los ajustes manuales necesarios para sostener la operación también muestran su deterioro. Cuando pocas personas conocen su arquitectura y configuración, su salida puede afectar el mantenimiento y la recuperación.
Estas señales deben relacionarse con la importancia de la aplicación para el negocio. Un análisis de impacto permite identificar los procesos soportados, sus dependencias y las consecuencias de una interrupción. A partir de esta evaluación se establecen el tiempo máximo para recuperar el servicio (RTO) y la pérdida máxima de información aceptable (RPO).
El análisis no debe limitarse a la indisponibilidad. Una aplicación puede continuar procesando operaciones mientras una persona no autorizada accede a sus datos o modifica información. El servicio aparenta normalidad, pero su integridad está comprometida. La evaluación debe incluir interrupciones, alteración de información, accesos indebidos, fraude, ransomware y afectaciones originadas en terceros.
Contener el riesgo mientras continúa operando
Cuando una aplicación no puede actualizarse o reemplazarse, la organización necesita aplicar controles compensatorios. Estas medidas reducen la posibilidad de que una debilidad sea aprovechada y limitan el impacto de un incidente, aunque no eliminan la vulnerabilidad existente.
La segmentación de red permite restringir las comunicaciones a los usuarios y servicios que realmente necesitan acceder. Una aplicación que no requiere exposición a Internet debería mantenerse fuera de ese alcance. Si debe intercambiar información con otros sistemas, los flujos necesitan reglas específicas.
La protección de los accesos comprende eliminar cuentas innecesarias, revisar privilegios, controlar usuarios administrativos e incorporar autenticación multifactor cuando la tecnología lo permita. La trazabilidad ayuda a conocer quién ingresó, qué acciones realizó y si se presentaron comportamientos anómalos.
En aplicaciones web puede incorporarse un firewall de aplicaciones o WAF para bloquear determinados patrones de ataque. Los sistemas de prevención de intrusiones, las herramientas EDR y las plataformas SIEM aportan capacidades de detección y respuesta. Sin embargo, estas herramientas no corrigen una falla existente en el código.
La organización también debe revisar el cifrado, proteger las bases de datos, verificar los respaldos y detectar modificaciones o accesos no autorizados. Los respaldos necesitan pruebas periódicas que confirmen que la información puede recuperarse dentro de los tiempos requeridos.
Las vulnerabilidades que no puedan corregirse deberían ingresar a un proceso formal de gestión de excepciones. Este debe documentar la condición encontrada, el motivo que impide solucionarla, los controles incorporados, el riesgo que permanece, los responsables y la fecha de revisión.
Una excepción no puede convertirse en una autorización indefinida. Las amenazas, la exposición y la criticidad cambian. La decisión debe revisarse cuando se modifiquen las conexiones, los usuarios, los datos o las condiciones de soporte.
Los cambios sobre una aplicación crítica también requieren precauciones. Antes de llevar una actualización a producción deben evaluarse la seguridad, la interoperabilidad, la integridad de los datos y el comportamiento ante fallas. Los respaldos verificados y los procedimientos de reversión permiten regresar a un estado estable si la implementación afecta la operación.
La permanencia necesita responsables y límites
La gestión de una aplicación heredada no corresponde exclusivamente a Tecnología. Requiere la participación de Seguridad de la Información, Continuidad, Gestión de Riesgos y el propietario del proceso.
Tecnología conoce la arquitectura, identifica dependencias y analiza las alternativas de modernización. Seguridad evalúa las amenazas, vulnerabilidades y condiciones de exposición. Continuidad revisa los escenarios de interrupción y las capacidades de recuperación. El propietario del proceso conoce las operaciones que dependen de la aplicación y las consecuencias de una interrupción o un cambio.
Esta coordinación debe traducirse en criterios comunes para evaluar aplicaciones, priorizar intervenciones, aprobar cambios y gestionar excepciones. Cuando el riesgo residual supera los niveles aceptables, la decisión de mantener el sistema debe elevarse a la instancia con autoridad para asumirlo.
El CIO debe considerar la viabilidad tecnológica, la sostenibilidad del soporte, el costo de mantenimiento y las alternativas de modernización. El CISO determina la exposición, las posibilidades de mitigación y el riesgo que permanece después de aplicar los controles. El negocio establece cuánto depende de la aplicación y qué impacto podría asumir.
Las vulnerabilidades críticas que no pueden mitigarse, los componentes sin soporte, la falta de personal capacitado y los controles insuficientes deberían acelerar el reemplazo. En otros casos, la permanencia temporal puede justificarse si la exposición es conocida, existen medidas de protección y la decisión se revisa periódicamente.
El peligro es que una solución temporal se convierta en una dependencia permanente. Mientras la aplicación continúe operando, la organización debe poder explicar bajo qué condiciones la conserva, qué controles la protegen, qué riesgos permanecen y quién los ha aceptado.
La pregunta no es cuánto tiempo más puede funcionar una aplicación antigua, sino durante cuánto tiempo la organización puede seguir confiando en ella sin comprometer sus datos, sus procesos y la continuidad del negocio.
