Each day, mainframes are powering the world’s banks, healthcare systems, government institutions, and more, processing millions of transactions a day. It’s no wonder, then, that security remains a hot topic not only for the industry, but for SHARE events, as well. Coming up at the semi-annual conference, held in St. Louis from August 12-17, we’ll hear from security experts on topics ranging from hacking and the dark web and pervasive encryption, to mainframe vulnerabilities.

Ray Overby, president and CEO of Key Resources, Inc. (KRI), will be on hand to speak about one type of vulnerability in particular: code-based vulnerabilities. We spoke to Ray to find out what he has in store for his presentation in St. Louis, and to hear what he thinks about the state of mainframe security. You can register for SHARE St. Louis here.

Could you describe your background in mainframe? How long have you been involved with SHARE?

I started attending SHARE events in 1983, and I was a ribbon-wearer for the security project for four years. I have been writing system-level intercepts in Assembler and Basic since 1982, including eight years as a developer at SKK, Inc., specializing in CA-ACF2/MVS. I started Key Resources, Inc. in 1988 and have specialized in mainframe security since the inception of the company. I am one of a few individuals who understands and has written software that interfaces directly with the three ESMs.

At SHARE St. Louis, you’re participating in a panel discussion about the z/OS security portal and mainframe code-based vulnerabilities. Can you explain why this is such an important topic to cover?

Corporations have very sophisticated risk management systems, organization and policies. The teams responsible for risk management within these corporations have been given the task of meeting compliance guidelines (like PCI and GDPR) and laws that require them to determine the criticality of a vulnerability and report and track all vulnerabilities within their systems.

In many of the organizations I have talked to, the risk managers aren’t aware that mainframes have code-based vulnerabilities. Though of course there are exceptions, I have found that the risk managers I have spoken with are left in the dark. That means their systems could be out of compliance and they could be held accountable if one of these vulnerabilities is exploited.

In my session at SHARE St. Louis, I’ll talk about the z/OS architecture and how the IBM Integrity Statement impacts security on the mainframe. I hope to explain why the operating system layer can be hacked and the severity of the vulnerabilities that KRI has found. I want individuals to understand that third-party vendor code is often written poorly by individuals who do not have the proper training to write integrity-based code, and to understand how internal QA departments do not do a good job of thoroughly testing their software.

What are your thoughts on the current state of mainframe security? Do mainframe pros take it seriously enough? Are there any industry blind spots or shortcomings they should be aware of?

In my experience, some of the top decision-makers are overlooking the security of their mainframes. Part of the challenge stems from a common misconception that security products like RACF, CA Top Secret, and CA ACF2 provide everything they need. However, even though those security products provide authentication and authorization to mainframe applications and data, they do not protect systems software from malware and ransomware attacks.

When it comes to dealing with code-based exploits, mainframers need to understand that they are largely on their own. On the distributed side, the Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. But nothing like this exists on the mainframe. Everyone is on their own and everyone, especially the CISO, has to begin to take responsibility.

What do you hope attendees walk away with from your session?

My intent is to raise awareness that vulnerabilities do exist on the mainframe. I also want attendees to understand that IBM and third-party vendors have very specific processes for reporting mainframe vulnerabilities that are completely different from how distributed vulnerabilities are handled. That means they need to understand the reporting of and resolution process used to fix vulnerabilities.