Terminology Confusion Regarding Vulnerability Reporting

[UPDATE 1/16/2022 11:00 AM EST] There is a lively debate underway on this very topic over on LinkedIn. A proposal has been made to hold a bake-off over which automated SBOM Vulnerability Reporting format should be pursued that suggests software consumers provide the consensus position.

Many thanks to Allan Friedman of CISA for pointing out the many ambiguities that exist when it comes to vulnerability reporting. As Allan points out, the terms “Vulnerability Disclosure” have a very specific meaning in the cybersecurity world, which led me to write this article to help parties distinguish the various type of vulnerability reporting that are now coming into focus, largely with the help of Log4j.

METHODS FOR REPORTING SOFTWARE VULNERABILITIES

Vulnerability Report (click link for details) (a/k/a Coordinated Vulnerability Disclosure)

Timing: Event driven, when exploits prove the existence of a vulnerability
Recipient: Software Vendor and/or CISA
Reporter/Authoritative Author: Researcher that discovers the exploitable vulnerability and provides exploit code to demonstrate the vulnerability
Medium: Social-Media, Dark web, email or other form of private communication (preferred), i.e. CISA report form
Expected Response: Recipient investigates the exploit/vulnerability and distributes an analysis of their findings, in a responsible and efficient manner, to appropriate parties
Vulnerability Disclosure advice for Open-Source Developers is available online.

Common Vulnerabilities and Exposures (CVE) (click link for details)

Timing: Event driven, when exploitable vulnerabilities have been confirmed
Recipient: Public
Reporter/Authoritative Author: NIST NVD, CISA, CNA
Medium: email or other form of public communication, i.e. Website, NIST NVD Search; data is also available in electronic JSON format using NIST NVD API
Expected Response: Recipient investigates the CVE details using an automated (JSON processing) or manual process and initiates appropriate response based on risk analysis. This frequently requires software vendor interaction for installed software products

Security Bulletins (a/k/a Technical Advisory); Vendor specific, an actual Log4j security bulletin from Siemens and an actual Log4j security Bulletin from Schneider Electric are available at the links provided. NOTE THE EXTREME DIFFERENCES IN BOTH CONTENT AND FORMAT MAKING MANUAL PROCESSING AND CONSUMER RESPONSE SLOW, INEFFICIENT AND ERROR PRONE

Timing: As needed, usually after a software vendor or other entity, e.g. ICS-CERT, has investigated a Vulnerability Disclosure; frequently associated with a specific CVE ID
Recipient: Parties with an interest in knowing information about a software exploit or may be at risk of exploits
Reporter/Authoritative Author: Authorized parties with the knowledge, skills and expertise to provide accurate information pertaining to the technical details and risk impacts from an exploit/vulnerability, i.e. the Software Owner/Producer
Medium: Posted on a publicly accessible site, email, posted on customer portal with access control, in a vendor specific, proprietary format
Presently the most common method employed by software vendors to inform customers of software vulnerabilities affecting products and mitigation activities
Predominantly a manual process, but some entities provide programmatic access to the same information in proprietary electronic formats
Expected Response: Recipient reads/processes security bulletin and takes appropriate mitigating action if necessary to prevent exploitation

OASIS CSAF Vulnerability Exchange (VEX) (click link for details): NOTE CSAF HAS AN ALTERNATE PROFILE CALLED SECURITY_ADVISORY THAT APPEARS TO OVERLAP WITH THE VEX PROFILE: an example CSAF security advisory is provided by Siemens and CISA.

Many thanks to Thomas Schmidt, Federal Office for Information Security (BSI) Germany, for his help in understanding CSAF and VEX

