SPONSORED CONTENT

Continuous Enforcement:

A Proactive Approach to Mainframe Security

SAMM and continuous enforcement
Nation-states, hacktivists, ransomware operators, and AI-powered threats are converging on the world's most critical system of record–the IBM Z mainframe. 
The good news? The sky is not falling. The platform remains one of the most securable computing environments ever built. But "securable" and "secure" are not the same thing. That distinction could be the difference between business continuity and an emergency meeting with lawyers in the boardroom.
 
That’s why you need continuous enforcement: a proactive, behavior-driven approach to mainframe security that goes far beyond traditional alerting. It's not a radical idea. It's a necessary evolution.

A Perfect Storm of Mainframe Security Threats

Storms are inevitable. Experienced organizations don't debate whether bad weather will arrive, they prepare for before it does. IT security is no different.
 
The threat landscape has shifted dramatically. Organizations running z/OS environments now face:
  • Nation-state actors from China, Russia, North Korea, and Iran, running sophisticated, persistent intrusion campaigns
  • Hacktivists probing systems for sport and ideology
  • Ransomware operators who embed themselves into platforms and hold entire operations hostage
  • Emerging AI and quantum computing threats that have the potential to break encryption and manipulate data at unprecedented speed and scale
 
And don’t forget about the regulatory pressures. DORA now mandates recovery of information within two hours. New certificate requirements compress timelines to as few as 41 days. GDPR, HIPAA, SOX, PCI-DSS 4.0, NIST, and a growing list of frameworks all have teeth. 
 
Organizations out of compliance face fines, class action lawsuits, and reputational damage that can take years to recover from, if they recover at all.

3 Dangerous Misconceptions About Mainframe Security

Before discussing solutions, it's worth addressing the thinking that creates the problem in the first place. Three pervasive misconceptions in mainframe security leave organizations unnecessarily exposed.
1: Mainframe security
2. Threats
3: Trust
DevOps graphic
MISCONCEPTION 1

The mainframe is already secure.

This may be the most dangerous belief in enterprise IT. The IBM Z platform has been running critical infrastructure for over 60 years, and in some cases that track record has bred complacency. Executives and senior leadership often assume that because it's a mainframe, it's inherently protected.

Professional security assessments and audits tell a very different story. In one recent engagement, a regional financial institution was found to have more than 20 severe risks, 110 high risks, and 40 medium risks—all sitting quietly in their environment for 15 to 20 years. Access that should have been revoked wasn't. Surrogate class settings were left open, meaning users could pass elevated privileges to others. Old roles and permissions from long-departed employees were never cleaned up.

The exposure only came to light after the retirement of the organization's longtime mainframe administrator, who was trusted, knowledgeable, and in control for nearly two decades. When the external audit firm recommended a review, the results shocked the board. Immediate action was taken, but the reality was sobering: the system had been vulnerable for years without anyone knowing it.
1: Mainframe security
2. Threats
3: Trust
DevOps graphic
MISCONCEPTION 2

Threats only come from outside.

The instinct to protect the perimeter is understandable, but it's incomplete. Approximately 35–38% of malicious or harmful activity originates internally from individuals who are authorized to be on the system. This includes deliberate insider threats as well as unintentional actions, like the Anthem Breach, where an employee clicked a malicious LinkedIn link and inadvertently opened a pathway into the company's systems.
 
Perimeter defenses are necessary but insufficient. If you're only looking out, you're missing more than a third of the threat surface.
1: Mainframe security
2. Threats
3: Trust
DevOps graphic
MISCONCEPTION 3

Privileged users can be trusted implicitly.

A trusted employee is not the same as a trustworthy system. Privileged access must be monitored, managed, and periodically revalidated. This is regardless of staff seniority, tenure, or perceived expertise. Organizations that grant broad access to a small number of "mainframe gurus" and then never audit that access are creating single points of failure with catastrophic potential.
 
A large international insurance company that had grown through acquisitions learned this lesson the hard way. Each acquired entity brought its own legacy access structures, security roles, and account configurations. None of them were properly consolidated or cleaned up. The result: a sprawling web of excess access, inappropriate surrogate class usage, and ineffective controls for privileged accounts—all compounding across multiple systems over years.

