Enterprise Knights of IBM Z - Group home

Thwarted by IBM Z! - Episode 5

  


Introduction
How do I secure thee, let me count the ways? Well, one critical step is making sure you have a solid enterprise patch management strategy that includes your IBM Z. IBM Z includes not only your operating systems, such as z/OS, z/VM, Linux on IBM Z, etc., but also the middleware and application deployment environments, such as CICS, DB2, and Java. And let us not forget that IBM Z hardware and firmware need to be monitored for possible security patches or mitigations as well. This means you need a plan to ensure all the latest service is applied to your system, which includes security and integrity service, in addition to HIPERs and regular maintenance.

This does not only mean service for what you use, but service for what is installed. This is a common misunderstanding, I often hear “I only need to patch the features and functions I use.” Bad actors do not care if you use the software, if it is installed, it is fair game, not to mention a threat to the security of your IBM Z environment and enterprise as a whole. Leaving older, out-of-service, or unpatched versions of Java on the system, for example, opens a window into all those publicly known and sometimes exploited vulnerabilities.

A window into the Portal
The IBM Z and LinuxONE Security Portal is intended to be your one stop shop for IBM Z security patch information.

You will find Security Notices that cover hardware, firmware, some middleware like WebSphere that do not deliver their fixes via PTF and Java. Security Notices are also how we communicate urgent or important security information to those that have a need to know. Security Notices are provided to communicate hardware and firmware updates needed for IBM Z machines. For example, notifications can include when it is time to update a Service Element (SE) or the Hardware Management Console (HMC).

For z/OS and z/OS products that deliver their fixes via APAR/PTF, Enhanced HOLDDATA and Assign data is provided for use with SMP/E to generate a custom report addressing what needs to be installed on your individual systems based on what products are installed. You will also get a CVSS and an enhanced CVSS file to help security decision makers understand the urgency to install a fix and the applicability of that fix to the system’s workload (see discussion below). The enhanced CVSS file is in a CSV (comma-separated values) format to ease the burden of automation. More on automation below.

There will also be an entry in the Security Portal for z/VM, providing the latest APAR and CVSS information needed to keep your virtualization environment up to date.

Breaking it down with CVSS
The Common Vulnerability Scoring System is an internationally known and understood way of communicating the urgency and applicability of a fix to a particular deployment environment. There are three sets of metrics that help tailor the CVSS score for each environment. The CVSS Base metrics capture the characteristics of the vulnerability, while the Temporal metrics represent the characteristics of the vulnerability throughout its life cycle. The last set of metrics, Environmental, represent the characteristics of the vulnerability in a specific environment. The Base and Temporal metrics are provided in the Security Portal. The Environmental metrics are adjusted by the customer to reflect their use case and how that product may be deployed in any particular environment with a given workload.

These metrics are used in a complex formula, developed at FIRST (see Reference below), to calculate a score, ranging from 0 to 10, where 10 is the highest score. This score is used as one of the inputs to determine the severity of a security vulnerability and therefore the urgency for applying a fix.

A common concern is knowing if a patch needs to be applied. While the best practice is to apply all service, the Base metrics are a good place to start an investigation as to the applicability of a fix. The Base metrics group covers the scope, exploitability, and impact of a fix.

  • The scope indicates if the vulnerability is limited to the impacted component or can extend to other components.
  • The impact metrics cover how the vulnerability pertains to CIA: confidentiality, integrity, and availability.
  • The exploitability metrics cover the attack vector, attack complexity, privilege required, and user interaction needed to exploit the vulnerability.
Reviewing these groups of metrics and their values as they pertain to the specific vulnerability helps to better understand how that vulnerability may relate to a specific deployment environment or workload. That environment may have mitigations in place, like a firewall, to help thwart a network-based attack. A workload might contain Personally Identifiable Information (PII) raising the importance of a vulnerability with a high confidentiality impact.

Decoding CVSS metrics can be a daunting task. When you see a CVSS Vector such as CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, where do you start? The CVSS Base score is 8.6, usually considered High, but the real question is how it pertains to the various workloads in the enterprise given the security controls and mitigations that are in place. It is worth taking some time to really understand what is being communicated when you see metrics such as AV:N, which means this vulnerability has a network based attack vector or C:H, indicating a total loss of confidentiality, but on the other hand I:N and A:N indicate there is no impact to the system’s integrity or availability respectively. These are the valuable pearls of information that are being communicated by the CVSS metrics that must be part of the decision-making process when making critical patch management choices. When you are called on by an auditor to defend your patching strategy, these metrics should be used to support your decisions.

Automation is your friend
With the integration of Python into the IBM Z environment, via Linux or z/OS, the path to automation has been realized. There is a sample Python script in the IBM Z and LinuxONE Security Portal that can be used as a guide to aid in the tricky authentication step, and open the door to automate the patch management process for IBM Z.

This allows for the download any of the files provided by the Security Portal, but of high interest for z/OS users is the HOLDDATA and Assign data. They can be downloaded right to a z/OS image for use and integration with batch jobs running SMP/E.

The enhanced CVSS data can also be automated for use by security officers or auditors and includes not only the CVSS Base score and vector, but a link to a CVSS Calculator with the Base and Temporal metrics already propagated. This allows the security team to adjust the Environmental CVSS metrics, providing a more accurate CVSS score for their enterprise based on their individual workloads. Since z/OS is s general purpose operating system environment it is common for diverse workloads across an enterprise to have different requirements for patch management. Some have even automated adding their Environmental metrics based on workload. The sky is the limit.

Summary
Take the time to automate, understand your workloads and associated risks based on confidentiality, integrity and availability, putting a patch management plan in place to ensure your workloads are thoughtfully protected, reducing risk to your enterprise and saving on unnecessary and unexpected patching fire drills when regular maintenance will cover your enterprise risk policy.

References