Timing: Issued after a software vendor has investigated a Vulnerability Disclosure; may be associated with a specific CVE ID
Recipient: Parties with a vested interest i.e., software customers, in an exploit and may be at risk of exploitation from an installed software package
Reporter/Authoritative Author:: Software Vendors/product owners that can state a product is not affected by a vulnerability.
Medium: Electronic format communicated to customers, usually via file download from a customer access-controlled portal, but may also be publicly accessible
Expected Response: Recipient implements automated process to retrieve and process CSAF VEX artifacts and notifies appropriate personnel of elevated risk and other findings e.g, known not vulnerable
Predominantly an automated process with some manual involvement i.e., determining steps to plan and implement mitigations
Standard electronic format, defined within OASIS, CSAF; provides considerable benefits to improve risk assessment response time, if broad vendor adoption is achieved
Designed to provide software consumers with automated and improved risk assessment as an alternative to manual Security Bulletin reviews
Discloses vulnerabilities and vendor findings at a product level, with the ability to correlate to an SBOM URL

NIST SBOM Vulnerability Disclosure Report (SBOM VDR) (click link for details) per SP 800-161 RA-5.

Timing: Whenever an SBOM is distributed to a software customer
Update Frequency: Updated when a new exploitable vulnerability is confirmed by a vendor and/or when a VEX of CVE is issued
Recipient: Parties with an NTIA compliant (minimum elements) SBOM for an installed software product that may be exploitable by a newly reported vulnerability (CVE ID)
Reporter/Authoritative Author: Software Vendor/Product Owner with deep knowledge of product details that can assess the impact of all vulnerabilities that may impact single product.
Medium: Electronic XML format communicated to customers, usually via file download from a customer access-controlled portal, typically not publicly available
Expected Response: Recipient implements automated process to retrieve and process SBOM VDR artifacts when SBOM is initially released and whenever a new vulnerability is confirmed by a software vendor. Take appropriate actions based on a risk priority strategy
Implements ISO 29147:2018 standard concepts for "vulnerability disclosure", which states: "Vulnerability disclosure enables both the remediation of vulnerabilities and better-informed risk decisions. Vulnerability disclosure is a critical element of the support, maintenance, and operation of any product or service that is exposed to active threats. This includes practically any product or service that uses open networks such as the Internet. A vulnerability disclosure capability is an essential part of the development, acquisition, operation, and support of all products and services. Operating without vulnerability disclosure capability puts users at increased risk."
- Major goals of vulnerability disclosure include:
- — reducing risk by remediating vulnerabilities and informing users;
- — minimizing harm and cost associated with the disclosure;
- — providing users with sufficient information to evaluate risk due to vulnerabilities;
- — setting expectations to facilitate cooperative interaction and coordination among stakeholders.
Predominantly an automated process with some manual involvement i.e., determining steps to plan and implement mitigations
Open-source, free to use electronic format, provides considerable benefits to improve risk assessment response time, if broad vendor adoption is achieved
Designed to provide software consumers with automated and improved risk assessment as an alternative to manual Security Bulletin reviews
Implements rapid assessment flags to identify Unresolved Vulnerabilities at the SBOM (product) level and Exploitability at the component level
Discloses vulnerabilities, including CISA KEV's and vendor findings at an SBOM component level within a product SBOM
Supports both SPDX and CycloneDX NTIA supported SBOM formats in accordance with NTIA minimum elements for Executive Order 14028 implementations
An example SBOM VDR is available online

[UPDATE 1/13/2022] Many thanks to Tom Alrich for his article describing the CycloneDX CDX VEX option that was just announced this week (after publication of the initial posting of this article).

It is imperative for society to take the steps needed to protect ourselves from cyber-criminal and improve our risk assessment capabilities and response time when new vulnerabilities are discovered. Existing, labor intensive, slow and inefficient manual processes must be replaced with automation, as this excellent video by Ralph Langner points out: https://www.youtube.com/watch?v=c-RPUChayO4

Equally interesting to watch (3 hours) is the Congressional hearing on 1/11/2022 regarding updates to FISMA. Vulnerability Reporting is a top priority for government agencies.

I welcome all feedback, insights and additions that will improve the quality and/or completeness of this information, for the benefit of the Energy Central Community. Many thanks to Allan and Thomas for sharing their insights.