As a consultant for Technology Expert Labs (TEL), formerly IBM Systems Lab Services, I have been helping clients assess and improve their security posture. I have heard many times that the mainframe is "special" and does not need the same level of attention as other platforms because it is already "secure."  I even heard from a mainframe domain manager that mainframe did not require a security policy.

Many believe the myth that the mainframe is inherently secure. Here is the truth: The mainframe is not secure by itself, but it is one of the most securable platforms. 

To properly secure your mainframe, you must do your homework and identify your mainframe assets and how they interact in your enterprise ecosystem. Maybe your mainframe feels very secure, but what if another platform connecting to your IBM Z LPARs has weaknesses? You may be the next in the list to appear in the ITRC list of hacking victims.

The identify function involves identifying who is connecting to your infrastructure and how the traffic is encrypted.

Since version 2.3, z/OS has been equipped with zERT ( z/OS Encryption Readiness Technology). Enabling zERT allows you to identify who is connecting to your LPARs and which encryption algorithms are being used. If you plan to use stronger network encryption, zERT enables you to identify all connecting servers that will need to support this stronger network encryption ahead of time, avoiding unplanned outages. 

Since z/OS 2.4, zERT can also enforce a connection encryption policy to ensure that non-secure connections disclosing data or credentials are no longer permitted.

Data breaches seem to dominate headlines these days, and mainframes aren't immune. Some years ago, I worked with a “breached” z/OS client. Stolen credentials allowed unauthorized access—a situation multifactor authentication (MFA) could have prevented.

While specific security frameworks might not mandate MFA for your z/OS TSO users, it's not just a compliance checkmark. Consider the widespread adoption of 2FA across platforms and its impact on security. Adding this extra layer of defense could be your mainframe's last defense shield against cyber threats.

Think of it this way: even the strongest password can be compromised. But with MFA, even if someone steals your password, they still need that second factor (like a code from your phone) to gain access. It's like adding a padlock to your already locked door—an extra layer of security against unwanted intrusions.

And don’t forget about pervasive encryption, which is still relevant today. Using z/OS data set encryption brings another layer of security, ensuring that your most important assets—your data or your client’s data—are still safe, protected by a strong encryption algorithm even if a breach occurs. 

The world is changing, and the battle against hackers is no longer against humans only. The hacking world is rapidly adopting AI and adding new weapons to their arsenal, creating a new and escalating threat to your valuable assets.  Fighting against AI powered hacking requires a better response.

That's why fast threat detection is more crucial than ever. Security intelligence, monitoring and reporting should be your top priorities.

We're ahead of the curve with the AI-powered Telum processor in the z16. It's already being used to detect banking fraud in real time, and soon, it will be your shield against AI-wielding hackers.

But you don't have to wait for the future. Start by instrumenting your mainframe logs and implementing robust monitoring and analysis. There are many solutions to monitor z/OS security-related events and alert you of detected threats. Sending logs to a data analytics solution is also paramount to detect changes in trends. 

Even if you begin with non-AI solutions, be prepared to embrace the future. Exciting advancements in AI-powered mainframe security are right around the corner. 

The respond function of the NIST Cybersecurity Framework emphasizes the importance of being prepared for cyber incidents. This includes having a response plan to:

1. Quickly identify the source of a breach. Use your detection capabilities to pinpoint the attackers, entry point and affected systems.
2. Seal the breach. Take immediate action to contain the incident and prevent further damage.
3. Improve. Develop short-, mid- and long-term plans to rebuild your defenses and strengthen your security posture.

On the cryptography side, as a z/OS crypto expert, I'm surprised to see clients still using PPINIT (passphrase initialization) for master keys. This practice prevents key rotation after an incident and creates a single point of failure. Consider an option like the Trusted Key Entry (TKE) workstation for secure key management and rotation.