Ciberseguridad en IBM i: la paradoja de confiar en lo que nunca falla

IBM i no es un sistema que simplemente ejecuta aplicaciones. Es una infraestructura de poder organizacional. En la mayoría de las organizaciones donde sigue operando, IBM i no cumple un rol accesorio ni secundario, sino uno fundacional: es el lugar donde se materializa la verdad operativa del negocio. Allí se consolidan cifras, se validan transacciones críticas, se ejecutan procesos que definen ingresos, costos, obligaciones regulatorias y compromisos contractuales. Cuando existe una discrepancia entre lo que muestran los sistemas modernos y lo que refleja IBM i, la organización rara vez duda de este último. IBM i no debate: arbitra.

Ese poder no es casual ni cultural; es arquitectónico. IBM i fue diseñado para privilegiar consistencia, determinismo y control explícito. Cada objeto tiene un dueño, cada acceso una autoridad, cada proceso un marco definido. Esta rigidez, que en otros sistemas se percibe como limitante, en IBM i se transformó en virtud. Permitió sostener durante décadas operaciones críticas sin degradación funcional, incluso mientras el resto del ecosistema tecnológico se fragmentaba, se aceleraba y se volvía más frágil.

El problema aparece cuando ese poder no se gobierna explícitamente. En muchas organizaciones, IBM i queda fuera de las discusiones estratégicas de riesgo porque “siempre ha estado ahí” y “nunca ha fallado”. Se lo protege contra caídas, pero no se lo interroga como concentrador de autoridad. Se lo mantiene estable, pero no se revisa el impacto sistémico de lo que produce. Esta omisión no es menor. En un entorno donde los ataques ya no buscan derribar sistemas, sino influir decisiones, cualquier plataforma que consolide verdad se vuelve estratégicamente sensible.

IBM i, en ese sentido, no es solo un sistema heredado que sobrevive por inercia. Es una pieza central en la arquitectura de confianza de la organización. Y toda arquitectura de confianza que no se revisa termina siendo explotable, no por debilidad técnica, sino por exceso de deferencia.

El modelo de seguridad de IBM i y la deuda temporal acumulada

El modelo de seguridad de IBM i fue, durante mucho tiempo, una referencia implícita de buenas prácticas. Mucho antes de que la industria hablara de control de acceso basado en objetos, separación de privilegios o ejecución controlada, IBM i ya lo había incorporado como parte esencial de su diseño. Esto redujo de forma drástica errores operativos, escaladas accidentales y comportamientos impredecibles.

Sin embargo, ese modelo fue concebido bajo supuestos muy específicos. Supuestos de estabilidad organizacional, de identidades persistentes, de flujos de acceso relativamente estáticos y de un perímetro lógico claramente definido. El sistema fue diseñado para un mundo donde el cambio era lento y las integraciones eran excepcionales. Ese mundo ya no existe.

Lo que hoy se observa en muchos entornos IBM i no es una falla del modelo, sino una deuda temporal acumulada. Decisiones de seguridad que fueron razonables en su momento se mantienen vigentes en un contexto completamente distinto. Autoridades amplias otorgadas para resolver bloqueos operativos urgentes. Excepciones creadas para integraciones puntuales que se transformaron en accesos permanentes. Configuraciones heredadas que nadie se atreve a revisar porque el costo de equivocarse parece inaceptable.

IBM i no cuestiona estas decisiones. No tiene por qué hacerlo. Ejecuta con precisión el marco que se le definió. Pero desde una perspectiva contemporánea, ese marco suele estar profundamente desalineado con los principios actuales de gestión de riesgo. El menor privilegio, la temporalidad del acceso y la separación funcional de identidades no forman parte del ADN histórico de muchos entornos IBM i.

Esta deuda no se manifiesta como una vulnerabilidad explotable clásica. No hay un parche que aplicar ni una configuración obvia que corregir. Es una deuda de contexto. Y como toda deuda de contexto, se vuelve peligrosa cuando el entorno cambia más rápido que la voluntad de revisarla.

Identidades, autoridades y accesos que sobreviven a la organización

En IBM i, las identidades no son transitorias. Son entidades persistentes, con historia, permisos acumulados y dependencias profundas. En muchos entornos, los perfiles de usuario sobreviven a las personas que los crearon, a los proyectos que los justificaron y a las estructuras organizacionales que les dieron sentido. Cambia la empresa, pero los perfiles permanecen.

Esta persistencia se vuelve crítica cuando se combina con autoridades amplias. Conceptos como ALLOBJ (autoridad total sobre los objetos del sistema) no son anomalías técnicas; son mecanismos legítimos del modelo de seguridad. El problema surge cuando estas autoridades se asignan de forma defensiva y acumulativa, como solución rápida a fricciones operativas, y luego nunca se revisan.

