Sin SMF no hay SOC en el mainframe. Así de simple y así de grave. Cuando un equipo de seguridad decide extender la cobertura de su SOC al mainframe IBM Z, la primera pregunta no es qué herramienta instalar, sino de dónde proviene la telemetría. En entornos Windows o Linux, la respuesta es sencilla: logs de eventos, syslog, auditd y agentes EDR. En ciberseguridad mainframe, la respuesta tiene nombre propio: System Management Facility, conocida universalmente como SMF. Los registros SMF son el mecanismo nativo de z/OS para registrar la actividad del sistema, y llevan haciéndolo desde los años setenta, mucho antes de que existiera el concepto de SIEM. Todo lo que ocurre en un mainframe —quién inicia sesión, qué datasets abre, qué trabajos lanza, qué perfiles de seguridad modifica, qué conexiones TCP establece— queda reflejado en los registros SMF. Si no está en SMF, a efectos de auditoría no ocurrió. Este artículo explica qué son, cuáles son críticos para la seguridad de z/OS, qué riesgos surgen cuando no se gestionan bien y cómo el análisis de registros SMF se convierte en inteligencia accionable para el SOC.

Qué es SMF y cómo funciona

SMF es un subsistema de z/OS que actúa como notario del sistema. Cuando ocurre un evento relevante —un trabajo batch que termina, un usuario que accede a un dataset protegido, un perfil de RACF que cambia— el componente correspondiente de z/OS escribe un registro SMF con los detalles del evento. Estos registros se identifican por un tipo numérico (SMF record type), numerado del 0 al 255, que indica qué subsistema los generó y qué información contienen. IBM reserva los tipos 0 a 127 para el sistema operativo y sus subsistemas, y deja los tipos 128 a 255 para productos de terceros. En total hay más de un centenar de tipos definidos por IBM, cada uno con sus propios subtipos. Los registros se escriben en tiempo real. Tradicionalmente, se almacenan en unos datasets especiales llamados SMF datasets (denominados SYS1.MANx); en las instalaciones modernas también pueden dirigirse a los log streams del System Logger. Cuando un dataset se llena, z/OS conmuta automáticamente al siguiente. El proceso de vaciado y archivo —realizado por la utilidad IFASMFDP (o IFASMFDL cuando se usan log streams), que muchos equipos llaman coloquialmente "SMF dump"— es crítico: si falla, los registros más antiguos se sobreescriben y la evidencia se pierde para siempre. Este detalle operativo tiene implicaciones de cumplimiento directas. DORA, NIS2 y PCI DSS exigen que los registros de auditoría se conserven durante periodos determinados. Si el proceso de SMF dump no está correctamente configurado y supervisado, la organización puede perder evidencia sin siquiera saberlo.

Análisis de registros SMF: los tipos críticos para el SOC

No todos los registros SMF son igualmente relevantes para la seguridad. Estos son los que cualquier estrategia de monitorización de la seguridad de mainframe debe conocer y vigilar.

Tipos 80 y 83: el corazón del audit trail de seguridad

El tipo 80 es el registro más importante para cualquier auditor o analista de seguridad. Lo genera el External Security Manager —RACF, ACF2 o TopSecret— y captura todos los eventos de seguridad del sistema:
  • Intentos de acceso a recursos (exitosos y fallidos).
  • Cambios en perfiles de usuarios y grupos.
  • Modificaciones de atributos especiales (SPECIAL, OPERATIONS, AUDITOR).
  • Cambios en reglas de protección de datasets y recursos.
  • Operaciones de gestión del propio ESM.
El tipo 83 está documentado por IBM como registro de "Security events" y complementa al tipo 80. Su subtipo 1 recoge la auditoría de acceso a datasets gestionada por RACF, mientras que los subtipos posteriores capturan otros eventos de seguridad del sistema (entre otros, la actividad de LDAP, eventos de cumplimiento de datos y la auditoría de componentes que invocan los servicios de auditoría de RACF). El tipo 81 documenta la inicialización de RACF: registra las opciones y la configuración del ESM vigentes al arranque del sistema. Para el SOC funciona como una línea base de configuración de seguridad, que permite detectar desviaciones cuando alguien modifica opciones críticas de RACF. Para el SOC, estos tipos son el equivalente al mainframe del Security Event Log de Windows. La diferencia es que aquí no hay un agente que los reenvíe automáticamente: hay que buscarlos.

Tipo 90: cambios en el sistema y en la configuración de SMF

El tipo 90 registra cambios de estado del sistema y comandos de operador: modificaciones de parámetros del sistema, cambios de hora y —lo más relevante para la seguridad— cambios en la propia configuración de SMF (comandos SET/SETSMF). Es el registro que delata a quien intenta manipular el reloj del sistema o el propio mecanismo de auditoría para ocultar su actividad. Vigilar el tipo 90 es, en la práctica, garantizar la integridad del rastro de auditoría.

Tipo 30: quién ejecutó qué y cuándo

El tipo 30 captura el ciclo de vida completo de los trabajos y sesiones en z/OS: inicio, pasos intermedios y terminación. Incluye el usuario que sometió el trabajo, el identificador del trabajo, los programas ejecutados, los conjuntos de datos accedidos y los códigos de retorno. Para el SOC es fundamental para correlacionar actividad: si un registro tipo 80 muestra un acceso anómalo a un dataset de nóminas, el tipo 30 permite saber exactamente qué trabajo lo provocó, quién lo lanzó y desde dónde.

Tipo 92: actividad en z/OS UNIX System Services (USS)

El tipo 92 registra la actividad en el subsistema USS (Unix System Services) de z/OS: creación y modificación de ficheros, cambios de permisos, ejecución de procesos y llamadas al sistema. Es el equivalente de auditd en Linux, pero en el mainframe. USS es a menudo el vector de ataque más descuidado en z/OS. Los analistas que no están familiarizados con el mainframe tienden a ignorarlo porque "no parece un mainframe". Error: un atacante que obtiene un shell USS con UID 0 tiene acceso prácticamente ilimitado al sistema.

Tipo 119: eventos de red TCP/IP

El tipo 119 lo genera el stack TCP/IP de z/OS (Communications Server) y captura conexiones de red, errores de protocolo y eventos de seguridad relacionados con las comunicaciones. Es el punto de partida para detectar movimiento lateral hacia o desde el mainframe.

Tipos 14, 15, 17 y 18: actividad sobre datasets

Los tipos 14 y 15 registran la apertura de datasets para lectura y escritura respectivamente. El tipo 17 registra la eliminación de datasets y el tipo 18 su renombrado, una técnica habitual para ocultar ficheros o evadir reglas de protección basadas en el nombre. Para un analista que investiga una posible exfiltración de datos, estos registros son imprescindibles: permiten saber exactamente qué ficheros se abrieron, cuándo, por qué usuario o trabajo y si alguien intentó borrarlos o disfrazarlos.

Tipos 110 y 100/101/102: middleware crítico (CICS y Db2)

El tipo 110 registra la actividad de CICS Transaction Server (estadísticas y monitorización de transacciones), mientras que Db2 utiliza varios tipos: el 100 para estadísticas, el 101 para accounting y el 102 para trazas de rendimiento y auditoría (los registros IFCID, que incluyen la traza de auditoría de Db2). En instalaciones donde las aplicaciones críticas corren sobre CICS o donde los datos residen en Db2, estos registros son parte indispensable del rastro de auditoría. Conviene no confundirlos: el tipo 102 es de Db2, no de CICS.

El problema que nadie menciona: el volumen y la complejidad

