One more reason why the industry needs to synchronize SBOM standards and CVE reporting
image credit: Author Logo
- Nov 15, 2020 5:30 pm GMTNov 15, 2020 6:15 pm GMT
- 795 views
On November 9th, 2020, the ACM hosted the CPSIoTSSec 2020 Workshop which contained several presentations that are germane to ICS/OT Cybersecurity practices within the energy industry. One talk in particular stood out in my mind, which happened to win the award for best paper; Catch Me If You Can: An In-Depth Study of CVE Discovery Time and Inconsistencies for Managing Risks in Critical Infrastructures, https://doi.org/10.1145/3411498.3419970
The main takeaway from this paper, for me, is further proof that we desperately need to align SBOM standards with CVE reporting systems, databases and operations, if we are to have any real, useful, ability to track vulnerabilities and manage the risks with installed software objects within a Grid Command and Control ecosystem. This paper is an eye opener and, best of all, IMO, the findings are based on empirical data and a proficient analysis and cross correlation of issues between CVE, CPE, CWE and CVSS domains that impact our ability to accurately identify and mitigate risks in software used in Industrial Control Systems (ICS)/OT throughout Grid Command and Control (e.g. SCADA and EMS). I encourage you to read the paper, it's full of useful information, or watch the 20 minute youtube video, but just in case you can't find the time, you're welcome to puruse my "CliffsNotes", below:
- The longer the vulnerabilities remain “in the wild” or a lack of consistency in vulnerability reporting, the greater the impact on Critical National Infrastructure operators’ ability to systematically understand and mitigate the risks.
- We find that, on average, a vulnerability is ‘in the wild’ for 5.3 years, and that many CVEs do not correctly reflect and state the affected devices as Common Platform Enumerations (CPEs). Based on our findings, we propose a set of guidelines to improve the reporting and consistency of ICS CVE information.
- OT systems typically remain unchanged for a number of decades after deployment, compared to typical IT refresh cycles of at most 5 years. Safety and management of process is pivotal within OT, whereas IT systems concern themselves with business continuity, a well-understood field with standardised security practices.
- Any vulnerability reported which could apply to an asset owner’s infrastructure must therefore contain actionable information at the right time. If there is any inconsistency or inaccuracy in that information, vulnerabilities may remain unaddressed in that infrastructure with potentially serious consequences if exploited
- inconsistencies in the CVE description could have a further impact. . If this information is flawed in any way, it is not possible to act and protect their infrastructure
- Our dataset is established from CVEs listed in US-CERT ICS Advisories, which tracks ICS-related vulnerabilities; we found many issues with the data quality. The largest issue is that of inconsistencies both within CVEs, and across different CVEs
- This leads to two research questions that we aim to answer:
- (1) How long are Siemens vulnerabilities “in the wild” before being discovered and assigned to a CVE?
- (2) How accurate is CVE information to an asset owner and how much does the information within CVEs vary?
- Resulting in the following outcomes:
- Analysis of the time a vulnerability existed ‘in the wild’ before CVE publication,
- A detailed review of CVE accuracy and how this can affect risk management in assets and infrastructure,
- Development of guidance to reduce vulnerability exposure windows and improving the accuracy of ICS vulnerability reports.
- most vulnerabilities were ‘in the wild’ for between 10 and 40 months
- Kaspersky Lab’s analysis of ICS vulnerabilities , found that 85% of vulnerabilities were patched or resolved, but 5% were only partly resolved, and 6% were not patched as the affected component was either no longer sold, or supported
- the average time to assess and assign a CVSS score to a CVE is 134.7 days. This delays the ability of an asset owner to understand the severity of the vulnerability.
- HOW LONG DO VULNERABILITIES EXIST BEFORE A CVE IS GENERATED?
- We find that, on average, vulnerabilities existed “in the wild” for 1897 days (5.2 years), with the maximum time between release and CVE publication being 5352 days (14.7 years) and the minimum, 115 days. In the worst case, a vulnerability was in the wild for up to 8152 days (CVE-2019-10936 and CVE-2019-10923).
- the longer a vulnerability persists, the installed consumer-base increases, with a higher number of potentially exposed devices requiring swift patching when a CVE is issued
- we observed a lack of consistency in the ways the same product and vendor were represented as a CPE vector. In some cases, the acronym of the vendor was used, e.g. ‘GE’ in place of ‘General Electric’
- For the two vendors, Schneider Electric and Phoenix Contact, there were 4 different representations each (including typographic errors). This demonstrates that these issues exist across vendors.
- When variations of how products are represented, there is a risk that an operator may miss critical vulnerabilities due to a mismatch in the expected CPE.