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.

Author: vanderaj

Just another security geek

2 thoughts on “The mainframe conundrum”

  1. I think part of the problem is that to address these issues you have to spend some dollars/effort on fixing the code/design. You could just as easily spend that some effort on creating a new system which is much more maintainable.

    The trend at the moment seems to be inbetween – use mainframes to massively parallel VM’s running ‘modern’ operating systems.

    But yes, there is a belief that the mainframe is immune to almost anything….

  2. I have done a little bit of Mainframe security work, and it was quite an eye opener!

    The problem with getting security folk skilled up on mainframe tech is the lack of availability (i.e. lack of access to a sandbox area where a newbie to the field can explore, learn and test things out).

    I certainly agree with your assessment of the problem. One banking client that I did work for had a big DB2 installation on their mainframe. Until this particular project, all access to the DB2 instance was from within the mainframe itself, using supposedly trusted code, and supposedly trusted users (i.e. only folks with TopSecret (=~ RACF/ACF2) logins). The problem was that now they wanted to allow an external app to use the mainframe’s DB2 as a backend, via a JDBC connection.

    When I checked the table permissions, I found that there were approximately 20000+ tables with PUBLIC SELECT access defined on them, and several thousand with PUBLIC INSERT, UPDATE and DELETE access allowed. And they had no idea why, or which applications were using those tables, as which user. Which meant they could not fix the permissions. Even adding auditing to the tables to identify users would have impacted performance too much, and was dismissed as an option. So it was left as is, but now with external access allowed, so that people could start digging around. Nice, eh?

    Another audit I did at a government organisation was equally inspiring. All users are given a menu which comes up after they login, and they are only able to run programs that appear on the menu. Supposedly. Oh, yes, except for the “escape code” that you can type in which would give unrestricted command line access. Which the sysadmin knew about, but didn’t think any of their users would know anything about. Nobody thinks about organised crime deliberately planting someone in a low paying job in order to get access to terminals and access credentials.

Leave a Reply

Your email address will not be published. Required fields are marked *