Historically, the terms “mainframe” and “security” have gone hand in hand, and that’s a problem. Mainframes are just not secure out of the crate. Now, if you’re a career mainframer, it’s possible your blood is starting to boil right now and you’ve already started to pen a lengthy response attacking my “inexperienced millennial” mainframe views…. hear me out.
The mainframe platform is hands down, one of, if not, the most securable computing platform in existence. RACF and other security managers give us the ability to turn, what seems like, a limitless number of knobs in pursuit of security perfection. For the purpose of this article, let’s call this concept mainframe security configuration or “the basics.” If you’re not covering even the basics well (or don’t know what the basics look like), private message me, we should talk.
Let’s assume you’re doing the basics well. You have KDFAES encryption turned on for passwords stored in your security database, APF lists are secured, program properties table has limited amount of programs (other than IBM Defaults) bypassing security, users must change their passwords every 60 days, you’re cutting SMF security events for both successes and failures, etc.
Now it’s time to take your mainframe security game to the next level. Before we go next level, let’s pause, take a deep breath, and realign the security side of our brain. I’m asking you to do something that may seem unnatural. Stop thinking in terms of security audits and start thinking like the bad guys. To help you start thinking like the bad guys take a look at the Top 10 Common Hacking Techniques You Should Know about by Fossbytes. The bad guys will do/give ANYTHING to access your systems by any means necessary.
Alright, now that we’re “bad guys” let’s talk about next level, mainframe security. It’s time to monitor and protect your systems from those modern-day security threats discussed in the article above (i.e. phishing emails, key loggers, ransomware, denial of service attacks, human error, etc) Think real-time security SMF events flowing to your SIEM tool of choice (e.g., QRadar or Splunk as an example) in addition to mainframe based Multi-Factor Authentication (MFA). This is the next level, but how do you get there?
Requirement #1 for next level - Real Time SMF Security Feeds to SIEM
If my ID has elevated security access and I unsuccessfully attempt logging into your system five times at 2:00 AM on a Saturday, will anyone know about my failures as they are happening? If your answer is no, you have a problem (I mean that in the nicest way possible!) If you don’t have my logon failure data flowing, in real time, to your SIEM tool, you have a bigger problem!
In my described scenario, there is a gap. Your security operations team likely knows my ID logged into the network, accessed the intranet, and checked email; they have no idea that I accessed the mainframe and tried to inflict pain on your organization.
Modern day mainframe security requires monitoring from the very teams that were put in place to monitor security threats on a 24/7 basis; our security operations team. Security organizations are monitoring cloud and midrange systems, they also must monitor the mainframe in the same fashion. You do not want to be the person that finds your organization’s mainframe data being discussed on the news.
Requirement #2 for next level - Multi-Factor Authentication on Z (MFA.)
According to the national Institute of Standards and Technology (NIST) MFA is a security enhancement that enables you to present two pieces of evidence – your credentials – when logging in to an account. Your credentials fall into any of these three categories: something you know (like a password or PIN), something you have (like a smart card), or something you are (like your fingerprint). Your credentials must come from two different categories to enhance security.
The most common hacking techniques (referenced above) are thwarted with multi-factor authentication as one of the first layers of defense. The hacker must have some credential other than a user ID and password to access the system. To effectively protect your mainframe, this MFA solution must be tightly integrated with your External Security Manager (like RACF) and only grant user access once your ESM and Z MFA agree that the user credentials match the credentials expected by Z MFA.
If you’re not doing the basics, start yesterday. If you don’t have MFA running on Z and protecting your Z users, start today. If you’re not sending SMF security logs to your security operations team, in real time, call your SOC team and tell them you want to partner to actively monitor your mainframe, NOW!
Look for my next article explaining why MFA on a jump server is not nor should it be considered PCI compliant. Stay Tuned!
PS: Real time feeds and Z MFA are two layers of protection that should be utilized in a modern mainframe security strategy. They are by no means, the only security layers you should be looking to implement. There are excellent reasons to include pervasive encryption and data privacy passports in your future security strategy plans.