Raising our game: making identity management and SIEM work for the mainframe – Part 1

Are we taking modern security on the modern mainframe seriously enough? I don’t think so.

A while ago, I asked a mainframe shop why their identity management solution was hooked up to the majority of their platforms—except for the mainframe. I was told, “Oh, we heard there were scalability and reliability issues.” This was pure hearsay: nobody could tell me the source. They hadn’t actually installed it on a test system to verify. I pointed out that we had a regulatory issue and audit problem to solve, and this was a way to do it. Why didn’t we try a proof of concept, I asked. We did. It worked. There was a few teething problems, but this was more about a perception about it being difficult and overly complex to achieve rather than the reality.

Increasingly, the first port of call for internal and external auditors looking at controls for mainframe applications is the identity management solution. Assuming it will be a central point of control and visibility, they want to see who is on the system and has access to what, so they can start their checks and assessments. Basic housekeeping. But they will most likely be disappointed.

That’s because of something I still see regularly in my professional practice: the mainframe operating in silos. From a security, governance and compliance perspective, that means it’s not hooked-in to identity management solutions when most other platforms are. The mainframe is entirely or partially absent. The same goes for privileged access management (PAM) solutions, and security information and event management (SIEM) solutions like Splunk and IBM Security™ QRadar®.

Including the mainframe in such tools is vital to gain the visibility needed right across the user estate. As a client said to me recently, hooking up the mainframe to the identity management system ‘would give us really good visibility of privileged users and all those different levels of access.’

In this day and age, would you leave a Windows server or Oracle database exempt from identity management and security monitoring? The mainframe is a production server. In fact, it probably handles more critical data than most other platforms, which you wouldn’t dream of exempting from proper governance, so why do it for the mainframe—given its profile and what it actually does for the business?

I see two main strands. First, not using these tools at all or not properly connecting them to the mainframe. Second, gathering information and perhaps even sharing it, but the people at the receiving end don’t understand and are unable to act on the insights gained. How did we get to this place?

For some mainframe shops, making the right connections can be beyond their in-house technical capability. In which case, get external advice or find a third-party software product to smooth integration. Trying and failing because you didn’t have the support or resources needed is not a reason not to do it. Some people may have also been burned by a connector that simply doesn’t work with the mainframe; a vendor may have over-egged certain capabilities or ease of integration. In which case, go back to the vendor and tell them, or ask an independent expert for help.

I also hear people saying there’s too much ‘rubbish’ in the security database, whether RACF, ACF2 or TSS, so it’s not in a good enough state to feed into an identity management solution. But that’s a rubbish argument. Wouldn’t it make sense, as a starting point, to get that stuff visible so you can see what it’s like and start to act on it? A co-worker once said, “Let’s get the dirty laundry aired and it will get attention!”

Another push-back from the mainframe community is people saying “Even if we sent user behaviour events to the SIEM, no one at the receiving end of Splunk or whatever understands it.” My response is, again, that’s not a valid reason not to do it. It’s a process and a culture issue, solved by user training, and by having strong automated processes that trigger an alert for someone to investigate or take further action. Can you risk not doing it?

There’s also that persistent sense of complacency: the mainframe has always been considered secure. But that’s no longer the case. Some mainframers may still feel they are separate from the rest of the enterprise and, perhaps, in some way special. That is no longer true. We are now at a point where the mainframe simply has to be hooked-in to these enterprise-wide security solutions.

Outside the mainframe bubble, the platform can also be little understood and still seen as legacy, sunset technology. The perception is that it’s ‘just too complicated’ to hook up to identity management and SIEM solutions. But it’s more than possible. I was involved in a project to help an organisation to integrate its identity management solution with the mainframe, and their SIEM. The benefits are enormous, from provisioning and deprovisioning onwards.

In the second part of this blog, I’ll share a few experiences in making the right connections for mainframe security, and explain the importance of getting business-facing teams and technology teams on the same page, speaking the same language, and overcoming those silos.

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.