The mainframe conundrum

It would have been nice to get Web 1.0’s security fixed first before starting on Web 2.0. And before Web 1.0 was … the mainframe.

In my time with health care providers, at one of the world’s largest telcos, at various largish Australian banks, and over the last few weeks teaching mainframe folks about secure coding techniques, I’ve come to a conclusion: we’re in a crisis. Not only have we not really solved the necessary problems in Web x.0 land, we haven’t been keeping an eye on the ball in the most important area of all: where the value lies.

Critical nationally protected infrastructure all use mainframes to process the value of our lives:

• Banking (money – a necessity, which allows you to buy housing)
• Logistics (getting stuff from A to B)
• Defense (making sure we’re protected)
• Food chain (eating – a necessity)
• Government (unfortunate necessity)

Pretty much covers Maslow’s Hierarchy of Needs in every way – modern life would not be possible without mainframes. We cannot:

• house ourselves (buy houses with a mortgage),
• eat (we no longer farm or hunt ourselves and rely on getting access to food at supermarkets (who use mainframes to keep stock levels and understand what their customers are buying) which requires shipping – and most large logistics firms use mainframes for everything from load optimization through billing and scheduling
• or even get water depending on your water utility.

I look back wistfully at seminal security papers and works from the 1960’s and 1970’s. I feel miffed that this 40 year head start has been squandered. Almost everything we’ve “discovered” in web application security is old news to these researchers. Their programmer contemporaries are still out there, building mainframe apps, and they do not know anything about the old research, let alone the new. “Web apps? Not my job, governor!”

Today’s mainframe devs do not know the core principles – confidentiality, integrity, and availability (except for performance reasons). Key security principles such as defense in depth, complete mediation, and validation are no longer practiced, even though the old code lived and breathed it.

In my discussions with mainframe devs, they struggle with basic security concepts, and even in some cases, the need for security at all. After all, the attackers know nothing of the mainframe and they can’t get on to the system. Right?

In the end, the fault partially lies with the application security community. We in web application security know no mainframe stuff. I don’t know anyone competent to review COBOL, RPG, PL/1, IBM assembly language (!), or a host of 4GLs. I don’t know anyone who knows a jot about RACF, ACF2, and all the security mechanisms available on mainframes since before I was born.

Very few know anything about TPF, MVS, z/OS, CICS, and VM. And yet, taking even one of these – TPF – could reward study for years. It powers all the airlines, the travel industry (Galileo, the world wide booking system used by everyone who travels, is a TPF application), and even 911 emergency response systems. And yet, I must admit I’ve never heard of it until last week, and yet I’ve worked around folks who used mainframes for the last 15 odd years. What chance does that newbie .NET coder who needs to have a secure ordering system involving a mainframe as a backend? We have no advice.

So we can’t properly review applications that use mainframes … except to treat them as black boxes. And that is wrong! Most large organizations have a 30-40 year investment in their applications and they’re not going to re-write in a Johnny come lately language like Java or C# just because we can’t review old code. There are literally billions of lines of COBOL out there, and it … runs the world. There should and MUST be a way we can review this code.

What needs to happen in the security research community?

We need to research the security concerns in commonly used mainframe languages (COBOL, RPG, PL/1, assembly) on top of common platforms (z/OS, others) using their common data stores (DB2, and so on). We will break old/new ground here. Probably this stuff was being thought about back in the late 70’s early 80’s, but was never published. I think our field’s brightest researchers simply stopped looking at commercial environments around this time.

We need to understand their native toolsets to provide key security architecture deliverables, such as using RACF to provide authC and authZ services. The mainframes have a rich set of security tools… but no one uses them any more.

We need to become competent in reviewing these older systems and applications, so we can provide reasonable advice

We need to be choosy about what to review – there’s simply so much code at every large firm and government agency and basically no one to review it

Although OWASP should be publishing the results of this work, maybe we as the security industry should have an extended residency with the IBM Redbook folks to get access to the real deal (do you have a mainframe?), peer review our work, document all our findings and get it back in the hands of the mainframe devs in a timely fashion.

What needs to happen on the mainframe side of the fence

Business requirements should reflect in the security architecture. We know that mainframe has almost all if not all of the necessary support of a “modern” security architecture:

Data protection

• Confidentiality. Most mainframes have an inbuilt HSM. Few sites are using this feature! What a waste. Let’s get this out there and encourage the use of hard core encryption
• Integrity. Most of the protocols in the SNA stack have inbuilt integrity controls, and yet once they are mated to TCP/IP, the common protocols such as ftp, x3270, and access to MQ is all unencrypted and has no integrity controls. This needs to change

Identity management

• RACF is basically as old as me. It supports everything a SSO vendor would happily sell a Java site and has done for over 30 years. It now supports modern pass phrases, LDAP support, and so on. These “advanced” features should be in use at more sites.

Event management

• I still need to do more reading, but I can’t imagine that the systems which power banks has no audit or logging features. Let’s learn how to differentiate between logging and auditing, and ensure these logs are protected from unauthorized use.

The folks on the mainframe need to understand the powerful tools and native platform support they already in their possession. This requires training and support from their vendor. IBM? Hear me.

We in the security research community can’t possibly understand every possible version of every language and platform out there. It’s time to start consolidating around a few common platforms and languages. I propose the security industry sticks to supported platforms and languages as IBM has a chance of rectifying any problems we find.

This will be painful for many, but it’s like the pains the accounting industry went through in adopting the GAAP. We can’t and should not audit a planet’s worth of loose receipts.

I am not hopeful that any of this will change any time soon. I am willing to have a dialog with any and all mainframe folks. Let’s talk.