By Reg Harbeck with Phil Young
This is part five 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 this entry, I use a number of computer abbreviations and concepts that may not be familiar to all. I have placed a mini-glossary* at the end to make it clearer.
“I can tell you I know most corporations have an SLA* for critical patches* in Windows.* It’s probably 72 hours. Or maybe 90. […] Some places, it’s 12 for critical...”
“If a critical vulnerability comes out for the mainframe and that APAR* has a CVSS* score of 10, that should be in production within the same amount of time as a production vulnerability for Windows.*”
Yeah, right. How about six months, after it’s no longer bleeding edge, and we’ve tested it on the sandbox*, and then set aside a weekend for an IPL* with a backout plan?
What do you do when our mainframe legacy culture, which is tried and proven and works, meets urgent needs to fix things before hackers start making inroads to the mainframe with a newly-discovered critical security exposure?
In many ways, this is one of the key issues that need to be dealt with to keep the mainframe functional as the world-wide tsunami of security vulnerabilities and hackers begins to leak into the mainframe castle grounds.
After all, to quote Phil again, “Even though you’re told your entire career it’s different, even though it gets a special pass on security controls, even though it’s written in COBOL* and PL/1* and REXX* and CLISTs* and Assembler*, it’s just a computer.”
Because, proving the security of a distributed computer means, “Oh, okay, so you stopped some hacker from getting into your Linux* box.”
But, “The entire company’s fortunes live-like how long can a company live without their mainframe?”
“How long-if their mainframe goes down, how long can they literally stay in business?”
“Like it’ll be an hour before it makes the local news.”
“It’ll be two hours before it makes national headline news.”
“It’ll be three hours before it ends up being on the nightly news.”
“And four hours, we’re talking about congressional investigations.”
“Like once you start hitting overnight...”
But what can one or a few people – however vocal – do about it?
“I spoke at CA World and met up with some people from [big mainframe company] and they were having a discussion, and they said what I’m doing is grassroots. And they’re absolutely right. What Chad [Chad Rikansrud, @BigEndianSmalls on Twitter aka Big.E.Smalls – a fellow mainframe hacker] and I do is a grassroots effort to raise awareness about the security or lack of interest of security in the platform.”
To illustrate, “Someone found me on Facebook and told me what I’m doing is not hacking. All I’m doing is finding misconfigurations. And I had to explain to them that, “No. Hacking is finding situations where people have made mistakes, and taking advantage of those mistakes.””
In other words, people make mistakes, hackers find those mistakes, scripts employ those mistakes. But what once was just sharing appropriate information can become a mistake once an exploit exists that uses that information.
You know, information such as… but we’ll save that for next time.
*Mini-Glossary:
APAR: Authorized Program Analysis Report – a patch on a mainframe system.
Assembler: A text-based expression of a computer’s natural “machine language” that allows programmers to directly tell acomputer such as the mainframe what actions to take without having their program translated by interpreters or compilers. This is most commonly used for systems activities and other very technical functions. Each different computer platform has a different machine language, and therefore a different Assembler.
CLIST: “Command LIST” – a simple mainframe interpretive language that allows for scripts to be written to perform basic actions such as setting environmental values at logon time.
COBOL: “COmmon Business Oriented Language” – a computer programming language that has been in use since 1959. Many of the applications that run the world economy on the mainframe (and other platforms) are written in COBOL.
CVSS: Common Vulnerability Scoring System – an official metric describing how severe a security vulnerability is, where 0 is no risk and 10 is extremely high risk.
IPL: Initial Program Load – what you do when you “reboot” (i.e. restart) a mainframe.
Linux: A basic operating system originally written for an Intel x86 personal computer hardware platform that is now also available on many other platforms, and has been available on the mainframe since 1999.
Patch: A small modification made to a larger program or system in order to correct an erroneous behavior.
PL/1: “Programming Language 1” – a computer programming language that has been in use since 1964. While not as pervasive as COBOL, it has been used on the mainframe and other platforms and is considered to be a direct or indirect progenitor to many other languages, possibly including C.
REXX: “Restructured EXtended Executor” – the premier interpretive language on the mainframe, it had its origins on a simple scripting language on the mainframe, which was improved and then completely redeveloped to create an outstanding language with many flexible features for writing systems, automation and applications programs.
Sandbox: A special mainframe environment set aside exclusively for testing software and configurations to ensure they’ll function properly before making them available in a live production system.
SLA: Service Level Agreement. An agreed description of the quality and timeliness of service that will be provided to a customer organization (e.g. by the IT or Information Technology department or outsourcer).
Windows: A graphical environment for consumer electronics such as Intel x86 personal computers and some models of mobile phone that includes operating system features.
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.