IBM Z-Series systems are renowned for their dependability and uptime, which is why they are still widely used in a variety of different industries.

These highly-securable systems (such as the recently announced z17) run numerous applications, process mission-critical services and hold crucial data across the banking, insurance, healthcare, government and retail sectors.

In today’s open networks, the mainframe cannot implicitly trust the user, however securing said data can prove to be cost-intensive and may disrupt some departments, especially in higher-volume mainframe systems.

This article will tackle some topics about security with RACF on System Z

Passwords: The modern Ostiary

As most people will be aware, passwords are critical gatekeepers to our digital identities, protecting access to our accounts for online shopping, dating, banking, social media, etc...

Ultimately, passwords can present a mundane and seemingly simple point-of-attack for hackers to exploit, which is why it's so important to keep them secret.

For Z-series systems, password controls must be enforced to ensure security and compliancy, while user education should be provided to prevent use of uncomplicated passwords.

While a password like 0S7!4RY# would reasonably be considered 'strong', such a complicated password could cause a wholly different problem in that is hard to remember and the user may write it down so they don't forget.

This creates a near-paradoxical situation where users need to make passwords difficult enough to not be beaten by brute-force attacks, yet also easy/familiar enough to be remembered without prompts that may be found by potential threat agents...

RACF Password Suggestions

RACF provides authentication options for the mainframe, and all of these options should be leveraged to strengthen password complexity:

• Utilise the full number of characters, which is 8 characters for RACF passwords: Increased length means increased time and effort in a brute-force attack.
• Use a combination of alphabetical and numerical characters (letters and digits).
• Using mixed-case passwords doubles the number of alphabetical options.
• Additionally use special characters and national characters (@ # £ $)

You may not be able to use all of the above suggestions depending on your employer's password rules (via SETROPTS) but using all of these will drastically increase the number of possible permutations and combinations!

Beyond Passwords and Passphrases

Aside from the Passwords & Passphrases described in my last article, there are other avenues for securing your IBM Z System...

Encryption is the process of converting data into a string that is unreadable to anyone without the correct decryption key: Database systems may happily decrypt data on behalf of an illicitly authorized user, thus user ID/password controls and data-encryption are complementary aspects of security.

PassTickets allow a workstation to communicate without using a RACF password or password phrase, with a product or function creating a one-time-use token for the end-user that isn’t reusable and is time dependent.

Digital Certificates are a type of digital credential that are signed and/or issued by a trusted third party that binds an end entity to a public key. Certificates involve two parties which both have the certificate in their database (known as a keystore) in a process known as a "handshake", where one party uses the certificate to identify itself, and the other party validates it via the SSL / Transport Level Security protocol.

IBM Multi-Factor Authentication for z/OS (also known as IBM MFA) provides the facility for users to use multiple authentication factors during the logon process. Designed to be flexible, this is not locked to any particular authentication factors, so as new MFA options become available, they can be added to this facility without changing the core infrastructure.

Security like Onions: It's gotta have Layers

In an ideal world, every aspect of your IBM Z System would be secure, including every individual product and tooling.

However, given the current (ongoing) issue of the Skills Shortage, organisation may want to focus on putting infrastructure functions in place, rather than fixing 'legacy' applications.

This is primarily because you can’t always find people capable of fixing them, especially with many veteran mainframers retiring, and a lack of time to train new talent.

Security functions can be introduced and improved on layers outside of z/OS itself, including databases, web servers, etc... For example, Db2 can have it's own security implemented directly or via RACF profiles.

Introducing additional layers of security is the best practice, being both cost effective and having a minimal impact on transparency: However, there’s no one magic silver bullet that can protect against all threat vectors, no matter what platform a business utilises.

CISO 🤝 RACF

Security expectations cannot be relegated exclusively to mainframe users.

Those with permissions to review the RACF Database of a system (e.g. Security Engineering staff) should find time to coalesce with any present Information Security teams (e.g. CISO) and work together to ensure that the system is a secure as possible.

This may include regularly inspecting all aspects of a system (from printers and fax machines, to VDIs and Mainframes) in order to identify if anyone is attempting to read prohibited information.

By consistently inspecting which data is being accessed by users and how often, it's easier to find a potential threat within your system.

If a user ID is compromised, you should have a layer of defence that prevents the attacker from getting too much data too quickly, slowing a threat down and allowing you time to restrict and/or revoke access.

Intrusions of this type can be detected via data-usage control software, including zSecure Alert and zSecure Command Verifier.