⚠️ Alerta de Seguridad: el riesgo silencioso del código Assembler en entornos IBM z/OS

Un riesgo operacional real, actual y poco visible

En la mayoría de las grandes entidades financieras europeas, el mainframe IBM z/OS sigue siendo el corazón del negocio: pagos, liquidación, core bancario, custodia, clearing y reporting regulatorio dependen de él. Sin embargo, existe un riesgo crítico, poco tratado y raramente monitorizado: la ejecución de programas Assembler aparentemente legítimos, capaces de provocar impacto operacional severo inmediato, sin necesidad de explotar vulnerabilidades conocidas ni fallos de configuración. Este riesgo no es teórico. Es real, ejecutable y alineado con escenarios de insider threat y supply-chain, exactamente los que DORA y NIS2 exigen gestionar. Tras analizar la existencia de código Assembler malicioso, documentado en foros técnicos no oficiales y repositorios clandestinos, decidimos reproducir el escenario en un entorno de laboratorio totalmente controlado. El programa dejaba el LPAR en un software wait, del que la única forma de recuperación era realizar un IPL del LPAR. Los entornos mainframe z/OS están diseñados para soportar prácticamente cualquier fallo de hardware:
  • La caída de un LPAR no interrumpe el servicio: otros miembros del Sysplex continúan operando.
  • Incluso la pérdida de un Sysplex completo puede activar planes de contingencia y centros alternativos previamente definidos.
Sin embargo, estos entornos no están diseñados para protegerse de fallos de software malicioso o negligente que se ejecutan con privilegios suficientes. En un escenario de congelación múltiple, podría congelar:
  • TODOS los LPAR de producción en el centro principal
  • TODOS los LPAR de producción en el centro alternativo
  • TODOS los LPAR de desarrollo/preproducción/QA/Formación en el centro principal
  • TODOS los LPAR de desarrollo/preproducción/QA/Formación en el centro alternativo (si es que existe para estos servicios)
Un programa de estas características puede permanecer latente, esperando una fecha y hora determinadas, para ejecutarse de forma simultánea.

El problema: código pequeño, impacto sistémico

Assembler z/OS es:
  • Extremadamente potente
  • Ejecutado muy cerca del sistema operativo
  • Capaz de realizar acciones irreversibles si se programa mal o con intención maliciosa
Hoy en día:
  • Quedan muy pocos expertos en Assembler
  • Existen miles de programas legacy en producción
  • La revisión manual es prácticamente inexistente
  • La confianza se basa en la antigüedad del código, no en su análisis
Un programa de pocas líneas, correctamente estructurado y con apariencia legítima, puede:
  • Detener una partición lógica (LPAR)
  • Congelar procesos críticos
  • Obligar a un IPL de producción
  • Provocar indisponibilidad inmediata del negocio
  • Generar una crisis operativa sin “ciberataque” visible
Desde el punto de vista regulatorio, esto no es un incidente técnico: es un fallo de resiliencia operacional.

Por qué este escenario preocupa a DORA y NIS2

Ni DORA ni NIS2 se centran únicamente en malware externo. Ambas normativas ponen el foco en:
  • Riesgo interno
  • Código privilegiado
  • Falta de controles preventivos
  • Capacidad de detección temprana
  • Impacto sistémico de un único evento
Un programa Assembler malicioso o negligente encaja perfectamente en:
  • ICT Risk (DORA)
  • Operational disruption
  • Insider threat
  • Inexistencia de controles continuos
  • Imposibilidad de demostrar diligencia ante el regulador
En la práctica, muchas entidades no pueden demostrar:
  • Qué programas críticos existen realmente
  • Quién los ejecuta
  • Qué impacto tendrían si se comportan de forma anómala
  • Cómo se detectaría su ejecución en tiempo real
Desde la óptica regulatoria, la inexistencia de controles preventivos y de detección continua en este escenario no es una debilidad técnica, sino una deficiencia grave de gobierno del riesgo ICT, lo que conecta directamente con:
  • Art. 5–6 DORA (ICT risk governance)
  • Art. 21 NIS2 (gestión de riesgos)

El mayor riesgo: la falsa sensación de seguridad

El problema no es que estos programas existan. El problema es que se confía en que “nunca pasará nada” porque:
  • “Lleva 20 años en producción”
  • “Siempre ha funcionado”
  • “Nadie sabe ya tocarlo”
  • “Es código histórico”
Desde un punto de vista de riesgo, esto es exactamente lo contrario de un control. En muchos casos:
  • Una sola persona tiene el conocimiento
  • No hay sustitución
  • No hay análisis de impacto
  • No hay monitorización continua
Esto constituye un single point of failure humano y técnico.

Qué deberían preguntarse hoy los CISOs y CIOs

Si su entidad opera IBM z/OS, estas preguntas son inmediatas:
  • ¿Sabemos qué programas Assembler se ejecutan en producción?
  • ¿Tenemos visibilidad real de su comportamiento?
  • ¿Podríamos detectar la ejecución de uno anómalo en minutos?
  • ¿Podemos demostrar control continuo ante el regulador?
  • ¿Qué ocurriría si uno de ellos provocara una indisponibilidad total?
Si alguna de estas preguntas no tiene respuesta clara, el riesgo ya existe.

Conclusión: no es hacking, es resiliencia

Este no es un artículo sobre hacking. No es un exploit. No es una vulnerabilidad CVE. Es un riesgo operacional estructural en el corazón del sistema financiero europeo. DORA y NIS2 no preguntarán cómo ocurrió el incidente, sino: “¿Qué controles tenía para evitarlo o detectarlo?” Y en muchos entornos mainframe, hoy, la respuesta es: insuficientes.

📌 Nota final

Desde Bsecure ayudamos a las entidades financieras europeas a identificar, monitorizar y demostrar control efectivo sobre este tipo de riesgos en entornos IBM z/OS, con un enfoque continuo, auditable y alineado con DORA y NIS2. Si desea validar su exposición real a este riesgo, puede contactarnos de forma confidencial.