Del análisis estático a la resiliencia operativa continua Artículo de posición y análisis técnico sobre la aplicabilidad de Claude Mythos en entornos IBM z/OS Idea central. Claude Mythos sí tiene aplicación en z/OS, pero no principalmente en el núcleo propietario de IBM. Su mayor valor se manifiesta en las capas procedimental y operativa del mainframe moderno: REXX, CLIST, JCL, USS, Python para z/OS, automatizaciones y código aplicativo accesible. La reciente presentación de Claude Mythos Preview por parte de Anthropic ha marcado un punto de inflexión estratégico. Al ofrecer capacidades avanzadas para detectar vulnerabilidades en aplicaciones de forma autónoma dentro de un marco de uso defensivo restringido, este modelo ha puesto de relieve una realidad incómoda para la industria: el salto hacia la IA defensiva y ofensiva no está a la espera de que las infraestructuras tradicionales se adapten. En el caso de z/OS, la pregunta no es si la tecnología será aplicable algún día, sino dónde puede aportar valor real hoy y qué cambios exige en la forma de auditar, asegurar y demostrar el cumplimiento. La respuesta obliga a mirar más allá del sistema operativo base y a centrarse en la superficie de ataque que realmente cambia cada semana en un entorno mainframe moderno.

1. Dónde encaja realmente Claude Mythos en un entorno z/OS

Durante años, securizar un mainframe se ha asociado, sobre todo, a la configuración de RACF, la protección de datasets, la segregación de privilegios, el control de librerías críticas y la administración segura de subsistemas como CICS, DB2, JES o USS. Todo eso sigue siendo imprescindible, pero ya no describe por sí solo el perímetro real de riesgo. El z/OS actual es un ecosistema híbrido. Junto al sistema base convive una periferia procedural cada vez más amplia: scripts REXX y CLIST, JCL y PROCs, automatizaciones batch, herramientas en USS, Python para z/OS, extractores, parsers, integraciones ETL y software aplicativo propio. Es precisamente ahí donde una capacidad como la de Claude Mythos puede resultar más útil. No debe entenderse como un simple lector de código. Su utilidad potencial radica en analizar artefactos técnicos, relacionarlos con un objetivo de seguridad y razonar sobre secuencias de fallos o abusos que un revisor humano podría tardar mucho más en reconstruir. En z/OS, esto lo sitúa como una tecnología complementaria al control continuo de configuración y no como un sustituto de la auditoría técnica tradicional.

Matriz técnica de aplicabilidad

Área en z/OS Riesgo operacional Aplicabilidad de IA Hallazgos típicos
Módulos internos de z/OS sin fuente Bajo para revisión directa Baja Valor indirecto: razonamiento sobre el comportamiento, las llamadas y las superficies de ataque.
REXX y CLIST Medio/alto Alta Bypass de controles, abuso de privilegios, comandos dinámicos inseguros, lógica operativa defectuosa.
JCL, PROCs y batch Alto Alta Escalada operativa, datasets temporales inseguros, delegación excesiva, flujos batch peligrosos.
USS y Python para z/OS Muy alto Muy alta Fallos en los parsers, exposición de secretos, wrappers débiles, APIs inseguras, automatizaciones frágiles.
Código aplicativo accesible Alto Media/alta SQL dinámico, validación insuficiente, defectos lógicos, exposición indebida de datos.
La lectura de esta matriz es clara: cuanto menor es la visibilidad sobre el artefacto técnico, menor es el rendimiento esperado de un sistema de análisis asistido por IA. Por el contrario, cuanto más procedural, integrable y verificable es la pieza analizada, mayor es el valor potencial.

2. La nueva superficie de ataque del mainframe moderno

El riesgo ya no reside únicamente en una mala definición de RACF o en una librería crítica mal protegida. Muchas debilidades relevantes surgen hoy de la forma en que el entorno se automatiza, se integra y se opera. Un script que construye comandos dinámicamente, una cadena batch que delega demasiado, un parser USS mal validado o una utilidad interna con secretos embebidos pueden abrir caminos laterales que no aparecen en una revisión puramente configuracional. Esto explica por qué las herramientas capaces de analizar código y comportamiento técnico a escala pueden representar un cambio de paradigma en z/OS. No porque vayan a “romper” el sistema base por arte de magia, sino porque permiten revisar con mucha mayor profundidad la periferia donde hoy se generan muchas exposiciones reales.

3. La obsolescencia del compliance estático

El modelo tradicional de auditoría profunda, cada dos o tres años, basado en un muestreo manual de una fracción limitada del entorno, es cada vez menos compatible con la velocidad del cambio técnico y con las expectativas regulatorias actuales. Bajo marcos como DORA o NIS2, el cumplimiento deja de ser una fotografía ocasional y pasa a ser una capacidad de demostración continua. Una revisión bianual o anual presenta al menos tres problemas estructurales:
  • Visibilidad parcial. No garantiza la revisión del 100 % de los artefactos y configuraciones relevantes.
  • Ventana de exposición. Un riesgo detectado tarde puede permanecer operativo durante meses antes de una nueva evaluación formal.
  • Inviabilidad operativa. La escasez de especialistas en z/OS hace muy difícil sostener a escala un modelo intensivo en revisión manual.
