Research Shows Mainframes Have Severe Security Code Vulnerabilities
The Fortress Myth
The mainframe is often considered to be an impenetrable fortress. The Fortress Myth is based on two factors. The first is the presence of a large freestanding machine that, historically, was confined to communications within an enterprise. The second factor is the impressive and legendary IBM® z/OS® System Integrity Statement, which was first issued in 1973 as the MVS™ System Integrity Statement. No other hardware and operating system vendor has issued a public statement of integrity.
A ZERO-DAY VULNERABILITY
is a vulnerability in software that is unknown to the vendor or code-owner
Adding to the Fortress Myth is that, until recently, z/OS installations did not have access to tools capable of performing binary vulnerability scanning of the software residing in the mainframe’s operating system layer. Manually reviewing the software to identify severe security code vulnerabilities is impractical due to the vast number of programs. Additionally, unlike software vendors of other platforms, mainframe software vendors do not have open websites informing the public about severe security code vulnerabilities, and the lack of public information perpetuates the Fortress Myth.
You Can’t Have Security Without Integrity
IBM defines integrity as the inability of any program, not authorized by a mechanism under the client’s control to:
- Disable or circumvent the store or fetch protection
- Access an operating system resource that is password protected or protected by a mainframe security product, also called an External Security Manager (ESM)
- Obtain control in an authorized state such as APF-authorized, supervisor state, or with a protection key of less than eight
Identifying Vulnerabilities in the Mainframe
Exploitable vulnerabilities in the mainframe can be categorized as configuration-based and code-based. Configuration-based vulnerabilities are caused by improper configuration settings in the IPL (boot), subsystem startup, or external security managers like IBM RACF®, CA ACF2™ or CA Top Secret®. Configuration-based vulnerabilities are remediated by making configuration changes.
Code-based vulnerabilities are caused by poor design or coding errors in products that reside in the operating system layer on your mainframe. A complete security compliance review of a mainframe system includes vulnerability analysis of configuration-based and code-based vulnerabilities. Failure to do both leaves your mainframe system at risk.
Automated, real-time, binary code scanning tools make it possible for enterprises to scan the operating system layer of the mainframe to identify severe security code vulnerabilities. Research performed by Key Resources, Inc. shows that the vast majority of mainframes have severe security code vulnerabilities in code that is running on their production systems. The vulnerabilities may exist in the operating system, vendor or internally-written code.
Severe security code vulnerabilities, when exploited, allow internal and external hackers to bypass the security controls put in place by z/OS and the installation. It takes only one exploit of a severe security code vulnerability to:
- Elevate a user’s access privileges
- Turn off security and logging
- Denial of Service Attack
A ZERO-DAY ATTACK
is a vulnerability exploited by a compromised or disgruntled employee or external hacker before a vendor or code-owner fixes the code or before the patch is installed by the client
Remediating Vulnerabilities in the Mainframe
Unlike configuration-based vulnerabilities, code-based vulnerabilities have to be fixed by the code-owner or, in rare cases, the code has to be removed from the system. In most cases, removing the errant code from the system is not a viable option and remediation is required.
NOW IS THE TIME TO BEGIN
taking mainframe code vulnerabilities seriously!
An automated scanning tool must be able to report the exact locations of each of the identified vulnerabilities as well as how to re-create the issues. This information should be used by the code owner in re-creating the issue in their secure development environment. An exploit should not be developed, as it reduces the risk of exploit details being disclosed. By re-creating the vulnerabilities, the code owner validates the information provided by the automated scanning tool, and then creates a patch to repair the vulnerability.
Once a patch to the code is available, it must be applied across all systems. It is imperative that this process be done in a timely manner before a compromised and/or disgruntled insider or external hacker writes, publishes, and potentially executes an exploit on your system.
While software vendors regularly issue fixes for known code vulnerabilities, most enterprises choose to adhere to their standard maintenance processes and may not install a fix before the vulnerability is known. The best practice is to incorporate automated, real-time binary scanning tools into your maintenance and quality assurance processes. This practice will allow potential severe security code vulnerabilities, or SSCVs, to be identified before they are rolled out to production machines. This same practice will help to ensure that the remediation of one SSCV has not inadvertently introduced additional vulnerabilities.
Improve Regulation Compliance
Many existing industry regulations and guidelines require automated vulnerability scanning. For example, the Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures document states that testing procedures require that an enterprise perform quarterly internal vulnerability scans and rescan as needed, until all “high-risk” vulnerabilities are resolved.
The National Institute of Standards and Technology (NIST) Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, recommends the use of automated tools to report integrity violations.
The Technical Safeguards section of the HIPAA Security Standards Assessment document has a subsection addressing integrity called Integrity 164.312. Five out of the six topics in the subsection can be accomplished using a mainframe binary code scanning tool for products residing in the operating system layer of the mainframe.
Due to the large and increasing number of data breaches, similar requirements and guidelines are being adopted by many agencies.
Best Practice: Mainframe Vulnerability Scanning Products
- Available as a stand-alone product
- Performs scans of mainframe operating system layer
- Identifies exploitable severe security code vulnerabilities
- Low false positive rate: < 2% identified vulnerabilities
- Provide precise vulnerability location information
- Should not require an exploit to be created