Why Alerting Isn't Enough

For the better part of the last decade, the conversation in z/OS security has centered on alerts. These real-time notifications flag suspicious activity and wait for a human to respond. Continuous alerting is better than nothing. But it’s fundamentally reactive, placing the entire burden of response on human judgment under pressure.
 
The 2013 Target Breach is a textbook illustration of where alerting falls short. The attackers entered Target's systems through a third-party HVAC vendor, moved laterally to point-of-sale registers, and began collecting and encrypting credit card data. Alerts were generated. The Security Operations Center (SOC) flagged the activity and notified management. Management did nothing. The encrypted data being transmitted out of the network looked, on the surface, like normal high-traffic holiday activity. Nobody acted.
 
Tens of millions of customers had their payment data stolen.
 
The failure wasn't the alerting system. The failure was the assumption that an alert, by itself, constitutes a security posture. It doesn't.
 
Enforcement, on the other hand, means the system is configured to prevent unauthorized behavior from completing. It involves whitelisting who should have access to which files, encrypting all transmission lines, and ensuring that when someone attempts to act outside defined policy, they are stopped. Not flagged. Stopped.

The 3 Core Principles of Continuous Enforcement

Continuous enforcement is built on three interconnected principles: understanding and anticipating behavior, monitoring at the file level, and locking down anomalies in real time.
1: Anticipating Behavior
2. File Integrity Monitoring
3: Real-Time Lockdown
DevOps graphic

Anticipating Behavior

The objective isn’t to document what happened. It’s to understand what should happen—and to intercept anything that deviates from it.
 
This requires organizations to define, in advance, who should have access to what, under what circumstances. Payroll files, transmission channels, privileged commands, for example, should have a defined set of authorized users and authorized behaviors. When an action falls outside those definitions, enforcement prevents it from proceeding.
 
The tools enabling this approach must be designed to understand behavioral context in z/OS environments, not simply log events and wait.
1: Anticipating Behavior
2. File Integrity Monitoring
3: Real-Time Lockdown
DevOps graphic

File Integrity Monitoring (FIM) for z/OS

FIM isn’t new to open systems architectures, but its application in z/OS environments remains underutilized. The concept is straightforward: every file has measurable attributes, including size, permissions, and cryptographic checksums. If any of those values change unexpectedly, it warrants immediate investigation.
 
This isn't optional for compliance-conscious organizations. FIM is explicitly required under:
  • GDPR (European data protection)
  • HIPAA (U.S. healthcare)
  • SOX (Sarbanes-Oxley for financial reporting)
  • PCI-DSS 4.0 (payment card security)
  • NIST frameworks
  • CIS benchmarks
  • NYC 500/DORA (financial services regulations)
  • ISO standards
These regulations don't exist in a vacuum. They were created because organizations failed to implement adequate controls on their own. The teeth are real: non-compliance creates liability for boards, executives, and the organization's ability to obtain cybersecurity insurance.
1: Anticipating Behavior
2. File Integrity Monitoring
3: Real-Time Lockdown
DevOps graphic

Real-Time Lockdown of Suspicious Activity

When a deviation is detected, an organization can’t just wait for a human to review a report. Automated lockdown capability prevents further activity from a suspicious process or account while an alert is simultaneously dispatched. This distinction is what separates enforcement from monitoring.
 
This is especially critical in ransomware scenarios. If an actor has embedded themselves in your z/OS environment and begins manipulating files, every second matters. The ability to detect the change in a system's expected state and immediately quarantine that activity is the difference between an incident and a catastrophe.

Real-World Consequences: What Happens Without Enforcement

Real-world examples paint a consistent picture. Organizations that neglect continuous enforcement face real, documented consequences.
 
The Regional Financial Institution: Years of accumulated access vulnerabilities discovered only after an audit triggered by an administrator's retirement. Once the board understood the exposure, they faced immediate legal liability under SOC requirements, and the specter of class action suits if any data had been exfiltrated without their knowledge.
 
