The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 

Post

9 ½ years!

Tom Alrich's picture
Supply chain Cyber Risk management - emphasis on SBOMs and VEX documents Tom Alrich LLC

I provide consulting services in supply chain cybersecurity risk management and am now primarily focused on software bills of materials (SBOMs) and VEX (Vulnerability Exploitability eXchange). I...

  • Member since 2018
  • 342 items added with 103,784 views
  • Aug 8, 2022
  • 258 views

 

Fortress Information Security (a company with which I have a consulting relationship) has been analyzing a lot of SBOMs lately. They recently showed me the results of their analysis of the components in a particular security product (which one hopes would have better security than most software products). They were careful not to tell me that these results are somehow typical of the “average” software product, since determining that would require a much larger, controlled study. But they did say they’d examined a number of other products whose analysis yields similar results.

They had other statistics in their report, but what struck me most were the figures for “vulnerability age” – i.e., the number of days since the vulnerability was published (which I assume means when a CVE number was assigned to the vulnerability). The report said:

  • There were 19 vulnerable components in the product (i.e., they had at least one open vulnerability. I didn’t see the total number of components, but I’m assuming it’s a lot larger than that). Since there were 141 total vulnerabilities, this means there were about 13 unpatched vulnerabilities per component. That’s a lot.
  • Since the top 10 vulnerable components each had 5 open vulnerabilities, this means the 141 vulnerabilities must have been fairly evenly distributed among the components, with a lot of 5s, 4s, etc. It’s not like one or two bad actors were making the other 17 or 18 components look like slouchers. They were all bad actors, or at least not good ones.
  • Vulnerabilities were grouped by severity, based on their CVSS score category: low, medium, high or critical.
  • There were five low-severity vulnerabilities. Their average age was 2801 days or 7.67 years.
  • There were 61 medium-severity vulnerabilities, whose average age was 2,987 days or 8.18 years.
  • There were 2 high-severity vulnerabilities, whose average age was 3,058 days or 8.37 years.
  • There were 9 critical vulnerabilities, whose average age was 3,447 days or 9.44 years. In other words, the most serious vulnerabilities were the oldest, with the average serious vulnerability having been identified 9 ½ years ago.

Here are my conclusions from this data:

  1. Keep in mind that, if a vulnerability has been outstanding for 8 years but the component that contains the vulnerability wasn’t included in the product until yesterday, then the vulnerability in that product is one day old. Of course, unless this is a brand new product (which it’s not), at least some of the vulnerable components must have been in it for years.
  2. Also, keep in mind that these numbers probably haven’t been adjusted to remove non-exploitable vulnerabilities. Thus, the number of exploitable vulnerabilities could be expected to be much smaller than the 141 figure for instances of component vulnerabilities. It’s possible that, if Fortress had asked the product supplier about those 141 instances of vulnerabilities, they might have said something like, “We knew all along that (e.g.) only two instances of component vulnerabilities were exploitable and we immediately patched those, so the 141 that you see are all not exploitable.” It’s possible they’d say this, but I doubt it.
  3. If a component vulnerability has been around for more than say a year, one would hope the supplier would patch it, even though they still don’t believe it’s exploitable. After all, there are ways in which a component vulnerability that has been deemed non-exploitable by the product supplier might suddenly become exploitable, such as a code change that inadvertently made the vulnerability exploitable. So even if those 9 ½ critical vulnerability instances aren’t exploitable, they should have been patched long ago anyway.
  4. I don’t understand why the age goes up with component severity. One would generally think that the highest-severity vulnerabilities would be patched as soon as possible, not left to molder for years.
  5. Since it’s unlikely that the supplier acquired most of their components around 8 years ago, this means the creator of the component (and most were probably open source projects, since 90 percent of components are open source) probably sat on open vulnerabilities for years, before the supplier of the product that Fortress analyzed acquired or downloaded it. Hmm… that doesn’t say a lot for component suppliers, does it?
  6. However, since the supplier of the product hopefully didn’t acquire all their components yesterday, the fact that at least some of these vulnerable components were sitting in the product for years doesn’t say much for the supplier either, does it? Remember, this supplier makes a security product (in fact, one that’s advertised a lot in the ICS space). Who cares whether or not a security product is itself secure? It seems this supplier doesn’t…
  7. What I found most amazing is that the lowest average age for a component vulnerability is more than 7 ½ years. I would have guessed it would be, say, no more than one year – and even that seems like a lot to me.

Bottom line: If I were a user of this product and I learned that the majority of component vulnerabilities were known at least 8 years ago yet still hadn’t been patched, I would ask, “Does this supplier even look at component vulnerabilities, let alone patch them?” My conclusion would be, “Probably not.”

In 2017, Veracode performed a study[i] in which they found that “A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.”

I’ve always thought that this was a nice “before” quote, to be contrasted with the much-improved “after” quote from say last month. Certainly (I told myself), software suppliers’ practices would have improved a lot since 2017. I guess I was wrong.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

Tom Alrich's picture
Thank Tom 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.
More posts from this member
Discussions
Spell checking: Press the CTRL or COMMAND key then click on the underlined misspelled word.
Matt Chester's picture
Matt Chester on Aug 8, 2022
  • There were 9 critical vulnerabilities, whose average age was 3,447 days or 9.44 years. In other words, the most serious vulnerabilities were the oldest, with the average serious vulnerability having been identified 9 ½ years ago.

 

So much for 'staying 2 steps ahead of the bad actors'!

Mark Silverstone's picture
Mark Silverstone on Aug 12, 2022

Can you give us an idea of the kinds and levels of risk that these vulnerabilities present? Are we talking about hardware shutting down? Loss of process control? Slight risk? High probability risk?

Tom Alrich's picture
Tom Alrich on Aug 17, 2022

Thanks, Mark. The actual risk to any organization depends entirely on what the software (or intelligent device) is used for. If it's used to operate the office football pool, I'd say a breach would have low impact and thus low risk. If it operates a machine that could blow up and kill people if misoperated, it's high risk.

Since the software analyzed by Fortress is a widely-used cybersecurity tool, a breach of the software could then lead to a serious breach of the organization itself, so it might be high impact and high risk. It's up to each organization to determine the level of risk in their environment.

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 »