A vulnerability introduced by a poorly designed or coded authorized interface in z/OS, a vendor product, or a homegrown program or service can be exploited to gain the same level of control as an authorized program. That means the exploitation can then be used to alter the identity of the current user and gain access to and possibly modify sensitive or critical data without event logging.
Statement of Integrity
The SHARE Security Project was formed in 1972 to develop security requirements for future IBM operating systems. Project participants quickly realized there was no possibility of data security if the formal interfaces of the operating system could be bypassed due to lack of system integrity. IBM acknowledged this problem and responded to it in 1973 with its Statement of Integrity for OS/VS2 and subsequent operating systems, MVS and z/OS. (See the statement at http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.html.)
When IBM introduced MVS, it knew some vendor and homegrown programs would require the privilege to obtain control in an authorized state and use special authorized interfaces to the operating system; they provided the APF library functionality to address that. However, IBM clearly places the burden of responsibility on the installation for these programs: “To ensure that system integrity is effective and to avoid compromising any of the integrity controls provided in the system, the installation must assume responsibility … that its own modifications and additions to the system do not introduce any integrity exposures.” (This statement appears in the z/OS V1R12 MVS Authorized Assembler Services Guide, page 423, accessible at http://publibz.boulder.ibm.com/epubs/pdf/iea2a8b0.pdf.) Note that this applies to both homegrown and ISV programs and products.
Unfortunately, poor design and coding standards in the operating system, vendor products, and homegrown authorized routines and interfaces can also introduce vulnerabilities. In the PC world, we’re used to using virus checkers that look for routines either executing or residing on disk that leverage known vulnerabilities in the Windows operating system (what PC vulnerability people call “root-causes”). z/OS installations are fortunate to not need virus checkers because IBM commits to remediate all reported issues, but there are still vulnerabilities on its systems attributable to undiscovered design and coding errors in IBM and homegrown or ISV programs and service interfaces. The integrity vulnerability issue can’t be ignored. Within the recent past, more than 100 system integrity vulnerabilities have been located in z/OS and ISV products, according to Ray Overby of Key Resources, Inc.
Installations must demand their ISVs adhere to IBM’s z/OS Statement of Integrity and commit to always take action to remediate a system integrity issue when it’s reported. More important, they must include issues of integrity design in their software development and code review process. Installations should also engage professional vulnerability experts to review their systems and accompanying software to ensure they aren’t inadvertently introducing vulnerabilities that can be exploited to breach their security.
The vulnerabilities created by poor configuration, security system controls, and system integrity are more easily exploited by insiders. But, before you can assume insiders are a totally trusted group of individuals, it’s important to recognize that the percentage of breaches caused by insiders is rising. For example, in the 2008 Strategic Counsel Survey sponsored by CA Technologies, the percentage of internal breaches rose from 15 percent in 2003 to 44 percent in 2008. (See details at: http://investor.ca.com/releasedetail.cfm?releaseid=322474.) A 2010 PacketMotion Survey of U.S. government agencies revealed that employees still pose the biggest security threat (see http://www.nextgov.com/nextgov/ng_20100817_1347.php).
The White House, as reported in USA Today on January 6, 2011, asked agencies to review their data security as it relates to insiders: “In an attempt to tighten control of classified information, the Obama administration has issued governmentwide guidelines urging officials to be wary of ‘insider threats’ and suggesting how supervisors can evaluate employee ‘trustworthiness.’ ”
A January 3, 2011, Office of Management and Budget memorandum asks: “What steps has your agency taken to implement the latest version of the NIST SP-800 series guidance on Information Assurance, Risk Management, and Continuous Monitoring?” According to Gartner (see their Research Note G00172909), the IBM z/OS mainframe continues to be an important platform for many enterprises, hosting about 90 percent of their strategic applications. Enterprises may not take the same steps to address configuration errors and poor identity and entitlements administration on the mainframe as they do on other operating systems. So, the incidence of high-risk vulnerabilities is astonishingly high, and enterprises often lack formal programs to identify and remediate these.
The 2010 CyberSecurity Watch Survey sponsored by CSO Magazine (http://www.net-security.org/secworld.php?id=8781) indicates that “cybercrimes committed by insiders are more costly and damaging than attacks from the outside.” A more troubling survey comment (accessible via the same link) was from Deloitte & Touche LLP: “We believe that most cybercrimes go unreported, not because they are handled internally, but rather because they are never detected in the first place. This is a proverbial ‘tip-of-the-iceberg’ situation, and the implications are significant.”
z/OS mainframes have always been assumed to be secure because of IBM’s Statement of Integrity and the capabilities of three software security products—IBM’s Resource Access Control Facility (RACF) and CA Technologies’ ACF2 and Top Secret—that control access to the data sets and resources contained on those systems. However, the system configuration and security system controls and parameters must be validated to ensure maximum protection. The installations most seriously breached are those that fail to put information security high enough on their priority list to assure compliance with standards intended to avert disasters.
The U.S. Government has invested a great deal of money into developing the DISA STIGs (see details at http://iase.disa.mil/stigs/os/mainframe/z_os.html) for a variety of platforms, including mainframes, and these can be used in addition to vulnerability scans and penetration tests to ensure maximum protection for these systems. Vulnerability scans and penetration tests are required under several standards:
- PCI Requirement 11.3
- NIST 800-53 Requirement CA-2
- ISO 27001 Requirement 15.2.2.
It’s been easy to believe these apply only to the non-mainframe environment because mainframe z/OS systems were inherently secure. But this isn’t the case, and to be compliant, installations must also add these tests to their security assurance project list.
Installations can’t ignore their responsibility to information security on z/OS mainframes. It’s imperative for the security of their organization’s data and the protection of their customers’ private and confidential information. z/OS mainframes are the most securable systems available, but only with due diligence will the security on these systems be strengthened to the highest level possible and the risk of disaster minimized.