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 Disclosure (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: 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: NIST NVD, CISA
• 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: Authorized parties with the knowledge, skills and expertise to provide accurate information pertaining to the technical details and risk impacts from an exploit/vulnerability
• 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.

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: Software Vendors
• 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

SBOM Vulnerability Disclosure Report (SBOM VDR) (click link for details)

• 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: Software Vendor
• 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 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.