This group brings together the best thinkers on energy and climate. Join us for smart, insightful posts and conversations about where the energy industry is and where it is going.

Post

One more reason why the industry needs to synchronize SBOM standards and CVE reporting

image credit: Author Logo

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 [1], 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.

 

     

      Discussions

      Tom Alrich's picture
      Tom Alrich on Nov 16, 2020

      Thanks for posting this, Dick! I haven't read the article yet, but your summary shows why it won best paper.

      Richard Brooks's picture
      Richard Brooks on Nov 16, 2020

      Thanks, Tom. The author identified several issues that I've encoutnered running risk assessments with SAG-PM, that make risk management very challenging; i.e. Multiple representations of vendor names and product names in CVE's. I like that the authros used empirical data from ICS-CERT to raise awareness to these issues; this tells me that systemic problems exist today and these must be addressed in order to improve vulnerability and risk management effectiveness across the industry. We're all familiar with GIGO; here we're looking at Garbage In = Higer Risk (GIHR) and that's not good.

      Matt Chester's picture
      Matt Chester on Nov 16, 2020

      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

      Is this an issue of installations being pushed out before they're ready, or is this to be expected because software providers will virtually never catch 100% of vulnerabilities until the packages are out in the field and 'tested' in that way? 

      Richard Brooks's picture
      Richard Brooks on Nov 16, 2020

      Matt, the authors don't delve into causation. They focus on finding and reporting the problems that exist, but don't go into great detail about why or how the problems came into existance, except to cite the potential for human error in the CPE process. 

      Richard Brooks's picture

      Thank Richard for the Post!

      Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.

      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.

                       Learn more about posting on Energy Central »