Mainframes hold the heart of the most critical business processes in finance, healthcare, and government. Yet many security programmes still draw a neat line around them, treating z/OS as out of scope for red teaming, scenarios, and cyber risk quantification.
This article explains clearly and practically what red teaming, cyber scenarios, and cyber risk quantification (CRQ) are, and why they must be safely extended into the mainframe ecosystem. Not as a theoretical exercise, but as a necessary step toward realistic resilience.
Why the Mainframe Can’t Stay Out of Scope
The mainframe runs card payments, core banking, insurance engines, healthcare systems, and the batch jobs that pay salaries. When ransomware groups or nation-states target an organisation, they may start with a laptop or an exposed web service, but their real objective is access to the systems and identities that lead to z/OS, CICS, IMS, and Db2.
If testing stops at the distributed perimeter, you measure only part of the real attack path.
“If your testing stops at the distributed perimeter, you are measuring only part of the real attack path.”
Why Testing Often Stops at z/OS
It’s easy to see why mainframes are often skipped in pen testing and red teaming. Familiar reasons why mainframes get excluded:
- Operational risk concerns
- Limited z/OS expertise within penetration testing firms
- Scarce and fragile change windows
- Security tooling that prioritises Linux and Windows
- SMF and subsystem logs that arrive as text nobody clearly owns
At the same time, regulation pushes in the opposite direction. In Europe, Digital Operational Resilience Act (DORA) and PCI DSS require resilience across the entire transaction stack, not just web tiers and firewalls.
If the system that actually moves the money is absent from testing, the evidence is incomplete. The test is invalid.
Red Teaming, in Plain Terms
Red teaming is a realistic cyberattack rehearsal. A red team plays the role of an adversary, using real tactics, techniques, and procedures (TTPs), under clear rules of engagement.
Instead of scanning everything and producing a long list of findings, the team follows a script, with a goal: “Can we move from this compromised desktop to this mainframe dataset without being detected?”
Actions remain bounded and reversible. The output shows exactly how far the attacker got and what defenders saw along the way.
What That Looks Like on the Mainframe
A realistic mainframe red team exercise might include:
- Starting outside the firewall with infrastructure used to test user awareness
- Pivoting through a compromised desktop
- Accessing TN3270 or SSH
- Exploiting z/OS credentials or subsystem access
Alternatively, APIs and subsystems such as CICS, IMS, or Db2 may form the target. The key point is simple: include the mainframe as part of the story, not as an untouchable, mystical box.
Rules of engagement are clear during exercises and safety rails matter, such as no data changes, and there’s no uncontrolled execution. But within those rails, the team behaves like a real attacker.
What Are Cyber Scenarios?
Cyber scenarios are the table-top sibling of red teaming. Instead of hands-on keyboards, teams walk through a scripted incident.
A scenario might begin with a disgruntled insider submitting a malicious batch job or with phishing that leads to stolen credentials. The single question to answer is: “What happens next?”
A well-constructed scenario defines three things:
- The mission: For example, can an attacker disrupt payments by abusing batch scheduling?
- The path: Which identities, systems, and controls are involved?
- The outcomes: What data or services could be exfiltrated, changed, delayed, or stopped?
Because scenarios happen in meeting rooms rather than live LPARs, SMEs, it allows application owners and senior leaders to explore uncomfortable ideas without operational risk. Teams can pause, rewind, and compare what they expect to happen with what the logs and runbooks actually show.
This approach works especially well when operational caution is high and technical testing opportunities are limited.
Where Cyber Risk Quantification Fits
Cyber Risk Quantification (CRQ) transforms the outputs of red teams and scenarios into actionable decisions and metrics. Instead of saying “Oh no, this looks bad,” CRQ estimates the frequency and impact of events using evidence such as control maturity, incident data, test results, and expert judgment.
Applied to the mainframe, CRQ asks the same questions you already ask elsewhere:
- How easily could a realistic attacker reach a CICS region or Db2 subsystem?
- What could they actually do with that access?
- Would the SOC or operations teams notice?
- What would the business impact be for downtime, data loss, and regulatory exposure?
Early models don’t need perfection. Value comes from consistency and from linking estimates back to concrete evidence rather than gut feel.
MITRE ATT&CK Is the Default, But It’s Incomplete
MITRE ATT&CK provides a shared language for red teaming and scenarios. It breaks intrusions into attacker goals (tactics) and methods (techniques). Most SOCs and threat intelligence teams already use it for distributed systems.
Mainframe-specific TTP data remains scarce, but it doesn’t need to stay that way. A small group of experts within the Mainframe Hackers Society contributes research, and earlier work by BMC found that extending ATT&CK to the mainframe ecosystem is achievable.
Example: Mainframe ATT&CK Mapping
- Initial Access: Phishing leads to credentials reused on a TN3270 jump host
- Credential Access: Misconfigured FTP exposes sensitive datasets
- Execution: CICS transactions submit jobs to JES for later processing
Tagging tests and scenarios with ATT&CK techniques allows teams to compare mainframe results directly with the rest of the estate. You may discover strong controls for lateral movement on Windows, but gaps on z/OS.
Designing Safe, Bounded Mainframe Exercises
Safety is the biggest concern with mainframe red teaming, and rightly so. Nobody wants to be the person who took CICS down.
Safe exercises are possible with the right guardrails.
“The goal isn’t maximum destruction. It’s tracing realistic paths to gather high-quality evidence.”
Common safety measures include:
- Running tests in a dedicated non-production LPAR with real network paths and matching security controls
- Using obfuscated datasets where access must be proven without exposing live data
- Agreeing on hard stop conditions and a clear abort process
- Involving mainframe SMEs early to identify fragile areas and safer alternatives
The goal isn’t maximum destruction. It’s tracing realistic paths far enough to gather high-quality evidence. Often, a single successful dataset access, job submission, or ESM query tells the story.
Feeding Results Back Into Decisions
Mainframe-aware scenarios and red team exercises generate evidence that directly feeds CRQ and control ownership.
Instead of vague statements like, “The mainframe risk is low,” teams can point to what actually happened:
- How long it took to reach a privileged TSO ID
- Whether anyone noticed unusual TN3270 traffic
- How the abuse of a batch scheduler account could delay payments
Those observations translate into estimated frequencies and losses, which can be weighed against competing risks for budget allocation. You may find that proper SMF integration with your SIEM delivers more risk reduction than new hardware, or that a small control change removes an entire escalation path.
Most importantly, the mainframe is part of the same security conversation as everything else.
Getting Started: Three Practical Steps
1. Work Within Your Culture
If the mainframe has never been in scope, the first barrier is cultural. Secure sponsorship from leaders willing to accept the assessment. Bring mainframe engineers and security stakeholders into shared decision-making early as process champions.
2. Start Small
Choose one or two meaningful scenarios—such as ransomware moving from desktops into batch, or abuse of a shared operator ID. Define what “safe” looks like. Begin with a table-top, then move to a tightly bound technical test.
3. Show Results
Over time, small exercises build a realistic picture of attacker movement and defender visibility. That picture is exactly what regulators and executives increasingly expect to see.
A More Secure Mainframe
The mainframe has carried critical workloads for decades. It deserves a place in modern security: not as an untouchable relic, but as another platform where teams practise, measure, and improve.
As someone with a foot in both the worlds of cybersecurity and mainframes, I believe that including mainframes is no longer optional; it’s a necessary step toward realistic resilience.
Curiosity piqued?
Read more from Kev Milne, one of the few professionals focused on mainframe penetration testing.
0 Comments