How many threats hit the mainframe? No one really knows

Mainframes are the definition of mission-critical for countless businesses. Mainframes can run 1.1 million transactions per second and are at the core of the technology strategies within the worldwide financial markets. In 2017, IBM launched a new mainframe capable of running 12 billion encrypted transactions a day.

Why, despite the fact that businesses can’t afford a costly breach, is mainframe security still not getting enough attention? Like any other system, mainframes are subject to ransomware attacks, cybersecurity threats, and code-based vulnerabilities that leave them open to serious exposures, but many CIOs, CISOs and security professionals aren’t aware of these risks.

Part of the problem is that no one knows exactly how vulnerable the mainframe really is. It’s hard to put a handle around the number and significance of mainframe vulnerabilities because threats aren’t made public the way they are on other platforms.

For example, Linux has long benefited from its open community, where users can freely exchange information about the security risks they encounter. Even Windows has realized that publicly disclosing threats increases the overall security of its products. The louder you are about vulnerabilities, the higher the likelihood that customers will actually install security updates.

The mainframe community remains comparatively quiet about security. As long as vendors, customers and the industry at large continue to be unforthcoming about vulnerabilities, businesses will struggle to address the serious security risks that threaten their mainframe environments.

What exactly are those threats? At Key Resources, we’ve been tracking system integrity vulnerabilities since 2013. We’ve found more than 140 zero-day vulnerabilities, including trapdoor, storage alteration, system instability, storage reference and identity spoofing vulnerabilities. These vulnerabilities are considered proprietary information by most vendors, which makes it very difficult for companies to be proactive. Companies need to have the authority to review a proprietary vendor database, for example, and figure out which patches to apply.

The conspiracy of silence

Mainframe vendors aren’t talking about vulnerabilities, and some go as far as pushing back when threats are brought to their attention, or have excuses for not fixing vulnerabilities even after they’re informed.

There’s really only one vendor making mainframes, and they’re tight-lipped about vulnerabilities. Often, users receive a notice of an integrity vulnerability, without any description of it. Unfortunately, other vendors end up following that lead, so no one is really talking about these issues. And, companies that rely on mainframes don’t publicize if they’ve been hacked, so it’s difficult to determine the extent of mainframe exposure.

This culture – or conspiracy, if you will – of silence lulls many mainframers into a false sense of security about their systems. Mainframe security should really be treated much like any other computing system, with rigorous testing and frequent patches.

There are a couple of possible reasons why vendors don’t disclose vulnerabilities. Security costs time and money, for one. It can be expensive to fix products with security exposures that require architectural changes and which take away resources from new and ongoing product enhancements.

Vendors may also be worried about their reputation. Security expert Phil Young explained in a recent interview, “Vendors are still thinking in terms of the late 1990s paradigm where people would mock them for releasing an unsecure product. But, customers today understand that there are security vulnerabilities in everything – they simply expect vendors to own the issues and fix them.”

The reality is, trying to sweep vulnerabilities under the rug is a bigger problem than simply announcing and fixing them as they’re found.

What needs to change?

How can we break this cycle of silence? Creating an independent industry watchdog that would advocate for disclosure is a possibility, if vendors continue to drag their heels.

Ideally, though, the major vendors in this space would step up and take the lead. They can start by making it clear that they won’t punish security researchers for publicizing vulnerabilities that they discover. As Young has stated, security researchers are hesitant to talk about vulnerabilities they find because they fear potential ramifications from vendors. They need to know that not only can they research, but they can also share their findings with both vendors and users without being punished for speaking publicly.

Even better, vendors should start scanning for vulnerabilities prior to distributing new releases. They could also issue a call asking security researchers to find bugs for them. Young agrees that offering incentives is a good approach, since it would show that vendors’ goal is the most secure mainframe possible.

Many large financial organizations have already integrated their mainframe environments into their vulnerability management and risk assessment programs; including operating system vulnerability scanning.

Other large organizations use bug bounties to find vulnerabilities that need fixing. The U.S. Department of Defense, for example, works with HackerOne to reward researchers who find vulnerabilities in DoD web properties. Why not the mainframe?

Similarly, MasterCard makes their products and services safer by working with security researchers to locate potential vulnerabilities, with an average payout of $1,000. Why not the mainframe?

Implementing automated vulnerability scanning within their QA programs is one way mainframe vendors could send a message to customers that ensuring the security of their products is what’s most important. And, ultimately, that’s everyone’s goal, here – to make the mainframe as secure as possible.