By Reg Harbeck with Phil Young

This is part six of a 10-part series on security for the mainframe. During SHARE San Jose 2017 Reg Harbeck, chief strategist with Mainframe Analytics Ltd. and member of the SHARE Editorial Advisory Committee, sat down with Phil Young, co-founder of zedsec 390 to explore critical security topics, and offer tips and tactics to help create a more secure mainframe environment.

The war on distributed computers has been public for a long time, with viruses, trojan horses, exposures, exploits, fixes, hackers and impacted organizations having their information published as part of the rapidly progressing journey of distributed computing security.

As we have seen in this series so far, the war on the mainframe’s security has been more covert, masked by the ostensible war about the mainframe’s relevance. I say “ostensible” because the mainframe has continued to become more and more deeply-embedded and relevant to the world economy even as all the “squeaky wheel” platforms have gotten all the press with their security, performance and functionality gaps.

Now we begin to look more carefully at what needs to be disclosed, and we discover that we are leaking data everywhere, but people haven’t been looking too publicly yet.

Phil says, “To me, the mainframe is like the diesel engine that’s running the power for the building. It runs, it’s reliable. […] We have two maintenance people on shift. Otherwise, we don’t care. […] So, it runs. The only time we hear about it is when it goes down.”

One could divide mainframe data disclosures into a number of categories.

First, of course, there are intentionally public disclosures – things that everyone is welcome to know about the mainframe. IBM Red Books and product documentation are great examples of this. Not marketing, but real, useful information that the world is welcome to learn about to see how to maximize the value of this excellent platform.

Then there are private disclosures – you know, the kind you sign an NDA (non-disclosure agreement) about before you’re allowed to know them. Generally, these are strategic plans, not technical configuration details, so they don’t normally fall under the next category…

The next category is secret stuff that only insiders are allowed to know, because if outsiders find out it may be used to hack and attack you. Aka “security by obscurity.” More about this next time…

Finally, there is public information that has become an exposure over the years. You know: user IDs, terminal IDs, IP addresses, overly-informative error messages. Go to a public email list and look for who sent an email, what domain and possibly terminal and/or IP address it came from, even information disclosed in a technical question.

This last one provides the starting point for a well-informed hacker to start drilling into the mainframe, feeding known vulnerabilities and CICS transactions, etc., along with this gleaned information to scripts that then check ports, IDs, passwords, etc., in a sufficiently covert manner not to rouse suspicion while persisting at a large enough volume to have a good chance of finding an opening.

But here’s the problem: You can’t hide all that information all the time. Doing so is just another form of security by obscurity.

Which is what we’ll talk about next time.

Read part 5 - Young, the Mainframe Hacker: A Patchy SLA?.
Read part 4 - Young, the Mainframe Hacker: Pro Script Shun?.
Read part 3 - Young, the Mainframe Hacker: Inoculating the Herd.
Read part 2 - Young, the Mainframe Hacker: Young Mainframe Devolution.
Read part 1 - Young, the Mainframe Hacker: The Saga Begins.