BoD and C-Level Series: Software Vulnerability Reporting and Risk Management
- Mar 29, 2022 6:33 pm GMT
This is another article aimed at providing BoD members and C-Level executives with an understanding of some key concepts used in cybersecurity and, in this case, specifically software supply chain vulnerabilities and risk management. An analogy, using a food recall is used as an example, from a fictitious company called Mayonaizz Gourmazz.
Mayonaizz Gourmazz is the market-share leader of gourmet mayonnaise products, 7 out of 10 households claim to use their top selling product, Gatsby’s Gold Mayonnaise. In the summer of 2020, while Covid-19 was surging, Mayonaizz Gourmazz issued a food recall for Gatsby’s Gold Mayonnaise product produced during the period 4/1/2020 and 4/2/2020. A public food health warning was issued for Gatsby’s Gold Mayonnaise indicating that salmonella poisoning had been reported, resulting in a fatality, and anyone with Gatsby’s Gold Mayonnaise should immediately stop consuming the product and discard whatever jars are on-hand that were produced between 4/1/2020 and 4/2/2020, to prevent the ill-effects of salmonella poisoning. An egg supplier to Mayonaizz Gourmazz was reported to have suffered an out-break of salmonella poisoning in a batch of eggs supplied to Mayonaizz Gourmazz and a food recall was required.
A similar scenario can occur with software products, in the form of “reported vulnerabilities”. This correlates well with a similar scenario affecting software:
Mayonaizz Gourmazz is analogous to a Software Supplier
Gatsby’s Gold Mayonnaise is analogous to a Software Product
The period 4/1-4/2 is analogous to a Product Version
The egg supplier is analogous to an open-source component that was used to build the Software Product – this external component contains the reported vulnerability that affects the software product
The label on a jar of Gatsby’s Gold Mayonnaise is analogous to a Software Bill of Materials (SBOM) that accompanies a software product. The SBOM contains the information needed to determine if the affected third-party component and the impacted software product are present in the software customers digital ecosystem.
The food recall is analogous to a software Vulnerability Disclosure Report (VDR) issued by a software vendor. These VDR’s come in several formats from software vendors, such as security bulletins that must be manually read and processed to determine risk levels. There is broad interest in moving toward the use of “automated” vulnerability reports in order to quickly, and efficiently determine risk level whenever a new vulnerability is reported.
This article explains how SBOM, combined with automated vulnerability reporting enables more rapid risk assessments, reducing the amount of time hackers have to carry-out their nefarious attacks. Today, the predominant use of manual cybersecurity bulletins provides hackers with ample time to find vulnerable sites, which become targets, that frequently results in a successful cyber-attack. The use of automated vulnerability reporting techniques can reduce the “susceptibility” window from days to minutes, reducing the likelihood of becoming a victim of cyber-crime.
Automated vulnerability disclosure reports for software are still evolving and standards are being considered, but much work remains. There are open-source, free to use automated vulnerability disclosure reporting solutions available that provide implicit vulnerability disclosures, i.e., CycloneDX VEX, which lists only those SBOM software components that have known vulnerabilities and explicit vulnerability disclosures, SBOM VDR, that lists each SBOM component along with the vendors vulnerability search status showing components that have no vulnerabilities and those that have vulnerabilities. SBOM VDR provides proof that a software vendor did indeed check each SBOM component for risks resulting in greater consumer confidence that the software has been thoroughly researched. Software consumers use a vulnerability disclosure to answer the question “What is the vulnerability status NOW for a given software product and version from a Supplier?”, before procurement and before consumption/installation. Let’s use the analogy to see how this might work on a jar of Gatsby’s Gold Mayonnaise.
Imagine you’re walking down the grocery store aisle and you stop to pick-up a jar of Gatsby’s Gold Mayonnaise. How do you know if this jar of mayonnaise is part of the food recall, before you purchase? One way this could work is to have a QR-code on the jar of mayonnaise that can be scanned to produce a report of “known food recalls as of NOW” for the product. Information about the specific product, version and supplier are encapsulated in the QR code so that you receive only the most relevant information about the risks of purchasing the product. The report comes back clean so you purchase the jar of mayonnaise and put in in your cupboard, to be opened after your current jar is empty. In one week you need to open the new jar of mayonnaise to replace the empty jar. Before you open the jar to consume the mayonnaise it would be a good idea to check for any new food recalls, to prevent from getting sick. You scan the QR-code to search for “known food recalls as of NOW” and sure enough, this jar of mayonnaise has a reported food recall, this tells the consumer that this product should not be consumed, saving the consumer from the ill-effects of possible salmonella poisoning.
Discussions are underway in the SBOM technical community to add a “link” to an SBOM that serves the same purpose as the QR-code in the analogy, where a software consumer can “click the link” to get the most current vulnerability report for a given software product and version, NOW. This enables a software consumer to check a software product for risks and vulnerabilities prior to procurement and prior to installation, just like the analogy shown, there can be a significant time differential between purchase and consumption/installation of software. It's best to check for risks before buying and before installing.
BoD members and C-Level executives should ensure that an organization is following best practices, as defined by NIST and CISA, when it comes to software risk management. Business practices and policies must require that each software product come with an SBOM so that an organization can quickly search for affected products, when a new vulnerability is reported. Each organization should follow policies and best practices that check a software product for risks, prior to purchase and prior to installation in order to identify risks before they can manifest into harm and business disruptions that accompany a successful cyber-attack. An NTIA compliant SBOM and automated Vulnerability Disclosure Report (SBOM VDR) are needed to perform an efficient, and rapid risk assessment, when new vulnerabilities are reported. Evidence of software risk assessments performed before procurement and before installation will provide the materials needed during an audit event or other cases to show conformance with Company cybersecurity policies and practices.
[UPDATE 4/25 Lawsuits The judge decided “the allegations of underlying security issues (such as the ‘solarwinds123’ password breach)” need not suggest that these security issues directly caused the loss. Instead, their purpose is to demonstrate that the executives were at least reckless in not realizing that something was dangerously amiss. “An egregious refusal to investigate may give rise to an inference of recklessness.” ]
No discussions yet. Start a discussion below.
Get Published - Build a Following
The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.
If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.