Aug 2 ’10

Is Your z/OS System Secure?

by Editor in z/Journal

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:

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:

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:

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, 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:

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:

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:

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.