Your security team has a dashboard for almost everything: endpoints, cloud workloads, the network edge, and identity. Then there’s the mainframe, quietly running your most sensitive transactions and holding your most regulated data, and somehow it’s the one system your SIEM can’t actually see.
A SIEM (Security Information and Event Management) platform like Splunk, IBM QRadar, or ArcSight is only as complete as the data flowing into it. On distributed systems, agents and connectors make it easy. The mainframe is different.
z/OS records security activity across sources that don’t look anything like a typical log file: SMF records, the system log, the operator interface, and the access events produced by RACF, ACF2, and Top Secret, plus activity from Db2, CICS, FTP, and UNIX System Services (USS). The information is all there. But it’s in mainframe-native formats, at mainframe volume, with thousands of records that a distributed SIEM can’t ingest or interpret on its own.
So the events exist, and nobody is watching them in real time. Mainframe security is reviewed through batch jobs and after-the-fact reports, long after a response would have mattered. For a platform that often sits at the center of banking, healthcare, government, and utility operations, that’s a meaningful gap to leave open.
If the blind spot were purely technical, you might live with it. It isn’t. It’s a compliance problem, too.
Frameworks like PCI DSS, SOX, HIPAA, GDPR, GLBA, and FISMA all expect centralized, monitored logging across the systems that hold regulated data. The mainframe is squarely in scope. When its security events aren’t flowing into your SIEM, you’re left proving control coverage by hand: exporting reports, stitching together evidence, and explaining to an auditor why one of your most critical platforms is monitored differently from everything else.
That’s why this gap surfaces in audit after audit. It’s also why closing it pays off twice: once in genuine security visibility, and again in the time your team gets back at audit season.
The pressure is sharpest in the industries that run the most mainframe workloads: financial services, subject to PCI DSS and SOX; healthcare, subject to HIPAA; government, subject to FISMA; and utilities, subject to their own regulatory regimes. In each, the mainframe often processes the very transactions and records that the regulations exist to protect, so a monitoring gap there isn’t a minor exception. It’s a finding waiting to happen.
VitalSigns SIEM Agent for z/OS (VSA, formerly SMA_RT) is purpose-built to bridge the mainframe to the SIEM you already run. It works in three steps:
All three steps happen in real time, which is the whole point: security teams see mainframe activity as it happens, not in a report the next morning.
Just as important for the people who run z/OS, VSA is light. It carries a small footprint in each LPAR with little CPU overhead, its workload is zIIP-eligible (SDS publishes a benchmark white paper on the offload and cost savings), and it installs without requiring a z/OS IPL. SDS notes that customers are often up and running within about an hour. It’s also a Ready for IBM Security Intelligence product, so it’s validated to work the way your SIEM expects.
Once VSA is delivering events, the mainframe stops being a separate world. In Splunk, for example, teams work from dashboards built for VSA data (All Activity, Failed Access, APF events, and FTP activity) alongside the rest of their environment. A failed logon storm against a RACF resource appears alongside the suspicious activity from every other system in the same console, under the same alerting rules.
For a CISO or IT director, that means an enterprise-wide view of risk rather than a mainframe exception. For the security analyst, it means mainframe events are searchable and routable like any other source. For the mainframe team, it means the SIEM and audit requirements are handled without having to babysit new batch reporting.
VSA’s credibility here isn’t just marketing: it was named to DBTA’s Trend-Setting Products list, and SDS publishes a Major Hospital case study showing how a real organization brought its z/OS security data into the enterprise SIEM. Those are the right next reads if you’re evaluating whether this fits your environment.
The mainframe shouldn’t be the one platform your SIEM can’t see. With VSA, z/OS security events flow into the tools your team already uses, in real time, in the formats your SIEM already understands. That closes the visibility and compliance gaps simultaneously, with minimal overhead on the system itself.
If you’re weighing it, start with the proof: read the Major Hospital case study to see it in a live environment, and review the zIIP benchmark white paper to understand the performance and cost picture. When you’re ready to see it against your own setup, request a demo or a 30-day trial with full setup support.
We offer individualized product demonstrations by request. Your organization can also try SDS Software on your system for 30 days, free of charge.
Phone: (800) 443-6183
Phone: (763) 571-9000
200 Village Center Drive, Suite 250
North Oaks, MN 55127
USA
