For the typical mainframer, any system that does not have the letter z at the beginning of its name is not really a system worth considering or working with. Those “other” systems are widely known as “Toy Town” systems. Systems for the little kids to play with. Systems not worthy of the mainframer’s attention.
Back in the late 80s, IBM decided to transform z/OS by introducing a Unix subsystem (USS). To fight this heresy, most “old mainframers” decided to do what anyone would do and simply ignore this novelty.
I’ve been working with mainframes for almost 20 years now, and since I embarked on my endeavor as a mainframe security expert, I have had the chance to travel around the world and see the mainframe reality of many different organizations in many different countries.
During this time, I have noticed a pattern; although many years have passed since USS has been introduced as part of z/OS, the old mainframer mentality hasn’t really changed. USS is still seen as something that should not exist on the mainframe. In fact, many of these mainframers are of the opinion that “We don’t need to know how to work with USS. We don’t need USS. z/OS works perfectly fine without it.”
Unfortunately, and surprisingly, many don’t seem to know how reliant the z/OS operating system is on USS. For example, without USS, TCP/IP would not work, nor would many other major subsystems. When confronted with this fact, the old mainframer responds that “We only do what is necessary to get things to work.”
There’s really no interest in USS from the old mainframer. “Speak with the juniors, they’re kids, they should know how to work with Unix,” they’ll say.
Does this sound familiar to you? Is this the reality at your organization? Here’s the problem: Ignoring USS doesn’t make it go away. In fact, the more you ignore it, the worse the problem becomes.
The vast majority of hackers are extremely proficient in Linux/Unix systems. They grew up with Unix. They live and breathe Unix. They know it inside-out, and they also know that USS is the best way to compromise the mainframe. It’s the mainframe back door.
“Ok, but the mainframe can’t be hacked,” one might respond. This is the story that keeps being told to the youngest generations as if it was established wisdom.
“You need to be a mainframer to know how to work with a mainframe,” “old” mainframers reiterate. The reality is that this is not true. It’s just another myth. Hackers have all the resources they need (manuals, documents, videos) freely available on the internet. And as for a z/OS system that they can use to work, well, have you ever heard of Hercules?
While IBM Z and z/OS is likely the most securable platform available today, there are plenty of resources on the internet that can help enterprising hackers probe mainframe systems for vulnerabilities.
As a mainframe security expert, I do a lot of mainframe penetration tests and security assessments around the world. USS is the main area where clients consistently fail.
To me, it is clear that the old mainframer hasn’t changed mentality towards USS, and that this has created a grave security problem for the mainframe--and ultimately for the organizations that rely on the mainframe to run critical core applications.
But let’s be clear on one thing: the fault is not only the old mainframer. The problem is also both IBM and software vendors who keep ignoring the security risks that USS presents. They keep simplifying the analysis of the security risks and implications on USS for their software and take the easiest route possible: documenting in their manuals that giving UID(0)--superuser privilege--to the users running their processes is acceptable and recommended.
This cannot be accepted. Vendors should take security seriously and do their homework. The old mainframer should be more diligent, and challenge behaviors and recommendations that are too quick in taking the easy route of providing high privileged access.
There are various cases around the world where the mainframe has been compromised. However, not many have been publicized--or when they have been, it’s often under the veil of “a glitch with legacy technology.” Non-disclosure agreements prevent me from mentioning any names, but I can say this: the mainframe can and has been hacked. The number of compromised mainframes will grow exponentially in the future if attitudes with regard to security on the mainframe don’t change. Ignoring USS just makes matters worse and opens a backdoor for hackers to access and compromise the mainframe.
One of these days, could the mainframe being hacked be yours? Will you use the “USS shouldn’t be part of z/OS” as an excuse?