There are security incidents and then there are what can be called “Big Bang” security incidents. These are the incidents that fundamentally change how we think about software security and vulnerabilities … even on the world’s most securable system, the mainframe. There have been two such cataclysmic events in recent years, and it is imperative to take action now to protect against future earth-shaking impacts.
The fateful year 2020 closed out with a “Big Bang” when SolarWinds was hacked. This was the first successful large-scale exploitation of a software supply chain. Bad actors were able to inject malicious code into SolarWinds’ Orion platform; the code was then distributed to more than 18,000 customers. Those affected included FireEye, Microsoft, Intel, Cisco, and Deloitte, and even government departments such as Homeland Security, State, Commerce, and Treasury.[1]
A year later, the Log4Shell vulnerability exploded across the IT landscape. This vulnerability enables a remote attacker to take control of a device on the internet if the device is running certain versions of Apache Log4j 2. The “Big Bang” significance of this vulnerability is that it showed exactly how ubiquitous open source software is. Impacted companies and software included Amazon, IBM, Apache, Google, and VMware.[2] Literally millions of exploit attempts have been made to date, and the risk is still very real since countless instances of the code remain unpatched.[3]
These two “Big Bang” incidents sent a clear message: No IT environment is immune from threats. The smallest piece of code may open the biggest door for malicious actors.
When we say that no IT environment is immune from threats, that includes the mainframe. True; the mainframe is the acknowledged frontrunner when it comes to security. Hardware and operating system security measures are baked into the platform. Nevertheless, best practices are critical to maintain the strongest security posture. These include regularly updating software, implementing strong access controls, turning on multi-factor authentication, enabling continuous monitoring, and performing security audits.
Put simply, your mainframe’s security is only as good as the actions you take to protect it. Two actions of key importance for managing vulnerabilities on the mainframe are operationalizing security or integrity fixes and preparing to leverage software bills of materials.
Distributed platforms have been addressing software vulnerabilities for a long time. Consequently, they have created a number of standards that can be used or adapted for the mainframe. For example, the Common Vulnerability Scoring System (CVSS) provides a normalized way to characterize the risks a vulnerability poses. Similarly, Common Vulnerabilities and Exposures (CVEs) enable unique identification of publicly-disclosed vulnerabilities, and Common Weakness Enumerations (CWEs) provide a common language and terminology for software weakness types.
On the mainframe side, IBM enhanced SMP/E several years ago to introduce a new ERROR HOLDDATA category type called SECINT, which flags security or integrity problems. Broadcom adopted SECINT fixes and has been publishing them since then. The CVSS base and temporal scores are included with the security fixes, and the SECINT fix category lets you quickly identify security or integrity maintenance among all published maintenance. Fixes include CVE information for open source software vulnerabilities. Broadcom also regularly publishes a CSV file that includes all the SECINT fix metadata, allowing you to automate processing of security fixes.
It is vital to integrate SECINT fixes into your existing maintenance process if you have not done so already. This can be accomplished by, first, identifying new SECINT fixes, and then prioritizing them for implementation.
One or more of the following options can be used to identify new SECINT fixes you need to address:
Not every security fix is equally important, of course; therefore, systematic prioritization is important. CVSS scores are a great starting point to assist with that prioritization. For example, you might institute a policy that applies critical and high severity fixes every week, and medium and low severities on a quarterly basis. The frequency depends upon your organization and how you decide to manage risk. What is important is to establish a process and follow it consistently.
In the face of escalating security risks, industry leaders and government organizations around the world have been hard at work to develop new capabilities and standards to mitigate software vulnerability and supply chain risks. One of these initiatives is the Software Bill of Materials. A Software Bill of Materials, or SBOM, is a list of all the components, dependencies, and other software artifacts that make up a piece of software. It is, in essence, a manifest that provides a comprehensive and accurate inventory of all the third-party and open source software components used in a software application. It includes versions, licenses, and other relevant information. You can soon expect software vendors to provide SBOMs for their software. In fact, here at Broadcom Mainframe Software, we are able to provide SBOMs for our mainframe software customers today on demand.
SBOMs are a key component in managing software security risks and vulnerabilities. They enable you to understand the full scope of the software you are using and the potential security risks associated with each component (e.g., the Log4Shell vulnerability). An SBOM can be created manually by inspecting the source code and documentation of the software, or it can be generated automatically using specialized tools and services. For example, SBOMz is an SBOM generation tool for z/OS that is available to Broadcom Endevor customers. You can use SBOMz to generate SBOMs for your “homegrown” software. This will allow you to manage software risks for both your homegrown and commercial software in the same standard way utilizing SBOMs.
As with SECINT fixes, it is vital to operationalize and automate consumption of SBOMs to derive value from them. For instance, start with a vulnerability analysis use case where you take all your SBOMs and manage them in a tool such as OWASP Dependency Track (which is available for free) or via one of many commercial solutions. This allows you to take the component information from your SBOMs and match them against known vulnerability disclosures, giving you a list of vulnerabilities that are applicable to your environment. Then, compare that information against published maintenance and pull maintenance to fix the vulnerabilities. This type of automation and setup gives you end-to-end visibility from identification of a disclosed software vulnerability to mitigation with the installation of relevant maintenance.
Vulnerability management on the mainframe continues to evolve. New standards are emerging, such as the Vulnerability Exploitability Exchange (VEX) and Vulnerability Disclosure Report (VDR). These standards are not yet mature or mainstream. However, once they are in place, they will allow vendors such as Broadcom to provide additional context around vulnerabilities to aid with the identification and prioritization of software fixes.
For now, the most important actions are integrating SECINT fixes into your maintenance process and preparing to leverage SBOMs to pinpoint known vulnerabilities. By consistently ensuring that your mainframe security is as good as possible – right down to the smallest piece of code – you are securing your business, your data, and your customers against the threat of even the biggest “Big Bang.”
Get your mainframe security health assessment now.
[1] Saheed Oladimeji and Sean Michael Kerner, “SolarWinds hack explained: Everything you need to know.” TechTarget, June 27, 2023.
[2] Eduard Kovacs, “Companies Respond to Log4Shell Vulnerability as Attacks Rise.” Security Week, December 13, 2021.
[3] Andreas Berger, “What is Log4Shell? The Log4j vulnerability explained (and what to do about it).” March 2, 2023.
Copyright © 2005-2024 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.
Comments