Your mainframe may be the most secure computing platform in your organization, but did you know it’s also at high risk for security breaches and regulatory non-compliance?
An impressive finding of the 2011 Verizon Data Breach Report is that 89 percent of organizations suffering payment card breaches hadn’t been validated compliant with Payment Card Industry Data Security Standard (PCI DSS) at the time of the breach. (See the report at www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2011_en_xg.pdf.) These standards are meant to be used as a benchmark, with standards compliance leading to an improved security posture.
Even if an installation isn’t legally subject to the PCI DSS standards, are they subject to other standards such as the Healthcare Information Portability and Accountability Act (HIPAA), National Institute of Standards and Technology (NIST), International Organization for Standardization (ISO), or the Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG)? All these standards require an installation to review its system and network configuration security and integrity controls to maximize the security of the environments and minimize vulnerabilities. Implementing the appropriate standards for your site—or better yet, implementing the extensive standards of the DISA STIGs—will make your site less vulnerable to a breach and the financial and public image damages associated with it.
Your IT management team must perform due diligence and apply best efforts to protect your data and IT infrastructure from breaches. IT is also responsible for making other senior management aware of the threats facing them if left unaddressed. Yet, this issue is often misunderstood and the requirement is ignored. For instance, the Verizon report shows that 44 percent of respondents indicated they maintained a policy that addresses information security. But only 16 percent of those breached in 2010 had such a policy. Clearly, installations that take security standards seriously and do their best to implement them are much less likely to suffer a breach.
Minimize or Eliminate Vulnerabilities
The purpose of these standards is to minimize or eliminate the vulnerabilities in z/OS systems. A vulnerability can be introduced by poor hardware configuration, poor system configuration parameters, poor security system controls, or a lack of system integrity caused by poor design and coding standards in either z/OS itself, Independent Software Vendor (ISV) products, or homegrown code.
For example, an easily identifiable hardware vulnerability might be the sharing of DASD storage between the production environment(s) and the test/development environment(s). While this practice was the norm many years ago, when disk storage devices were connected with physical cables and the test/development environment(s) were on separate computer systems and used as a backup system, this is no longer necessary today. Devices are now mapped with the Input/Output Configuration Data Set (IOCDS) and the Input/Output Definition File (IODF), which can be altered at Initial Program Load (IPL) time or with a console operator command. Normally, test and development environments have significantly less stringent security standards than production environments. Why put the production data and the system and application libraries at risk in these less secure environments?
Failure to fully protect all the Authorized Program Facility (APF) libraries on the system is an example of a system configuration/security system controls vulnerability. These APF libraries are defined in the Operating System Parameter Library. Authorized programs within them are marked with an “AC(1)” linkage editor attribute. For example, a program marked AC(1) residing in an APF authorized library can issue the MODESET KEY=ZERO Assembly language macro and obtain control in PSW Key Zero.
PSW Key Zero lets a program modify any storage in the system. This might legitimately be used to modify control block parameters to adjust the way the system or a vendor-supplied subsystem operates. It might also be illegitimately used to modify the user’s security credentials to make the user appear as a different and more privileged user or entity. In this way, the program could access and modify any data without any indication or journaling. Even the most diligent installation security staff won’t notice an issue or be able to reconstruct what happened to cause a breach to occur under these circumstances.
There may be hundreds of APF authorized libraries on any system. What controls are there on each of them? Who can update them? When a new one is added, is it reviewed to ensure no additional AC(1) modules were placed in it? Who reviews the security system logs to ensure that no illegitimate updates were allowed to occur in the libraries? What security system controls are in place over the operator command that dynamically adds these libraries?