Un mainframe de tamaño medio en un banco o aseguradora puede generar varios gigabytes de registros SMF al día. En instalaciones grandes, hablamos de decenas de gigabytes. La granularidad es extraordinaria, pero trabajar directamente con esa masa de datos binarios resulta prácticamente inviable sin las herramientas adecuadas. Los desafíos concretos que enfrenta cualquier equipo que intente hacer auditoría de mainframe sobre SMF sin una solución especializada son cuatro:
  • Formato binario propietario: los registros SMF no son texto. Cada tipo tiene su propio layout, con campos de longitud fija y variable que difieren entre las versiones de z/OS. Parsearlos correctamente exige un conocimiento profundo de la documentación técnica de IBM, que se extiende a miles de páginas.
  • Correlación entre tipos: un evento de seguridad real rara vez se refleja en un único tipo de registro. Relacionar un tipo 80 con su trabajo del tipo 30, con los datasets del tipo 14/15 que abrió y con la conexión de red del tipo 119 que lo inició requiere una lógica de correlación que va mucho más allá de un simple grep.
  • Gestión de la retención: los registros SMF deben archivarse, indexarse y mantenerse accesibles durante los periodos que exigen las normativas aplicables. Sin un proceso robusto, la evidencia se pierde o resulta imposible de recuperar cuando una auditoría o una investigación forense la necesita.
  • Ausencia de normalización: el mismo evento puede codificarse de forma diferente según si el ESM es RACF, ACF2 o TopSecret. Un SIEM que ingiere eventos sin tener en cuenta estas diferencias producirá falsos positivos, falsos negativos o incluso datos incorrectos.
A estos cuatro desafíos se suma un riesgo silencioso: si los buffers de SMF se saturan, z/OS empieza a perder registros y lo notifica mediante el tipo 7 (SMF data lost). Ese registro es, paradójicamente, la prueba de que el propio rastro de auditoría tiene agujeros. Si nadie lo vigila, la pérdida pasa inadvertida y la organización descubre el hueco justo cuando necesita esos datos para una investigación o una auditoría.

Correlación de eventos y detección de anomalías en z/OS

El valor real del análisis de registros SMF no radica en un tipo aislado, sino en la correlación de eventos de seguridad en mainframe. Un único registro rara vez cuenta la historia completa; es la relación entre varios tipos lo que revela un patrón de ataque. Pensemos en un caso típico de detección de anomalías en z/OS: un acceso fallido reiterado (tipo 80) seguido de un acceso exitoso atípico (tipo 80) sobre un dataset de alto valor, correlacionado con la apertura masiva de ese dataset (tipo 15) dentro de un trabajo batch (tipo 30) lanzado fuera de la ventana horaria habitual, y precedido por una conexión de red inusual (tipo 119). Ninguno de esos eventos, por separado, justifica una alerta. Su correlación, sí. Esta es la diferencia entre un SOC de mainframe que ve puntos aislados y uno que reconstruye la secuencia completa de un incidente.

Cómo DataPASS convierte SMF en inteligencia para el SOC

DataPASS aborda de forma nativa todos los problemas descritos. Está diseñado específicamente para z/OS y entiende los registros SMF sin agentes adicionales, conectores intermedios ni transformaciones manuales. Su funcionamiento respecto a SMF se articula en tres capas:
  • Ingesta y decodificación nativa: DataPASS lee directamente los conjuntos de datos SMF de z/OS, decodifica todos los tipos relevantes para la seguridad y normaliza su contenido en un modelo de datos uniforme. El analista no necesita saber si está mirando eventos RACF tipo 80 o registros de actividad USS tipo 92: la plataforma los abstrae y los presenta de forma coherente.
  • Correlación automática entre tipos de registro: la plataforma relaciona automáticamente los tipos 80, 30, 14/15 y 119 para detectar patrones que un análisis manual pasaría por alto, lo que habilita el logging y la trazabilidad mainframe de extremo a extremo.
  • Generación de evidencia de cumplimiento: DataPASS mapea los eventos SMF a los controles de los marcos normativos aplicables —DORA, NIS2, PCI DSS, SOX, GDPR— y genera los informes de evidencias de auditoría z/OS que los auditores externos necesitan. En lugar de exportar terabytes de registros binarios ante una petición de auditoría, el equipo entrega informes estructurados que demuestran el cumplimiento de controles específicos.

Lo que una mala gestión de SMF cuesta realmente

Imagina el escenario —uno que cualquier auditor de mainframe reconocerá como plausible—: durante una inspección de cumplimiento del PCI DSS en una entidad financiera, los auditores solicitan los registros de acceso a los sistemas de pago de los últimos 12 meses. La entidad no puede proporcionarlos porque el proceso de IFASMFDP ha fallado silenciosamente durante varios meses y los registros se han sobrescrito. El resultado: una no conformidad crítica, un proceso de remediación largo y costoso, y la exposición a sanciones. No es un problema de seguridad en sentido estricto. Es un problema de gestión de SMF, y es exactamente el tipo de fallo operativo que se produce cuando el vaciado de los datasets SMF no está supervisado con alertas. Este caso ilustra algo que los equipos de seguridad de mainframe conocen bien, pero que rara vez llega a los CISO y a los equipos de gobierno: SMF no es solo un mecanismo de logging; es la única evidencia de lo que ocurre en el mainframe. Su gestión deficiente no solo afecta la capacidad de detectar ataques, sino que también afecta directamente la de demostrar cumplimiento ante reguladores y auditores.