Desde una perspectiva ofensiva, este escenario es ideal. El atacante no necesita explotar una vulnerabilidad ni escalar privilegios. Solo necesita acceder a una identidad que ya tiene más permisos de los necesarios. Y ese acceso, cuando ocurre, no se presenta como un evento anómalo. Es una autenticación válida seguida de acciones permitidas.

A diferencia de otros entornos, donde el abuso suele implicar una ruptura visible de controles, en IBM i el abuso se confunde con normalidad. El sistema no distingue intención. Ejecuta. Mientras las identidades no se gobiernen como activos de riesgo en sí mismos, IBM i seguirá siendo un lugar donde el pasado define silenciosamente el presente.

Escenarios de compromiso reales sin exploits

La mayoría de los compromisos relevantes que involucran IBM i no comienzan en la plataforma. El acceso inicial suele producirse en sistemas periféricos: un endpoint administrativo, un servidor de aplicaciones, una integración mal aislada. Desde allí, el atacante explora el entorno y detecta dónde reside el valor real.

IBM i aparece entonces como objetivo natural. El acceso no requiere técnicas exóticas. Conectores ODBC o JDBC, cuentas de servicio utilizadas por procesos batch, identidades técnicas diseñadas para automatización. Todo perfectamente legítimo. Todo documentado, al menos en algún momento.

Este tipo de compromiso es particularmente difícil de detectar porque no genera ruido técnico. No hay malware residente ni fallas visibles. Hay sesiones válidas, consultas permitidas y procesos que se ejecutan según lo esperado. La diferencia está en el propósito, no en el mecanismo.

El impacto no se manifiesta como una caída del sistema, sino como una desviación gradual. Cambios en datos críticos, ajustes en lógica de negocio, alteraciones que se integran al flujo normal de operación. Cuando finalmente se detectan, el daño ya está incorporado en la historia del sistema.

IBM i como vector de persistencia y manipulación de negocio

La estabilidad de IBM i, que durante años fue su mayor fortaleza, lo convierte también en un vector ideal de persistencia. Una modificación introducida hoy puede seguir ejecutándose durante años sin levantar sospechas. No porque sea invisible, sino porque es coherente con el funcionamiento normal del sistema.

Desde una perspectiva ofensiva avanzada, no es necesario mantener acceso continuo ni implantar mecanismos ruidosos. Basta con introducir una alteración lógica que el sistema ejecute fielmente. Una validación desplazada. Un cálculo ajustado. Un control omitido. Todo dentro de los márgenes de lo permitido.

Este tipo de manipulación no rompe procesos ni degrada rendimiento. Produce resultados consistentes, pero incorrectos. Y como IBM i suele ser la fuente de verdad, esos resultados se propagan al resto de la organización como hechos legítimos.

Aquí el riesgo deja de ser técnico y se vuelve estratégico. IBM i no amplifica ataques visibles, amplifica errores de significado. Y esos errores, cuando se acumulan, erosionan decisiones, confianza y gobernanza.

IBM i y el futuro de la confianza en sistemas que no fallan

La paradoja final de IBM i es que su mayor virtud técnica —la estabilidad inquebrantable— se ha convertido en su mayor punto ciego de gestión. Durante décadas, la industria de TI aprendió a gestionar por excepción: si algo no se rompe, si no genera alertas rojas, si no detiene la operación, se asume que está sano. IBM i casi nunca se rompe. Y en ese silencio operativo, la organización encuentra una falsa sensación de paz.

El problema es que la seguridad moderna ya no trata sobre la disponibilidad del servicio, sino sobre la integridad de la intención. Un IBM i comprometido no deja de procesar; simplemente procesa una realidad alterada con la misma eficiencia y determinismo de siempre. La plataforma sigue garantizando que las transacciones se completen, que los registros se guarden y que los balances cierren, sin importar si los parámetros de esas acciones fueron sutilmente desviados por una credencial legítima usada con fines ilegítimos.

Recuperar el control implica un cambio cultural difícil: dejar de medir la salud de IBM i únicamente por su uptime y empezar a medirla por la trazabilidad de sus acciones. Significa introducir fricción deliberada —auditoría, revisión, validación— en procesos que siempre fluyeron libres. Significa auditar la normalidad, cuestionar los privilegios que “siempre estuvieron ahí” y aceptar que un sistema puede estar funcionando perfectamente a nivel técnico y, simultáneamente, estar siendo explotado a nivel lógico.

Tenemos que aprender a desconfiar de la estabilidad. Tenemos que vigilar aquello que funciona bien, precisamente porque su eficiencia lo hace invisible al radar de riesgos cotidiano. Hay que romper la inercia de dar por sentado que la robustez técnica equivale a invulnerabilidad estratégica, y empezar a cuestionar al sistema no porque falle, sino porque obedece demasiado bien.

Y ese, quizás, sea el desafío más incómodo para una plataforma que siempre cumplió su promesa.