Seamos sinceros: REXX es una maravilla. Es la navaja suiza de cualquier sistemista en entornos mainframe: un lenguaje potente, versátil y nativo que nos ha salvado la vida en innumerables ocasiones, automatizando tareas tediosas. Pero como suele pasar con las herramientas poderosas, tiene un lado oscuro que a menudo preferimos ignorar. Imagina, por un momento, un hospital. Los médicos necesitan acceso a las radiografías para diagnosticar, ¿verdad? Ahora imagina que dejamos las salas de rayos X abiertas y los historiales médicos accesibles para que cualquier celador, administrativo o visitante curioso pueda echarles un vistazo. Sería una locura, ¿no? Pues eso es exactamente lo que ocurre en muchos LPAR de z/OS hoy en día con REXX.

El problema: GitHub y la CBT Tape son un arma de doble filo

Si eres CISO o responsable de seguridad, esto te interesa. No hace falta ser un genio del mal para encontrar herramientas peligrosas. Si te das una vuelta rápida por GitHub y buscas "mainframe REXX", encontrarás un arsenal de scripts listos para usar. Y no estamos hablando solo de utilidades inofensivas; hablamos de código diseñado para realizar footprinting (reconocimiento) detallado. Estos scripts permiten a los "malos" —o a un empleado descontento, o a un usuario básico con credenciales comprometidas— mapear tu sistema, localizar vulnerabilidades de configuración, listar librerías de APF o ver catálogos que no deberían ver. Y no es algo nuevo: los directorios de la vieja y conocida CBT Tape llevan más de veinte años alojando scripts similares. La diferencia es que ahora están a un clic de distancia para cualquiera.

La vulnerabilidad de "libre disposición"

El riesgo real radica en los permisos por defecto. A menudo, en la configuración de un LPAR, asumimos que si un usuario no tiene acceso de escritura, no representa un riesgo. Error. Si cualquier programador básico puede ejecutar un REXX que escanea la estructura de tus datos, es como si le hubieras dado los planos del banco al ladrón antes del robo. Con esa información, pueden preparar la instalación de piezas de código para robar información, denegar servicios o, lo que es peor, instalar puertas traseras (backdoors) que pasen desapercibidas durante meses.

El impacto normativo: DORA, NIS2 y GDPR

Aquí es donde la tecnología choca con la legalidad. Ya no es solo una cuestión de buenas prácticas; es una exigencia legal.
  • GDPR (Reglamento General de Protección de Datos): Si un script REXX permite acceder a datos personales o comprometer su integridad, estás incumpliendo el principio de seguridad del tratamiento.
  • NIS2: Esta directiva europea endurece los requisitos de ciberseguridad. Permitir herramientas de reconocimiento interno sin control es una invitación a incidentes que deberás notificar.
  • Reglamento DORA: Enfocado en la resiliencia operativa digital del sector financiero, exige que gestionemos los riesgos de las TIC. Dejar REXX abierto a todos los usuarios es una brecha en esa resiliencia.

La solución no es prohibir, es auditar con profundidad (DATAPASS)

No podemos eliminar por completo la capacidad de ejecutar programas y scripts en REXX, pero sí podemos auditar quiénes realmente lo necesitan y "securizar" su uso. Las auditorías anuales tradicionales son una foto fija que caduca al día siguiente. Los malos no descansan hasta la próxima auditoría. Necesitamos aumentar la frecuencia y, sobre todo, la profundidad del análisis. Aquí es donde entra en juego la necesidad de servicios de auditoría cíclica como DATAPASS. No se trata de un simple chequeo, sino de un sistema de mejora continua de la seguridad del mainframe. DATAPASS permite identificar quién está ejecutando qué, detectar configuraciones débiles que permiten este footprinting y cerrar esas brechas antes de que un script descargado de internet ponga en jaque a tu organización. Un SIEM o un SOC moderno debe ser capaz de ingerir y correlacionar estas ejecuciones, pero la prevención mediante una auditoría profunda y recurrente es la única forma de evitar que tus propias herramientas se usen en tu contra. El mainframe sigue siendo el servidor más seguro del mundo, pero solo si lo configuramos para que lo sea. Dejar REXX en "libre disposición" es un lujo que, en la era del ransomware y el ciberespionaje, ya no nos podemos permitir. Es hora de cerrar la sala de rayos X y dar las llaves solo a quien realmente las necesita.