Checklist de seguridad z/OS: lo mínimo que debes verificar sobre SMF

Si gestionas o auditas la seguridad z/OS de un entorno mainframe, estas son las preguntas que deberías poder responder afirmativamente hoy mismo:
  • ¿Está el proceso de vaciado de SMF (IFASMFDP/IFASMFDL) automatizado y supervisado mediante alertas de fallo?
  • ¿Están los tipos 80, 83, 81, 90, 30, 92, 119 y 14/15/18 recopilados y archivados activamente?
  • ¿Se monitoriza el tipo 7 (SMF data lost) para detectar la pérdida de registros por saturación de buffers?
  • ¿Se vigilan los cambios en la configuración de SMF y en el reloj del sistema (tipo 90) como parte de la integridad del audit trail?
  • ¿Cuánto tiempo se retienen los registros SMF archivados? ¿Cumple con las normativas aplicables?
  • ¿Existe un mecanismo de correlación que cruce eventos de distintos tipos de registro?
  • ¿Puede el SOC consultar registros SMF históricos en menos de una hora ante un incidente?
  • ¿Están los registros SMF integrados en el SIEM corporativo con correcta normalización correcta?
Si la respuesta a alguna de estas preguntas es negativa o "no lo sé", el mainframe tiene un punto ciego que ninguna otra herramienta de seguridad puede compensar.

Preguntas frecuentes

¿Cómo automatizar auditorías en z/OS?

Automatizar auditorías en z/OS pasa por dejar de tratar los registros SMF como ficheros que se revisan manualmente. La vía práctica consiste en recopilar de forma continua los tipos relevantes (80, 83, 30, 92, 119, 14/15), normalizarlos en un modelo uniforme y aplicar reglas de correlación y mapeo a controles normativos que generen informes de evidencia sin intervención manual. Ese es precisamente el enfoque de la auditoría continua sobre SMF.

¿Cómo detectar cambios no autorizados en z/OS?

Los cambios no autorizados dejan rastro en varios tipos de registro: modificaciones de perfiles y atributos especiales en el tipo 80, actividad de trabajos en el tipo 30 y cambios en el sistema de ficheros USS en el tipo 92. La detección fiable exige correlacionar estos tipos y comparar la actividad con una línea base, de modo que una modificación fuera de la ventana de cambios o realizada por una cuenta atípica genere una alerta.

¿En qué se diferencia el SMF de un SIEM?

SMF es la fuente de datos: el registro nativo de todo lo que ocurre en z/OS. Un SIEM de mainframe es la capa que ingiere, normaliza, correlaciona y emite alertas a partir de dichos datos. Sin SMF, el SIEM no tiene qué ingerir del mainframe; sin normalización y correlación adecuadas, los datos de SMF resultan casi inutilizables. Ambos son complementarios, no excluyentes.

Conclusión

Los registros SMF son el fundamento sobre el que descansa cualquier capacidad de auditoría de mainframe y de detección en z/OS. Son la fuente primaria de información sobre lo que ocurre en un mainframe: sin ellos, el SOC opera a ciegas en el sistema que probablemente procesa las transacciones más críticas del negocio. Su complejidad técnica —formato binario, volumen masivo, heterogeneidad entre tipos y entre ESMs— es real, pero no es una excusa para ignorarlos. Es precisamente por eso que existen herramientas como DataPASS: para que el conocimiento profundo de los internos de z/OS no sea un requisito previo para tener visibilidad de seguridad en z/OS. Un SOC que entiende SMF es un SOC que realmente abarca el mainframe. ¿Quieres saber cómo DataPASS integra los registros SMF en tu estrategia de auditoría continua? Contacta con el equipo de Bsecure para una demostración técnica adaptada a tu entorno.