En este contexto, la IA no crea por sí sola la necesidad de cambiar el modelo de auditoría, pero sí acelera la evidencia de que el enfoque estático ya no es suficiente. Si una tecnología puede analizar a gran velocidad la capa procedural del entorno, el defensor no puede seguir operando con ventanas tan largas entre una revisión y la siguiente.

4. Hacia una Continuous Mainframe Cybersecurity Assurance

La respuesta estratégica no es “hacer más auditoría manual”, sino evolucionar hacia un modelo de Continuous Mainframe Cybersecurity Assurance. Este enfoque combina el control técnico continuo, la generación recurrente de evidencia y la priorización operativa del riesgo. En la práctica, esto implica tres cambios de fondo:
  • Monitorización del 100 % del entorno analizable. Abandonar el muestreo estadístico siempre que sea posible y revisar de forma periódica la totalidad de la configuración y de los artefactos relevantes.
  • Automatización de la evidencia técnica. Generar dashboards y métricas de riesgo operacional de forma semanal para que CISO, auditoría interna y responsables de cumplimiento puedan demostrar diligencia debida.
  • Análisis continuo de la capa procedural. Tratar REXX, JCL, USS, Python y automatizaciones como parte del perímetro de seguridad, no como simples piezas auxiliares de operación.
En un modelo así, Claude Mythos se encaja como una segunda capa analítica. La evaluación continua sigue siendo la base para medir el estado de control del entorno y demostrar el cumplimiento. Sobre esa base, una capacidad como Mythos puede concentrarse en los artefactos en los que la lógica, la automatización o la integración introducen riesgos menos visibles.

5. Modelo de uso recomendado para Mythos en z/OS

La implantación razonable de una capacidad de este tipo no consiste por darle acceso libre a la producción. El modelo operativo prudente debería estructurarse en fases:
  • Fase 1. Revisión offline de artefactos. Exportación de librerías, repositorios, REXX, JCL, scripts USS, Python y documentación asociada a un entorno aislado y de solo lectura.
  • Fase 2. Casos de uso concretos. Búsqueda de bypasses de autorizaciones, secretos embebidos, datasets inseguros, procedimientos batch peligrosos, SQL dinámico y automatizaciones con privilegios excesivos.
  • Fase 3. Extensión al código aplicativo. Ampliación a COBOL, PL/I, CICS o DB2 cuando existan fuente suficiente, criterios internos de validación y capacidad real de verificación del hallazgo.
Principio de seguridad. Claude Mythos debería incorporarse como capacidad analítica dentro de un proceso controlado, con permisos limitados, datos preparados y validación humana obligatoria, y no como actor autónomo de los sistemas productivos.

6. Hacia un Continuo Mainframe Cybersecurity Assurance

La lección que nos deja el avance de estas IA es que el atacante ya cuenta con capacidades de detección profunda. Si la estrategia de seguridad sigue dependiendo de una auditoría anual o bianual, la organización opera bajo una asimetría de información que ni las amenazas modernas ni los reguladores tolerarán. El entorno regulatorio actual, marcado por NIS2 y el Reglamento DORA, exige una diligencia debida que trasciende los estándares tradicionales. Para asegurar el cumplimiento de las normativas GDPR (RGPD), ISO 27001, SOX y Basilea II/III, es imperativo migrar de la auditoría estática a la monitorización continua. La implementación de un sistema de mejora continua —como es DataPASS— se convierte en la única piedra angular capaz de proporcionar la garantía necesaria ante estos retos:
  • Diligencia en la respuesta: Ante una auditoría bajo NIS2 o DORA, la capacidad de demostrar que se han medido el 100% de los datos catalogados de forma sistemática es la mejor defensa frente a cualquier incidente.
  • Eficiencia operativa: DataPASS permite realizar auditorías completas con una frecuencia (semanal o diaria) que sería inalcanzable de forma humana, asegurando que los controles de seguridad no queden obsoletos ante la evolución constante de los scripts procedurales del mainframe.
  • Visibilidad para el CISO: Centralizar el cálculo de riesgos operacionales y el reporte de cumplimiento normativo facilita una gobernanza efectiva, como la que los marcos, como SOX o Basilea III, exigen actualmente a las entidades financieras.

7. Conclusión

Conclusión estratégica. La lección que deja el avance de las IA es que el atacante ya puede realizar evaluaciones de seguridad con una profundidad y una velocidad sin precedentes. Si la estrategia de ciberseguridad mainframe sigue dependiendo de una auditoría anual o bianual, la organización opera bajo una asimetría de información que ni las amenazas modernas ni los reguladores tolerarán durante mucho tiempo. La transición hacia una Continuous Mainframe Cybersecurity Assurance no es solo una optimización de costes o de cumplimiento. Es la forma más sólida de asegurar que el mainframe siga siendo el entorno más robusto y seguro de la infraestructura tecnológica corporativa, incluso en una era marcada por la IA, tanto ofensiva como defensiva.