Select a language
As organizations are adopting agile and DevOps to improve their processes and products at breakneck speed, security considerations may be left in the dust and digital risks left unmanaged. Therefore, organizations must have security automation as part of their digital transformation. This article intends to provide you with security basics and an automation approach to assess platforms, products, and services to comply with security policies, regulatory, and compliance requirements.
A prime requirement of security is to mitigate the risks exposed by vulnerabilities that can be exploited by a threat actor, such as an attacker, to cross privilege boundaries within a system. Many known vulnerabilities are discovered by researchers, groups, and individuals who invest their time and report it.
To streamline the efforts, MITRE Corporation maintains publicly disclosed vulnerabilities in a system called Common Vulnerabilities and Exposures (CVE) and Open Vulnerabilities and Assessment Language (OVAL) definitions to describe the desired configuration of systems in machine-understandable format. Security Content Automation Program (SCAP) uses OVAL to automate systems assessment and discover discrepancies to the desired state.
CVE Definition and data fields
The CVE system provides a reference method for publicly known information security vulnerabilities and exposures. Published vulnerabilities are stored in the CVE list in the form of a CVE entry.
Each CVE entry or CVE has a unique identifier formatted as CVE-YYYY-NNNN (CVE prefix followed by discovery year followed by four or more random digit numbers) such as "CVE-2021-3139."
CVEs are assigned by a CVE Numbering Authority (CNA). There are three primary types of CVE number assignments:
1. The MITRE Corporation functions as Editor and Primary CNA.
2. Various CNAs assign CVE numbers for their products (e.g., Microsoft, Oracle, Red Hat, etc.).
3. A third-party coordinator such as CERT Coordination Center may assign CVE numbers for products not covered by CNAs.
The assignment of a CVE number doesn’t guarantee that it is an official CVE entry (a CVE may be improperly assigned to an issue that is not a security vulnerability, or which duplicates an existing entry).
Here's a quick description of few key CVE data fields:
This is a standardized text description of the issue(s). One common entry is:
** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.
This means that the entry number has been reserved by MITRE for an issue or a CNA has reserved the number. So in the case where a CNA requests a block of CVE numbers in advance (Red Hat currently requests CVEs in blocks of 500), the CVE number will be marked as reserved even though the CVE itself may not be assigned by the CNA for some time.
Until the CVE is assigned, MITRE is made aware of it (i.e., the embargo passes and the issue is made public), and MITRE has researched the issue and written a description of it, entries will show up as "** RESERVED **".
This is a list of URLs containing information relevant to the CVE report.
Record Creation Date
This may reflect when the CVE ID was allocated or reserved and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.
CVSS (Common Vulnerability Scoring System) is a free, standard, platform, and vendor-agnostic way for assessing the severity of identified security vulnerabilities. This allows responders to prioritize responses and resources according to the threat. Scores range from 0 to 10, with 10 being the most severe.
It uses different matrices such as Base Group Metrics, Temporal Group Metrics, and Environmental Group Metrics for a vulnerability severity assessment.
Base Group assesses how a vulnerability exploits the system weaknesses and the potential impact on the system, Temporal Group focuses on how severe the vulnerability will grow or reduce over the period, and Environmental Group focuses on change in severity with environmental conditions or implementation.
Based on CVSS ratings the CVE severity is defined. These tables depict the mapping:
Red Hat CVE database and Security Data API
Since Red Hat hardens and packages its product with security in mind, its CVSS scores might differ from the same CVE available at other sources. Hence, we recommend Red Hat customers look into the Red Hat CVE database instead. Red Hat provides the Security Data API, which exposes a list of endpoints to query security data with certain parameters and retrieve CVRF, CVE, and OVAL data easily.
The CVE list is a great way to consolidate published vulnerabilities in a single place. However, it doesn’t provide a structure to automate the findings of vulnerability in a system, and its application is mostly left to manual detection. OVAL helps reduce the gap through its declarative language to specify a specific machine state and interpreter specifications to collect data from a computer for testing based on a set of OVAL Definitions and then evaluate to determine the results of each definition.
Open Vulnerability and Assessment Language (OVAL)
OVAL is an international, information security, community standard to promote open and publicly available security content and to be shared across the entire spectrum of security tools and services. OVAL includes a language used to encode system details and an assortment of content repositories held throughout the community. The main components are:
OVAL Language: The OVAL Language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, configuration, patch state, etc.); and reporting the results of this assessment.
OVAL Interpreter: The OVAL Interpreter is a freely available reference implementation created to show how data can be collected from a computer for testing based on a set of OVAL Definitions and then evaluated to determine the results of each definition.
OVAL Repository: The OVAL Repository is the central meeting place for the OVAL Community to discuss, analyze, store, and disseminate OVAL Definitions. Definitions are free to use and implement in information security products and services.
OVAL Definitions are machine-readable, gold-standard tests that definitively determine whether the specified software vulnerability, configuration issue, program, or patch is present on a system.
Red Hat updates OVAL Definitions each time a Red Hat Security Advisory (RHSA) for an OVAL-compatible product is released. The OVAL Definition is used by the open source scanning tool we use called OpenSCAP, and by many third-party scanning vendors.
Security Content Automation Protocol (SCAP)
The Security Content Automation Protocol (SCAP), includes several open standards that are widely used to enumerate software flaws and configuration issues related to security, such as CCVE, Extensible Configuration Checklist Description Format(XCCDF), OVAL, Asset Reporting Format (ARF), Common Platform Enumeration (CPE), Common Weakness Enumeration (CWE), and Script Check Engine (SCE).
The OpenSCAP project is a collection of open source tools for implementing and enforcing this standard and has been awarded the SCAP 1.2 certification by NIST in 2014.
Red Hat compliance and vulnerability scanning with OpenSCAP
Red Hat Enterprise Linux (RHEL) provides tools that allow for automated compliance audits. These tools are based on the SCAP standard and are designed for automated tailoring of compliance policies.
Security compliance tools supported on RHEL include:
SCAP Workbench: The scap-workbench graphical utility is designed to perform configuration and vulnerability scans on a single local or remote system. You can also use it to generate security reports based on these scans and evaluations.
OpenSCAP: The oscap command-line utility is designed to perform configuration and vulnerability scans on a local system, validate security compliance content, and generate reports and guides based on these scans and evaluations.
Script Check Engine (SCE): SCE is an extension to SCAP protocol that allows content authors to write their security content using a scripting language, such as Bash, Python, or Ruby. The SCE extension is provided with the openscap-engine-sce package.
SCAP Security Guide (SSG): The scap-security-guide package provides the latest collection of security policies for Linux systems.
If you require performing automated compliance audits on multiple systems remotely, you can utilize the OpenSCAP solution for Red Hat Satellite. However, to help verify your system’s security, having a scanning tool like OpenSCAP is not enough. You need to select the right policy. Here is a brief overview of commonly used security policies:
Security Technical Implementation Guides (STIGs) by The United States Department of Defense specify how government computers must be configured and managed.
Payment Card Industry Data Security Standard (PCI DSS) must be followed by anyone who is handling credit card information and payments. It is a proprietary information security standard for organizations that handle branded credit cards from major card schemes.
The Health Insurance Portability and Accountability Act (HIPAA) sets the standard for sensitive patient data protection. Companies that deal with protected health information (PHI) must have physical, network, and process security measures in place and follow them to ensure HIPAA Compliance.
There is no need to be a security expert to deploy a security policy. You don’t even need to learn the SCAP standard to write a security policy. Many security policies are available online, in a standardized form of SCAP checklists.
Unfortunately, there is no universal security policy that could be applied everywhere; each organization has different needs and different security requirements. Before applying a security policy, it is necessary to think about your needs and go through the available offerings.
About the author
Sumeet A Kachhwaha is a Senior Technical Account Manager in Singapore. He has extensive work experience in the FSI Sector in the streams of DevOps and apps design and development. He has certifications in OCP, AWS, PMP, PSM, and ITIL.
At Red Hat, Kachhwaha supports business environments for banking and airlines customers that have presence in APAC. His primary focus is helping customers successfully adopt Red Hat OpenShift Container Platform.