While the mainframe’s reputation for security is well deserved, it is not invulnerable and nothing about it is “inherently” secure. Like all systems, it is only as good as the people and processes that support it. But unlike many other systems, the mainframe powers mission-critical workloads that most organizations can’t afford to neglect.
At the end of the day, mainframes are simply server platforms, and they’re just as vulnerable to modern attacks. Yet many organizations struggle to implement fundamental security practices that have been proven to reduce the risks in today’s threat environment.
This is the foundation for our Zero Trust Deep Dive series. Part 1 covered why Zero Trust is imperative for mainframe security. Part 2 explored how the right tools and buy-in can set up ZT implementation for success. Now, in Part 3, we’re going to outline the three primary components of a mainframe Zero Trust strategy.
#1 Reduce Up to 99% of Mainframe Security Risk With MFA
Nearly 1/3 of all data breaches were accomplished using valid user credentials, including internal threat and compromised credentials. If your organization has users with permission to access mainframe data or storage — and we’re willing to bet it does — there is the potential that stolen credentials could be used for malicious purposes. Oddly enough, there is a very easy “fix” for this, but we find that many organizations simply aren’t using it: multi-factor authentication (MFA).
MFA requires users to present multiple forms of evidence (i.e., factors) to be successfully authenticated. These factors can include a passphrase, temporary code, physical token, biometric scan, accessing from within a secure network, and many others. According to CISA, this mechanism alone can reduce hacking risk by up to 99%.
According to CISA, one simple tool can reduce mainframe risk by up to 99% — multi-factor authentication (MFA).
Today, most of us are familiar with using MFA when accessing company assets. Email frequently requires a code to be sent to the user’s mobile device to authenticate and gain entry. Yet for the vast majority of mainframes, MFA isn’t being implemented. And when it is, it’s primarily for privileged users.
Why is email considered to be so sensitive as to require protection behind a second factor, yet the mainframe, with likely the most crucial and sensitive data in the entire company, is not deemed sensitive enough for that same technique? The introduction of APIs eliminated our ability to rely on the mainframe’s perimeter security.
Now, MFA is one of the most important steps you can take toward managing risk. By making it harder to steal IDs, you run less risk of them being used for nefarious purposes.
#2 PAM: The Right Way to Handle Privileged Users on the Mainframe
In the last installment of our Zero Trust Deep Dive series, we covered the importance of Cleanup and a Configuration Management Database (CMDB). Running Cleanup early—for at least 15 months prior to taking action to clean up entitlement and IDs—and reviewing ownership rights through your enterprise CMDB sets you up to make strategic decisions about who should have access to what.
The next layer of protection and an integral part of Zero Trust is privileged access management (PAM). This methodology enables a more granular and systematic approach to access management, reducing the potential impact of credential abuse or misuse.
Principle of Least Privilege
The first element of PAM is the principle of least privilege. Not only is least privilege considered a best practice, but it is also a codified requirement to meet several security standards and regulations, including PCI-DSS, NIST 800-53, HIPAA, and others. This methodology limits permissions to only those “that are absolutely necessary to perform their assigned function,” and it applies to all users, applications, systems, and any other entities that need access to your mainframe. By limiting all entitlements, you essentially limit the blast radius should those credentials be compromised.
But what about users who need those elevated privileges, like system administrators?
Well, we’d argue that there are very few users, if any, in your organization who need unlimited access, from any location, using any device, and at any time. This is equally true for “vaulted” IDs, or privileged IDs that can be checked out by various users when needed. Instead, these highly-provisioned accounts should belong to specific individuals and have appropriate access based on their daily responsibilities — which can be temporarily elevated when there is a business need to do so.
There are very few users, if any, in your organization who need unlimited access, from any location, using any device, and at any time.
Just-in-Time Access
The second component of PAM is just-in-time access. This adds another dimension to your Zero Trust implementation by establishing a specific period during which those permissions can be elevated. This allows the user to complete the required tasks before their privileges are de-escalated. With the right tools, these entitlement changes can (and should) be completed automatically, minimizing strain on the mainframe team.
#3 Continuous Monitoring for Faster Response and Audit-Readiness
As we established in Part 1, our Zero Trust mentality means that we always assume that our mainframe will be breached. Detecting breaches can be frustratingly difficult, but preparing for the worst enables us to build out a system of compromise indicators to warn us about suspicious activity.
Before effective detection can occur, you need a clear understanding of who has access to what and why. The stakeholder engagement, access cleanup, and ownership mapping outlined in Part 2 create the necessary foundation for identifying unusual or risky activity. With that groundwork in place, monitoring efforts can focus on true indicators of compromise rather than background noise.
Continuous security event monitoring is commonplace on other cloud and distributed platforms and is certainly available for the mainframe. However, too often companies focus on simply logging SMF records. In reality, mainframe monitoring should include z/OS operating system configuration files, security files, and other critical records. It’s also important to monitor individual user behavior — especially those privileged users — and sensitive data access to understand and detect insider threats.
Without continuous mainframe monitoring, you’re unable to identify changes and suspicious activity in real-time, and you certainly can’t minimize exposure during a security event.
It’s also important that mainframe monitoring be upgraded from point-in-time snapshots. Continuous monitoring is crucial for identifying changes and suspicious activity in real-time, enabling faster identification, investigation, and response times, and to minimizing exposure.
After setting up a continuous process to gather detailed security monitoring information, you’ll also need a centralized security insights dashboard where that data is aggregated and analyzed. Our Security Insight capability aims to provide the reporting needed to support faster remediation and more effective prioritization. As a bonus, this tool helps your organization answer the questions needed to be “audit-ready” with fast, on-demand, and granular reporting.
Level Up by Integrating Mainframe Security with the Enterprise View
Each of these Zero Trust components build upon the others, incrementally improving your security posture. These strategies aren’t sequential, nor are they dependent on each other. But collectively, they represent a mainframe security “lifecycle.”
As you implement these tools and methodologies into your greater mainframe security strategy, keep your eye on the ultimate goal: integrating into the “big picture” of enterprise security. By automatically sharing security event findings, typically within a SIEM tool like Splunk, you enable a more comprehensive, contextualized view of activity across the entire enterprise. This approach enables more integrated protections and incident response processes, strengthening your overall posture.
No matter where you are in your Zero Trust journey, the most important thing is to take the next step. First you lay the foundation, then implement the necessary processes and tools to establish your Zero Trust environment. In the next and final installment of our series, we’ll explore how to iterate and continuously improve your strategy.
Read Zero Trust Deep Dive, Part 4: Coming Soon
This blog post is provided to you by Broadcom as a courtesy and is for your informational purposes only. This blog post is intended to provide preliminary guidance in forming your plans and policies. You should consult your own legal, regulatory, and security advisors to confirm that the information in this blog post is correct and applies to your specific circumstances. Any reliance you place on the information in this blog post is solely at your own risk.