“At least that could never happen on the mainframe, so my bank account, tax information, insurance policies and other critical data are safe.”
If you’re a mainframer, this may have been your initial thought when hearing about the latest malware attacks such as WannaCry, which encrypts PC-based data and holds it for ransom, decrypting it only if the ransom is paid in a timely fashion.
You may have even bragged to friends and family about how secure the mainframe is by comparison, and then had to try to explain why when they challenged you. Perhaps you referred them to the IBM z/OS System Integrity Statement
And it’s fair to tell the world that the mainframe is safe from such attacks, just like it’s fair for the makers of quality hot dogs or sausages to assure you it’s OK to consume their product without telling you the details about how they’re made—as long as they know the details and make sure it stays that way. You and I, along with IBM, are the mainframe sausage makers, and we need to be aware of those behind-the-scenes details to make sure our environments continue to “meat expectations.”
That means having a more exact understanding of why a properly configured mainframe environment is not subject to salient weaknesses. Shining a light onto these types of issues will bring some of our greatest potential exposures into view. It’s up to us to make sure our mainframe setup, maintenance and configuration can take advantage of the IBM z Systems platform’s security capabilities.
To illustrate the importance of keeping our mainframes properly maintained and configured, let’s look at a few weaknesses that distributed computers have, and how the mainframe can avoid them.
Insufficiently Secured Application and User Data
Application data shouldn’t be available for update by any means other than using authorized IDs through specified programs. If update access to your production data is available to any user, no matter how trusted, without forcing them to use appropriate programs, they become a potential exposure. Take a look at your security and make sure there isn’t update access to any of your most critical application data available to any user that might possibly run any program other than those associated with the application using the data. The principle of least privilege is appropriate here, which dictates that you should have no more access than absolutely required to perform your job.
In addition, user data can include configuration data and source code. While typical users usually can’t download and run malware on their mainframe accounts, many applications and systems personnel have access to online environments (e.g., TSO/ISPF and CA ROSCOE), where they can execute programs that haven’t been vetted through change control and related security processes. They might also have access to such data through a PC-based development environment. If so, it’s important that formal processes for modifying application programs along with application and configuration data are strictly followed so that rogue programs can’t do a mass update or encryption of it.
The Need for Protection In-Depth
In the distributed world, protection in-depth means layers of security (e.g., firewalls, anti-virus software, access control lists). Email and web content inspections are now also essential to limiting exposure.
We have not encountered any viruses on the mainframe. However, while viral attacks compromising many mainframes seem very unlikely given how secure they are, it’s still possible for someone on the internet to find a way onto your corporate network and look for ways to pry into your mainframe. When improperly secured, UNIX System Services, Java, open TCP/IP ports, shared DASD, remotely submitted batch jobs, unsecured CICS transactions, users with guessable passwords and production IDs with known or no passwords are all possible vectors of invasion.
It’s also important to make sure you can explain and identify every authorized program facility (APF) library on your z/OS system along with who has update access to it. For bonus points, find out if there are any duplicate program names across multiple APF libraries and why.
Once these common vectors into systems have been secured, there’s the issue of proper configuration and maintenance. After all, even mainframes and their operating software are made by mere mortals, excellent though they may be. And we all make mistakes.
This means staying on the lookout for undiscovered exposures that can arise from misconfiguration, programming errors and even local systems programs that have been in use forever without anyone thinking they might have gaps.
The first line of attack here is to keep a lookout for bulletins from IBM, ISVs and other contributors to your mainframe environment. You should also get any emergency fixes through your testing and change control process and move them into production as fast as your policies will allow.
You also need to stay current with new configuration options for your environment. The way our systems and other software were configured when first installed hasn’t changed much over the past few decades, while new and more secure options often render these settings obsolete.
For that matter, many in-house programs were written when mainframe software was in its adolescence and didn’t have the full, rich functionality now available out-of-the-box. Those programs are often redundant to more secure and functional alternatives available in software you’re already paying for. As a bonus, this is a good opportunity to get your new mainframers up-to-speed on your environment by having them hunt down and recommend replacements for obsolete and insecure homegrown programs.
Know Thyself—and Thy Backups
Some of the most important principles for quality computing were first invented on the mainframe, from security to integrity to virtualization. That also includes backups. The average mainframe environment is fully and regularly backed up, and even tested for an emergency restore one or more times per year. This is a significant advantage over the vast majority of distributed environments where a full disaster recovery restore test has never been successfully completed.
However, if your data has already been corrupted by malware or encryption and you don’t know it, you may actually be backing up junk. This is a real possibility, so as you seek to ensure the security of your mainframe environment and data, it’s very important to be aware of any abnormal changes to your data, programs or configurations.
The better you know your environment and which programs regularly modify which data, the more likely you are to uncover exceptions. As professionals, we need to learn our environment well enough to recognize when something isn’t quite right.
Back to the Grind
At the end of the day, it’s up to us as mainframe professionals to beef up our environment’s security to keep our employers out of the frying pan and far from the fire. Just because the mainframe’s capable of solid security, doesn’t justify hot-dogging until we have to catch up. It may not be a picnic, but the chips will be in our favor as long as we turn up the heat on potential exposures.
Reg Harbeck has been working in IT and mainframes for more than 25 years, and is very involved in the mainframe culture and ecosystem, particularly with the SHARE Board and zNextGen and Security projects. He may be reached at Reg@Harbeck.ca.