Insider threats, code-based vulnerabilities, human error, hackers, and ransomware are some of the top security concerns for companies. Since a 2018 Forrester study found that 57% of enterprises with a mainframe use it to run more than half of their business-critical applications and 72% of customer-facing applications are completely or very dependent upon mainframe processing, plugging security holes is vitally important.
Enterprises rely on add-on security software products, such as External Security Managers (ESMs), to provide security on the mainframe, enabling them to meet compliance and customer expectations. But there are additional considerations enterprises need to take into account. Organizations need to proactively handle the top vulnerabilities that affect all ESMs (i.e. IBM’s RACF and Broadcom’s CA ACF2 and CA Top Secret) and z/OS, according to Brian Marshall, president of Vanguard Integrity Professionals, and Robert Hansel, president of RSH Consulting, Inc., in their SHARE Virtual 2020 Best Session presentation, "Security Opening – Common Holes and a Deep Dive into the Top Prevalent Vulnerabilities that Impact z/OS and all ESMs."
Top 5 Vulnerabilities of ESM and z/OS
Marshall says that three of the top vulnerabilities that affect ESMs and z/OS are APF authorization protection, a lack of multi-factor authentication (MFA) implementation at all user levels, and unencrypted data at rest or in-flight. He explains that with APF authorization protection, there is a lack of understanding that LNKAUTH=LNKLST has the effect of causing all LNKLST libraries to be APF authorized when not invoked from STEPLIB, TSOLIB, JOBLIB, and similar invocations that concatenate the library dataset name.
For MFA, Marshall explains, "Many shops tend to only look at this from an ESM perspective, and I firmly believe it should be from a data access perspective." For example, mainframe shops need to look beyond the ESM specific attributes and look at who has access to sensitive data and profiles, such as special, operations, READALL, Non-CNCL, MISC authorities, FACILITY class, STGADMIN authorities or IRR-ADMIN, or BPX (New to mainframe? Review many of these terms in this Getting Started guide from IBM). Be mindful of who has access to CICS, DB2, IMS, or any other application that allows access to view/update/delete sensitive data along with dataset profiles/rules, he says.
Hansel adds that two other common vulnerabilities in ESMs and z/OS include when powerful utility functions enable unrestricted data management authorizations (e.g., backup, restore, rename, scratch, etc.) to IDs that often are not properly controlled and reserved just for the storage administration staff. Additionally, z/OS UNIX security is too often left to the technical support staff responsible for maintaining z/OS UNIX, and those staff tend to assign superuser-type authorities excessively to get system products working more quickly.
Assess Your Security Holes
Marshall indicates that APF-authorized datasets should start with the list returned from the RACF Sensitive Resources Health Check, which does a marvelous job reporting on APF defined datasets, and then extend that to LNKLST libraries when LNKAUTH=LNKLST. "Once you have the definitive list," he says, "review permissions for all of these datasets with the understanding that UPDATE access must be very limited and all access UPDATE or higher should be logged. Additionally, understand that SETPROG access is tantamount to having APF access and that this resource must be severely limited and logged as well."
Multi-factor authentication is more than just the combination of user ID and password or passphrase authentication. Marshall says that the best option is to check with ESM administrators, storage administrators, database administrators, and sysprogs about what protocols and MFA they use because it will depend upon the ESM and its implementation on the mainframe. For unencrypted data at rest or on the fly, he advises looking to see if the Policy Agent started task (PAGENT) that manages the TCP/IP configuration, including AT-TLS, is up and running and then check all IP configuration files for ports and encryption. He adds that there are some products available to check this and for data-at-rest encryption, and he reminds mainframers not to forget about pervasive encryption.
Hansel says for z/OS UNIX and storage administration issues, mainframe security personnel should gather a list of all known resources (e.g., UNIXPRIV resources like SUPERUSER.FILESYS) and then determine who should have what level of access to each. Afterward, they need to assess existing permissions to see if the expectations match with reality. "This is not a quick process if it has not been done before and should be documented for future reference," he explains. Health Check, Hansel adds, is great for finding gaping holes, such as excessive default access, but it requires more detailed analysis to find excessive permissions.
Top 5 Security Must-haves
- A specific, written, testable set of guidelines for security on the z/OS system. Start with the DOD DISA STIGS for z/OS (they have them for all three ESMs) and then adapt those to specific organizational requirements.
- Multi-factor authentication (preferably the same authentication provider they use on their distributed systems) on z/OS and preferably for all users.
- Privileged user access monitoring to help prevent internal and external threats.
- Encrypt everything and take a zero-trust approach. Don't trust any connection, whether it's inside or outside your network; instead, treat every session/transaction as a separate entity and validate it.
- Fund and properly train staff to find and address security issues.
What's the Remedy?
Once common security holes are assessed, Marshall says mainframers need to APF authorize only those libraries that actually require it, and they should create an automated procedure that can identify changes in both content and access to the APF-authorized libraries and issue an alert. He also emphasizes that UPDATE access should be strictly limited.
For unencrypted data and user access, Marshall advises running a sniffer and port scanner on the network to look for data and passwords in the clear. However, he says users will need to be very careful and only do it with the highest approvals and with the understanding that it can cause outages. "It is not uncommon for some standard tasks to have issues with port scanners or sniffers causing a network slowdown," cautions Marshall.
Hansel adds, "Suspected excessive access permissions cannot simply be removed, especially for system/process IDs like those for started tasks and production batch jobs, because it could cause an outage if access is actually needed." Remediation requires great care, he says. For critical resources, Hansel advises that users follow established change control protocols and remove access during a system maintenance period. They also need to closely monitor the system for problems immediately thereafter and be prepared to restore access if necessary.
Additionally, Marshall says that management needs to be made aware that z/OS is a system that matters, and if it is not properly secured and maintained "they could lose their job." The mainframe is connected to the outside world, and if an outside firm needs to be hired to demonstrate its vulnerabilities for management to understand, he says it is worth the investment. "Explain to them that defense in depth requires that they use the same types of controls on z/OS that they insist upon for other devices," he says.
Hansel points out that organizations also need to ensure their security awareness program informs all users they play important roles and have responsibilities in protecting mainframe resources. "Users need to notify security administrators if they believe they or others have been given more authority than seems appropriate for their job and remedy that," he adds.
Be Vigilant and Proactive at all Times
ESMs enhance security, according to Marshall, but administrators must know and understand not only the ESM but also z/OS. He says that administrators and sysprogs should be trained on security, and organizations should consider using outside firms on a periodic basis to check that security is being maintained and enhanced. "It's very easy for internal folks to accept the status quo of security simply because they have always operated as such." Hansel adds that ESMs provide the bulk of security protection on z/OS and are, therefore, essential. "No system should be without one," he says. "Some software products have their own internal security controls, but they provide security only for themselves and not for the system as a whole. Increasingly, software products, especially those from IBM (e.g., SDSF), are dropping their internal security entirely and requiring ESMs to take control."
Marshall and Hansel believe you should never assume your mainframe is secure, but remain vigilant. Marshall says, "z/OS is many times the repository for an organization's most valuable data. Insider and external threats are always a concern." Hansel explains that the mainframe has the most robust security controls available, but those controls must be implemented properly and maintained in order to remain effective. Marshall concurs, adding that remediation after an exfiltration of data is far more expensive than spending money on detecting and preventing it. This is why Hansel says continuous checking and refinement are required, especially whenever there is a new software product release introduced into the environment.