Hacking the mainframe

The editor of a leading mainframe magazine, z/Journal, asked me to research vague reports on hacking mainframes. The effort turned up one small company, Net’Q, claiming that hackers could break into mainframes and it promised a solution.

A subsequent Net’Q briefing laid out the details of how such an attack would take place. Essentially it involved:

  • Spoofing a user during a VTAM session.
  • Connecting to a second mainframe via APPN
  • Create a rogue applid

And you still have to get VTAM to accept the session as valid, and on and on. (Although I write considerably on security and understood the problem Net’Q outlined, I’m not a security geek.)

To bolster the point Net’Q insisted it had customers who had experienced the VTAM spoofing attack. Those customers, however, declined to speak with me on the record. They probably had good reasons, such as not publicly admitting a security breach, which could have serious corporate ramifications.

Hacking the mainframe is a perennial question, and as IBM opens up the mainframe to more and more unconventional workloads, such as SOA, Web 2.0 applications, mashups, business intelligence, mobile access and more, concerns about hacking persist. If nothing else mainframe data center managers increasingly have to trust external systems to authenticate users. So, hacking remains a possibility.

Net’Q could be absolutely right, but without either speaking on the record or providing evidence documenting the attack what more was there to say. Furthermore, when I brought the subject up with IBM’s security people, they insisted they had thoroughly reviewed the data Net’Q provided directly to them and they could not reproduce the problem. The story died right there.

But the question of hacking the mainframe continues to come up. In one of the most active System z discussions I’ve participated in on either Facebook or LinkedIn, hacking drew more responses than usual. It started with this question: Would you know if your mainframe has been hacked? You can see the entire discussion here. (If you have to become a member of LinkedIn to participate, go ahead and register. It’s free and painless.)

My contribution was pretty much what I recounted above but in less detail. Other participants pointed out a variety of obstacles any would-be hacker would have to overcome to be in a position to do any damage.

Just sneaking onto the mainframe isn’t much of a hack, certainly nothing to boast about, if you can’t see or do anything. That’s where the real damage lies.

Now, however, is not the time to get complacent about mainframe security. The opening up of the mainframe to new workloads and to outside partners requires mainframe managers closely review security.

And still there are security threats that even the best mainframe security tools can do little about, such as losing a cell phone onto which confidential CICS transaction data had been loaded. People lose Internet-capable phones all the time, and most are not encrypted or even password protected.

One Response to “Hacking the mainframe”

  1. How Secure is your System z « DancingDinosaur Says:

    […] myself have researched claims of security flaws in the System z and reported the results on this blog [see Hacking the Mainframe, Mar. 29] and come up with little of substance. But is it really […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: