By Reg Harbeck with Phil Young
This is part four 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.
In the previous blog, Phil Young suggested inoculating the mainframe ecosystem as an effective security strategy. And getting the word out, for example with this series, is a part of making that inoculation happen. There are other parts, of course—including strategies for waking people up to the dangers, and strategies for producing what might be called a “live vaccine.” Let’s start with some initial consciousness-raising:
Have you ever received a fake phishing email? You know: those ones your organization’s corporate security puts together to look like a phishing email—one designed to steal your identity and other secrets and accesses—which is actually intended to safely teach you not to open and click on them by directing you to an educational warning page instead?
Is your head spinning, just a bit, from trying to unwind that concept? Unfortunately, in the world of immune systems, including corporate IT security immune systems, multiply recursive indirection is a fact of life. Good luck getting someone with an agenda of simplicity to vote or budget for such an approach. You may as well try explaining the structure of SMF (System Management Facility – mainframe performance, accounting, chargeback, etc. data) records to them.
And yet, as mainframe professionals, we need to understand that mainframes aren’t exempt from this kind of thinking when it comes to keeping the world’s most important data and processing secure.
On the upside, the good news is that hacking the mainframe isn’t simple, and so far, there are no simple tools that allow you to run a script on a random mainframe without any additional information and hack right into it. You need to do some personal investigation as well—so far.
On the downside, the insights needed to bridge the gap and start the hack don’t require you to learn to be a systems programmer. However, knowing a bit about the structure and behaviour of the mainframe still makes a difference.
Or, as Phil Young puts it, “The scripts aren’t going to be able to walk through. Like it’s not point and click. Right? You still have to do some work. You still have to kind of understand what VTAM is, before you can use like the VTAM enumeration script.”
But, there are scripts. It’s just a matter of getting key information for them to start with, and knowing how to use what they find out.
What kind of key information? How about mainframe User IDs and terminal or IP addresses?
And once you have the information to feed the scripts, how do they work, and what can you do with the results? If you’re using this as a “live vaccine” you’ll want to make sure the right people find out, in the right way. If not…
But we’ll dig deeper into that next time!
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.