Aug 2 ’10
Is Your z/OS System Secure?
The percentage of internal breaches increased from 15 percent in 2003 to 44 percent in 2008; that dramatic change was noted in a 2008 survey commissioned by CA Technologies. The same survey showed that most IT leaders consider internal security threats a bigger risk to business than external attacks.
In the mainframe world, we’ve focused our efforts on securing our systems from outside threats and controlling the abuse of privileges by our massive user communities. Unfortunately, we’re missing exposures that, as noted in the survey, originate on the inside.
Efforts to secure the mainframe date back to the early ‘70s. The SHARE Security Project was formed in 1971, and it immediately began deliberations on how to secure IBM systems. The committee went around in circles, dealing with the issues of system integrity and system security, often confusing the two concepts. None of the members were satisfied with the non-existent level of security provided by the, then current, IBM operating system, OS/MVT.
Then, in 1973, IBM announced a new operating system, OS/VS2 Release 2, which included this system integrity statement as part of the IBM VS2 Release 2 Planning Guide:
System integrity is defined as the ability of the system to protect itself against unauthorized user access to the extent that the security controls can’t be compromised. That is, there’s no way for an unauthorized problem program using any system interface to:
- Bypass store or fetch protection; i.e., read or write from or to another user’s areas
- Bypass password checking; i.e., access password-protected data for which a password hasn’t been supplied
- Obtain control in an authorized state.
In VS2 Release 2, all known integrity exposures have been removed. IBM will accept as valid, any APAR that describes an unauthorized program’s use of any system interface (defined or undefined) to bypass store or fetch protection, to bypass password checking, or to obtain control in an authorized state.
The system integrity statement preceded the advent of any of the three mainframe security systems:
- Resource Access Control Facility (RACF), which IBM introduced in 1976
- ACF2, developed by SKK Inc. in 1978 and now owned by CA Technologies
- Top Secret, developed by CGA Allen in 1981 and now owned by CA Technologies.
The method used to protect data before the advent of these security systems was rudimentary passwords, but it’s easy to replace the concept of simple password protection with the controls of a security system. Clearly, even as far back as 1973, mainframe security systems were built on, and dependent on, the foundation of operating system integrity.
IBM has done a commendable job of maintaining system integrity over the years and has been responsive to any reported system integrity exposure. But, what about:
- Independent Software Vendor (ISV) products
- Locally developed exits and authorized programs
- Software obtained from other installations via shareware such as the CBT Tape (see www.cbttape.org)?
System integrity exposures are particularly exploitable by insiders who accounted for almost half of the documented breaches in 2008.
How do you secure your z/OS system? First, ensure that the proper security system controls and operating system parameters are set for maximum security.
All the APF-authorized libraries should be properly protected and only a limited set of users should have authority to update them. Programs in APF-authorized libraries, if linked with the AC(1) parameter, can, at will, obtain an authorized state and be able to gain access to data sets and resources. However, assuring this is a complex process. Installations may have more than 100 APF-authorized libraries and, for each one, the list of users who can update them must be obtained from the security system. Each user must be validated as appropriate.
Similarly, the data sets that collect the Systems Management Facility (SMF) log files must be properly protected. These contain the security system violation and logging records. The system parameter libraries must be properly protected and all parameters relating to the security they contain must be validated as appropriate. Any system exits, which can adjust the operating flow and also give certain programs or users additional privileges, must be reviewed. There are many parameters and settings and controls to review.
Before the introduction of automated methods, performing a security audit was a long, involved process that required extensive expertise, so it was difficult, expensive, and not totally complete. SKK developed and introduced the Examine/MVS product in 1984; it automated this analysis and allowed both auditors and internal security personnel to perform the process. Examine/MVS, now owned by CA Technologies and known as CA-Auditor, was followed by Vanguard Integrity Professionals’ Analyzer and then Consul’s Audit, now part of the IBM Tivoli zSecure suite.
The Defense Information Services Agency (DISA) has developed an extensive set of security guidelines. There are specific guides called the Security Technical Implementation Guides (STIGs) for ACF2, RACF, and Top Secret. These STIGS, available on the DISA Website at http://iase.disa.mil/stigs/stig/index.html, are cookbooks on how to properly configure the z/OS system parameters and ACF2, RACF, and Top Secret. They’ve been developed for all platforms the military uses, not just mainframes.
There are separate DISA STIG guidelines for z/OS for each of the three mainframe security products. While these guidelines may not apply completely to non-military z/OS installations, they’re a full list of items you should review. If the result of the review is that they don’t apply to your installation, or must be modified to fit your site’s operating standards, that’s acceptable, but each STIG should be used as a guide.
DISA has also developed a REXX implementation to validate that the installation is adhering to the STIGs; it uses the CA-Examine product as a base to collect the information. Vanguard Integrity Professionals recently introduced its Vanguard Configuration Manager (VCM) product, which reviews a z/OS system with RACF. This automated methodology eliminates almost all the labor-intensive aspects of reviewing your installation for compliance with the STIGs and does the analysis and reporting.
The STIGs assume there’s no way to bypass the integrity of z/OS, but if a user program can successfully do this, it can reset certain flags and settings to make the security product believe the program is authorized to access any resource it wants and even bypass any production of the security system log records. This applies to all three security products, although the internal settings would be different for each one.
Two different exposures can affect z/OS:
- Supervisor call routines or authorized programs whose sole purpose is to place the caller in an authorized state or set the caller up so he or she can be in an authorized state. These may be designed and intended to be a part of a legitimate or useful product or service but can be used illegitimately for other purposes.
- Errors in the implementation of products, homegrown programs, operating system extensions, or even z/OS that would allow the caller to obtain control in an authorized state. These may be in authorized programs, Supervisor Calls (SVCs), Program Call (PC) routines, or system exits.
Often, systems programmers aren’t aware of the integrity issues the first exposure introduces. For example, on one of the mainframe Internet lists, a systems programmer posted a code fragment asking for help. What the programmer was asking for isn’t relevant, but the code fragment (see Figure 1) is startling. Utilization of this SVC gives anyone in that installation who has access to Time Sharing Option (TSO) or batch processing the “keys to the kingdom.”
A similar SVC was found as part of an enhancement package, submitted by a reputable organization, on the CBT tape Website. The enhancement is something many installations would desire, so it’s possible many installations have unknowingly introduced this exposure into their environment.
The second vulnerability, the inadvertent one, has been found in products produced by ISVs, locally developed code, code obtained from other installations and, yes, even in IBM-supplied code.
Using analysis tools and techniques that discover these inadvertent vulnerabilities, along with the deliberate ones previously described, we’ve defined the following vulnerability categories for them based upon exposures it has found:
- Store into an address provided by an unauthorized caller while in system key or state. This could be used to update the status of the user program into an authorized state by, for example, storing into the Job Step Control Block (JSCB), which contains the authorized privilege flag.
- Load into a register, or several registers, from a fetch protected storage location provided by an unauthorized caller. If a dump is then induced, the content of the fetch protected storage is available. If this is a password, it could lead to a security exposure.
- Pass execution control to an address provided directly or indirectly by an unauthorized caller. This could be used to just obtain control in an authorized state.
- Dynamically elevate authority by setting the JSCBAUTH flag or ACF2, RACF, or Top Secret privileges.
Discovering these vulnerabilities takes a high level of expertise, and a similar level of expertise would be required to develop a method to exploit them. However, executing the exploitation method is easy. In one case, we developed an 11-line REXX program that gave the user RACF privileged authority. A slightly different version would have done a similar thing for ACF2 or Top Secret. The 11-line REXX program could easily be entered by any TSO or batch user. Note that this applied to a vulnerability that the vendor has since closed.
Given the rising percentage of insider attacks, it’s imperative installations take appropriate action before an attack succeeds, causing loss of critical or controlled information or wreaking financial havoc on the organization. z/OS installations must:
- Apply all IBM integrity fixes as soon as they receive them.
- Require that all ISVs provide a system integrity commitment that covers the products installed at the installation and commits to responding immediately to repair any system integrity exposure introduced by their products. Some of these issues may require extensive changes and testing, so while the vendor may start on remediation immediately, it may be some time before the vulnerability is repaired in the field.
- Review all installation-developed authorized code for integrity exposures. If the installation doesn’t have the required expertise, it should engage the services of an outside expert consultant.
- Review all code obtained from outside the company for integrity exposures (again using an outside expert if necessary).
- Periodically review the state of the z/OS system to assure that older integrity exposures have been repaired and no new ones were introduced. Remember that the z/OS system is continuously being updated with Program Temporary Fixes (PTFs) and new releases and, similarly, ISV products and internally developed code are being introduced and updated. We recommend periodic reviews for system integrity.
Keeping z/OS secure requires continual review of what’s added to the operating system and a solid understanding of how the operating system environment and security system controls are implemented.