By Reg Harbeck with Phil Young
This is the conclusion 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.
As we conclude our series about mainframe security and hacking, Phil talks about the people at mainframe organizations who need to be doing something. But who are the people that need to do something, and what is their current behavior?
Phil:
I wouldn’t say current IT security leadership or ignorant; I would say they’re just ill-informed.
Take for example a typical CISO [Chief Information Security Officer]. They graduated in the ‘80s or ‘90s. At that time in college they were likely told the mainframe was dying. So, they don’t know anything about the mainframe, why would they?
Today’s CISO are bombarded about all these bad things happening in their environment. They hear about how the Windows cluster’s gone down again because of some ransomware. They hear about how Linux vulnerabilities have spiked and an emergency has been declared because of STRUTs being attacked in the wild, and the mainframe is just sitting there. Quietly processing every transaction and making money without fail. The only time you’ll hear about the mainframe is when it goes down.
A lot of places I’ve been, the ownership for the security of the platform has rested within operations. Oftentimes IAM [Identify Access Management] might be implement within IT Security, but the ownership of writing and implementing security (compliance, patching, etc.) will be owned by the operations group.
Most enterprises have these massive staffs of risk assessors, penetration testers, and auditors. These individuals do penetration testing, risk assessments, audits, gap assessments. All those people, if the applications that they care about are residing on the mainframe, they should probably be as well-versed in it as they are the other platforms. Unfortunately, those jobs require people to be a jack of all trades. Since Windows and Linux are far easier to get audit guides for, information about, it makes sense that the security review processes for those platforms are more mature. The people who are testing and reviewing the platform [mainframes] security are just not as well versed in it as the others. Basically, you don’t know what you don’t know.
Here’s how I framed when Chad [Rikansrud] and I spoke recently at RSA: Ask yourself what is your downtime threshold for the mainframe? How long can you go without it? Is it minutes? Some places I’ve been, it was 60 seconds. They could go 60 seconds with the entire mainframe environment down. After that they would start losing money. In the case of a security breach causing such an outage (say they corrupt a database that then gets replicated across the entire environment) the CISO is the one ultimately responsible but I don’t believe they know they are responsible. They’re busy dealing with Windows and Linux problems.
In my opinion, it’s just a matter of time before a Logica type event happens in the US. But todays bad actors aren’t going to take your mainframe down, at least not on purpose. They’re going to inject code in to a CICS transaction to syphon funds, or encrypt all the datasets in your replicated environment to demand a hefty ransom, or steal confidential information to later sell on the darknet. Todays threats are sophisticated and they are aware of the platform [mainframe], they’ve just been able to target lower hanging fruit.
I have a three-pronged approach to mainframe [security] awareness. (1) I speak at IT security conferences so I can teach the people whose job it is to do penetration testing how to do their job on the mainframe. (2) I speak at audit conferences and audit conventions so that auditors know how to effectively audit the platform without the need for checklists, or at the very least, so that they know what the checklists are actually checking. And finally (3) I speak at mainframe conferences, most recently SHARE in San Jose, so that I can make the people who are responsible for the day to day mainframe operations know that the platform isn’t impenetrable.
The key for me, is that enterprises need to stop treating it as a special platform and need to start treating it the same way they treat the rest of their critical systems. With the same controls, same timelines and the same SLAs [Service Level Agreements, commonly used for patching]. I believe that if mainframe is treated no differently than other platforms it will benefit the overall health and security for everyone who uses it.
And with that, we shook hands and agreed we all need to keep working together to wake up the mainframe community and the rest of the world to this important platform and its security issues and implications.
To keep current, here are three people you can follow on social media:
Phil Young, aka Soldier of Fortran:
linkedin.com/in/mainframed767
mainframed767.tumblr.com (Blog)
twitter.com/mainframed767
Twitter: @mainframed767
Chad Rikansrud, aka Big Endian Smalls or Big.E.Smalls:
linkedin.com/in/chad-rikansrud-233b1677
Twitter: @BigEndianSmalls
Reg Harbeck, Chief Strategist at Mainframe Analytics ltd.
MainframeAnalytics.com
linkedin.com/in/regharbeck/
twitter.com/RegHarbeck
Twitter: @RegHarbeck
Read part 9 - Young, the Mainframe Hacker: Tools and Rules.
Read part 8 - Young, the Mainframe Hacker: Breach Combers.
Read part 7 - Young, the Mainframe Hacker: Ob-Sec-urity.
Read part 6 - Young, the Mainframe Hacker: Public Disclosures.
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.