Stepping into a Hacker’s Shoes: Why the Mainframe Needs Pentesting

Sometimes stepping into the shoes of a hacker is the only way to truly guard against them. That’s why so many organizations include penetration testing in their cybersecurity posture, with 85% of cybersecurity pros reporting that they pen test at least once a year.

But while pentesting is a common practice for networking teams, it isn’t always employed across all systems, especially not on the mainframe. In fact, when Chad Rikansrud, currently a Practice Director at NetSPI, first began working with the mainframe in the early 2000s, very few organizations specialized in testing adverse tactics against the mainframe. We chatted with Rikansrud about what was, and is still, holding organizations back from properly investing in mainframe security, what led him to drive pentesting on the mainframe, and what the process looks like today.

Introducing pentesting to the mainframe

We know that the mainframe only accounts for 6% of IT spend even though it runs around 68% of the world’s production for mission-critical workloads. What’s keeping organizations from investing in the mainframe?

Chad Rikansrud (CR): The mainframe is a huge, expensive, powerful platform that’s been around for 50+ years. Because it’s so huge, expensive and powerful, the goal for most IT teams is to regularly run the system at 90-100% utilization.

Unfortunately, security can be seen as the antithesis to utilization. As a result, security is compromised, with patches not being fully deployed for fear of causing outages or not having the ability to IPL the system. Plus, the ongoing myth of inherent security on the mainframe that so many tell quells any lingering anxiety that it could one day be compromised and cause an even bigger slow down.

Vouching for increased mainframe security measures can require a lot of awareness building. Pentesting is frequently the only thing that shakes people awake. Presenting IT and business leaders with a report of all of the ways that you as a hacker could’ve put them out of business is a pretty good way to sound the alarm before it’s too late.

How did you become a mainframe pentester?

CR: Part of my 20-year career at a large financial institution included heading up mainframe infrastructure. Malware and ransomware hit the scene during this time. First, malware was so profitable, but so complicated – find a house, break in, get what you want, get out with it before being caught or blocked. Ransomware erased a lot of those complications, making it easier than ever for criminals to profit – break in, lock all the closets so no one can access their belongings, then get paid to unlock them.

After experiencing multiple, non-hack-related mainframe outages, I wondered what it would be like if ransomware hit the mainframe. I learned that my organization’s mainframe didn’t have magic, inherent qualities protecting it from attackers. Up to that point we had really just been lucky.

I looked for someone who could test how insecure our mainframe was but learned that few firms specialized in adverse mainframe tactics. Even though I had widespread security knowledge, learning to protect the mainframe specifically became my top priority. This led me to work with the few mainframe security experts in the industry (at the time only about six around the globe) to develop a process around pentesting on the mainframe.  

What does a typical pentesting engagement look like?

CR: In short, pentesting checks an organizations’ current configuration – how they’ve set the system up and which security controls are in place.

When it comes to engaging with customers we typically work on time-boxed projects, which for just one system would take around 2 weeks. We initiate a combination of black and white box testing – black, the pentester acts a true external hacker with little to no knowledge of the IT landscape; white, the pentester acts as an internal developer with complete knowledge of the landscape.

Typically, we kick-off with identity credentials from someone in the network, which most hackers can easily obtain. After gaining remote access, we carry out the following process on each system:

Investigate: Casing the joint accounts for the bulk of the first week. During this time, we’re quietly lurking throughout the system, searching for security gaps to later exploit. 

• Plan: Develop an attack plan based on findings. 
• Attack: This could include a number of tactics, but escalating privileges is the ultimate goal. The higher we go, the greater our ability to modify the system, which packs a bigger punch than just stealing data. 
• Report: Gather our list of findings, rank their severity, share with clients and advise on how to remediate. 
• Re-test: Once changes are implemented, we test again to ensure they closed existing gaps. And since the system is changing all the time, we encourage clients to re-test on an annual or even semi-annual basis. 

But pentesting alone is not enough

Pentesting is great for challenging how the organization has configured their IT landscape and the controls in place to keep bad guys at bay, but it doesn’t cover OS-level code on the mainframe.

Unfortunately, speed and innovation tend to be prioritized over security, which is why vendors frequently introduce code that could likely be easily exploited to gain control of the mainframe. Anytime new code is introduced to the system – whether the organization is engaging with a new a vendor or there’s a routine update – there’s a chance that code has vulnerabilities. By introducing regular, automatic, vulnerability scanning, organizations can dive into the active OS-level code to detect if vendors have inadvertently opened threats through integrity vulnerabilities. Together, pentesting and vulnerability scanning form a seamless, mainframe security strategy.