A Risk-Based Approach to CVE Assessments in Regulated Environments

Updated -

In the article An Open Approach to Vulnerability Management, Red Hat outlines our approach to vulnerability management, including how we define, evaluate, report, and mitigate vulnerabilities within our products and services. For every reported vulnerability, Red Hat Product Security works with product engineers to review technical details and assess the potential impact on our products and services. This approach is especially true for regulated environments, which have been hardened and configured specifically to minimize risk.

This assessment includes information gathered and distributed through CVE.org, including the Common Vulnerabilities and Exposures (CVE) ID for vulnerability identification, Common Weakness Enumeration (CWE) for root cause analysis, and the Common Vulnerability Scoring System (CVSS) for vulnerability metrics. CVE.org acts as an administrator and aggregator of vulnerability data through CVE Numbering Authorities (CNA) oversight, CVE ID assignment, and centrally collating vulnerability information.

The CVSS score provides a base metric for characteristics that are true across any platform, including CIA impact agnostic to platform-specific configuration. CVSS itself is not a measurement of risk despite a widespread belief to the contrary. CVSS is divided into Base Metrics along with optional Temporal and Environmental Metrics. Temporal Metrics reflect the characteristics of a vulnerability that may change over time, while Environmental Metrics address the effects of a vulnerability in a specific environment.

Assessing the impact of a vulnerability using only Base Metrics is inadequate for fully understanding the risk to a given environment. It does not factor in the deployment or characteristics of the environment itself. According to FIRST’s Common Vulnerability Scoring System v3.1: Specific Document: “Consumers of CVSS should supplement the Base Score with Temporal and Environmental Scores specific to their use of the vulnerable product to produce a severity more accurate for their organizational environment.” The article further advises that a comprehensive risk assessment system should be employed that considers more factors than simply the CVSS Base Score.

Red Hat’s strategy for assessing vulnerabilities within regulated environments is based upon holistically assessing each vulnerability using the Base, Temporal, and Environmental Metrics as cited above. The additional controls used and cited in these assessments are representative of the Temporal and Environmental Metrics within CVSS.

Regulated environments

A regulated environment is defined as an environment where specific controls are required to operate. Examples of regulated industries include, but are not limited to, Financial Services, Government and Public Sector, Healthcare and Life Sciences, and Telecommunications. By implementing these controls, an organization creates barriers to successful exploitation and reduces the attack surface for any number of vulnerabilities. For this article, we will assess vulnerabilities in a FedRAMP High environment.

Red Hat OpenShift Service on AWS (ROSA) is FedRAMP High approved. To meet these requirements, we built a separate environment that was subject to over 400 controls stemming from the NIST SP 800-53 revision 5 security control baselines. When assessing vulnerabilities, we must consider the architecture built to meet those controls on top of underlying OpenShift architecture, existing practices, and the Base Metrics for the associated CVEs.

For this process, Red Hat security engineers conduct additional research on the vulnerability and the available controls. By understanding the root cause of a vulnerability and examining the potential consequences, an appropriate set of implemented FedRAMP High controls can be cited, reducing the likelihood or risk or even preventing the exploitation of the vulnerability.

For example, if the vulnerability falls into the privilege escalation category, our engineers focus on configurations that are in place to meet security controls, such as:

  • AC-2: Account Management
  • AC-5: Separation of Duties
  • AC-6: Least Privilege
  • IA-2: Identification and Authentication
  • IA-5: Authenticator Management (hard token MFA requirements)

The requirements that we meet in implementing these controls in the more stringent environment of FedRMAP High, combined with robust auditing and monitoring practices, help to reduce the risk of vulnerabilities like these from being exploited.

Conclusion

In summary, Red Hat engineers consider many factors when assessing vulnerabilities to assign risk and severity levels, especially in regulated platforms. It’s important to us to analyze all vulnerabilities regarding risk and actual threats and be transparent about our processes.

References

An Open Approach to Vulnerability Management
Common Vulnerability Scoring System v3.1: Specification Document
NIST SP 800-53

Comments