Time to get back to basics with mainframe security?

by Jamie Pease CISA, CISM, CDPSE, CISSP, CITP, MBCS, Chairman of the GSE UK Security Working Group

The phrase ‘back to basics’ will resonate with some British people who were around in the 1990s. It was used by the government for a campaign. I’ve never forgotten the phrase and every time I hear about a security breach, it comes to mind. What ‘back to basics’ means is that you start giving your attention to the simplest and most important matters after ignoring them for a while.

For many years, articles and presentations have talked about the poor state of controls in some mainframe shops. Thankfully, this situation has been steadily improving, primarily driven by the demands of regulatory and industry standards that force organisations to act. Don’t get me wrong, there are still some mainframe shops out there where security is unsatisfactory. And this isn’t just a mainframe problem, other platforms and services suffer from similar issues.

So let’s get back to basics: what has your organisation been ignoring for a while?

Investing in people

You can’t have good defences if you don’t have a sufficient team equipped with the skills and knowledge needed to manage those defences. If you are still running with headcount capacity to only service business as usual, your defences will erode. Equally, if people lack skills and knowledge, how can you expect them to exploit new functions and features that reduce risk, or identify and fix security vulnerabilities that might end up in the headlines?

Standards, standards, standards

If you don’t have security standards for your mainframe environment, you have no basis for building and maintaining a secure system. Maybe you have standards kicking around that were written in the 90s but were never updated? And your standards need to be aligned with today’s corporate security policy, something that’s often overlooked is reflecting changes in security functions and features. For example, if your corporate security instructions states that passwords at rest must be encrypted with AES 256-bit encryption, your mainframe security standards should state that the RACF setting KDFAES must be implemented on all RACF databases. Standards need to be granular as they form the specifications for controls that must be implemented.

Using all the tools at your disposal

Security and compliance solutions for the mainframe have come along way. Many organisations have indeed invested in new technology, however the reality is that functions and features they introduced five or more years ago are still not being used. Many of these can to reduce risk, so why aren’t they being used? This is often down to no-one being responsible for researching those “what’s new in this release” type announcements, then documenting and planning for implementing new security features.  Still not using KDFAES for your RACF passwords or Multi-factor Authentication?

‘Not my problem’

Did you outsource your mainframe security, from user administration to system security management? I’m not a big supporter of outsourcing any Cyber Security function; too many organisations think they can offload all responsibility to a third party and forget about it. Regardless of who is taking care of your mainframe environment, your organisation is accountable so the mainframe must comply with your corporate security policy, standards and regulatory requirements. You therefore need a gatekeeper inside your organisation who really understands the subject and ensures the third party is implementing and maintaining the controls you need. It is essential that your organisation retains a highly skilled mainframe security professional, otherwise the third party has no direction, and problems can occur.

Reducing the risks

All organisations need a risk register to track and manage risks. Did you know Cyber Security budgets are often built around a risk register? It’s therefore important you ensure mainframe security risks are loaded into the register, even though the paperwork might seem time consuming. I’ve often seen high risk items in a PowerPoint or email only for them to be forgotten because they weren’t being officially tracked.  This is not acceptable: imagine if a bad actor exploited a known vulnerability on the mainframe? How would you respond to an investigator who asks why this was not on the risk register?

Don’t switch off

I’m still surprised to see mainframe shops doing little or no security monitoring. Yes, I’m even talking about no privileged user monitoring! With the regulatory demands across different sectors, doing nothing is not an option. If you suffer a security breach, investigators will want to examine your detective controls. If you don’t know where to start, invite your vendor for a discussion on good security monitoring practices.

Send in the cleaners

Many security and compliance problems are caused by the lack of a continuous clean-up. Basic examples include: not deleting userids for people who have left the organisation; unused service accounts; users retaining access (via any means) which is no longer required; forgetting to switch off default access to all users; and removing old userids from internal security tables. Regular clean-up initiatives go a long way towards reducing risk. But just like housework, you have to keep on top of it.

Going back to basics might mean something different to you, such as z/OS Security, Network Security, USS Security, and so on. Whatever your take on this, the truth is that things we ignore for too long have a nasty habit of coming back to bite us.

Jamie Pease CISA, CISM, CDPSE, CISSP, CITP, MBCS – Chairman of the GSE UK Security Working Group

Disclaimer: The views, thoughts and opinions expressed in this article belong solely to the author and not necessarily to GSE, or any other organisation.