By Reg Harbeck with Phil Young

This is part seven 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.

“When addressing server security issues, it is an excellent idea to keep in mind […] System security should not depend on the secrecy of the implementation or its components.” (NIST – U.S. Department of Commerce, National Institute of Standards and Technology – document #800-123 section 2.4, available at http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf)

Phil says, “In NIST publication 800-123, they specifically call out that obscurity cannot be part of your security plan. And that if obscurity is part of your security plan, then you will be found an exception.”

Ah, security by obscurity: that most beloved of differentiators between “insiders” and “outsiders”. If you know a secret handshake, or cultural or linguistic shibboleth of some other kind, you are allowed in. Otherwise, you must remain outside amongst the non-elect.

This is different from a password in important ways, beginning with the fact that only one person should know any given password – it’s a real secret, not merely privileged information that is shared among insiders. If you share your password with even one other person, you’ve compromised your security because someone else could act as if they were you: identity theft.

Besides that, passwords (and other secret, identity-oriented information) are not about the implementation of a system. Rather, they are the secret keys that unlock access to protected systems.

This is all very different from the implementation, structure and functioning of secure systems. While authentication details and the data and functionality they protect may be secret, the details of the systems that provide protection need to be open to professional scrutiny and validation: because eventually, hackers will find a way to scrutinize and penetrate such systems if they are not continually examined and hardened.

As Phil points out, “There is an argument to be made that obscurity can help enhance other security controls. But obscurity cannot replace security controls. So, if I have a really good crypto algorithm, I want people to look at it. Because the more people that look at it, the better it is.”

When only insiders know obscure mainframe configuration and implementation information, but you don’t know which insiders for certain, then you become just one more organization that is open to security compromise by insiders – which happens to be the main source of security exposures. And by ex-insiders, who may have any number of reasons and incentives to abuse their knowledge.

For example, think of APF (Authorized Program Facility) libraries – who is controlling them, making sure only the essential ones exist, and only trusted people with a business need have access to update them? As Phil says, “There’s nine APF libraries that developers have access to? Why? These are things you need to talk about but no one asks those questions.”

So, we need to distinguish between real secrets and implementation details that are merely obscure, and get over the illusion that obscurity brings any kind of security.

Phil says, “I have a picture on my desk at work that says, ‘This mainframe is protected by obscurity.’ That doesn’t protect you from anything. It just means that no one with the skill set has taken the time to look at it.”

But what happens when we do start looking at it? Especially through the eyes of potential (or real) hackers? Stay tuned for the next post.

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.