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 artifacts 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), ref: IEC 29147 and IEC TR 5895
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 researchers Vulnerability Report; 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) and Security Advisories (click link for VEX details): NOTE CSAF HAS A PROFILE CALLED SECURITY_ADVISORY (profile 4) THAT IDENTIFIES PRODUCTS THAT ARE AFFECTED BY A VULNERABILITY WHERE THE VEX PROFILE (profile 5) IDENTIFIES PRODUCTS WHICH ARE NOT AFFECTED BY A VULNERABILITY: 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 Security Advisories (profile 4) and VEX profile 5.
Timing: Issued after a software vendor has investigated and confirmed Vulnerability Report from a researcher; 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. A reporter issues a CSAF Security Advisory for products that are 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 and Security Advisory 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 vendor findings for vulnerabilities and affected/not affected products that the reporters is aware of (may not identify all affected products)
NIST SBOM Vulnerability Disclosure Report (SBOM VDR) (click link for details) per SP 800-161 RA-5 also described in IEC TR 5895 and FIRST.org Multi-party CVD that include notification to end users via a Product Vulnerability Disclosure Report created by a product manufacturer and communicated to customers
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 Security Advisory 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 or JSON 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
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
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.