The International Insurance Conglomerate: A series of acquisitions over 15 years created a patchwork of legacy systems, none of which were properly secured during integration. Excess privileged access, leftover security roles, and inappropriate surrogate class configurations created an environment where a single breach could touch dozens of interconnected systems.
 
The Binary Code Scan Discovery: An organization storing Personally Identifiable Information (PII) for military personnel and government records, which is an environment that would pass a standard audit, was found to have a backdoor embedded in its binary code. The backdoor provided full access to every piece of PII data on the system: Social Security numbers, dates of birth, family information, driver's license data. It was only discovered because a binary code scan was performed. Standard auditing processes wouldn’t have caught it.
 
These aren't hypothetical scenarios. They are active, ongoing patterns across financial services, insurance, healthcare, and government sectors, all running on the mainframe.

SAMM: FIM Built for z/OS

Vanguard's Software Application and Malware Detection (SAMM) is a FIM solution designed specifically for z/OS environments. SAMM addresses the unique requirements of mainframe operations at enterprise scale.
 
The approach begins with establishing a full baseline. This involves complete discovery of the organization's SMPE (SMP/E) environment and software stack. This baseline represents the mathematically verified “known good” state of the system: every authorized program, every expected value, every approved component of the software stack that the organization relies on to run its operations.
 
From that baseline, SAMM runs Delta Discovery, which is a continuous scanning process that can be configured at intervals as short as five minutes. On each scan, SAMM examines the mathematical values across the enterprise's LPARs using message token locators. If the math doesn't add up—if any component of the expected stack has changed in an unexpected way, the system categorizes the finding:
Bad, red:

↪
Bad, red:
A clear deviation from the established baseline requiring immediate action
Suspicious, yellow:

↪
Suspicious, yellow:
An anomaly that doesn’t look obviously malicious but warrants investigation
Expected, green: 

↪
Expected, green:
A known, authorized change consistent with the established stack
When a suspicious or bad change is detected, SAMM doesn't simply send a notification to a queue. It locks down the activity, preventing further execution or access from the affected component, and simultaneously sends an active alert to the SIEM and designated contacts. The exposure is contained. Therefore, the investigation begins from a position of control, not crisis.
 
This architecture reflects the core philosophy of continuous enforcement: anticipate the problem, detect the deviation, and stop it before it becomes a breach.

The Cost of Inaction

The most common objection to proactive mainframe security investment is lack of budget. It's a short-sighted calculation.
 
One client’s former CISO spent four years submitting budget requests for the security infrastructure his organization needed. Those requests were never approved. When the breach occurred, the board hired a lawyer to investigate why the systems hadn't been secured. That lawyer walked into the boardroom carrying four years of unfunded budget requests. That organization no longer exists under that name. The breach erased it.
 
The budget question isn't whether you can afford continuous enforcement. It's whether you can afford not to have it. 
 
The fines are real. The class action exposure is real. The reputational damage is permanent. And for the individuals in the CISO role, whose careers are defined by their ability to protect these systems, the personal stakes are high.
 
Security is the foundation on which every other business investment rests.

Stop Waiting for the Alert

0
%
IBM Z processes approximately 80% of the world's critical infrastructure transactions
The IBM Z platform is one of the most powerful and securable computing environments in the world. It processes approximately 80% of the world's critical infrastructure transactions. The organizations that depend on it have every reason to protect it and every tool available to do so effectively.
 
But protection requires action. It requires moving beyond the assumption that mainframes are inherently secure. 
 
It requires acknowledging that threats come from inside as often as they come from outside. 
 
It requires replacing passive alerting systems with active enforcement frameworks that anticipate behavior, monitor at the file level, and lock down anomalies before they become breaches.
 
Evaluate your current security posture today. Start with an independent audit of your z/OS environment to understand where your real vulnerabilities lie. Then ask yourself whether your current tools are built for enforcement or just alerts. If you're not sure, contact Vanguard's security specialists to discuss how SAMM and continuous enforcement strategies can be applied to your environment. Finding the gaps on your own terms is always better than having someone else find them for you.
Share:  

Read recent editions of Mainframe Master Innovations