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

It seems some suppliers aren’t that good at writing patches

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,778 views
  • Aug 17, 2022
  • 308 views

 

My brother Bill Alrich sent me this link this week, regarding a presentation at Black Hat last week. I’ll let you read it, but I find it appalling. The gist of it is that the quality of security patches is declining, so that more and more of them are bypassed. This means the supplier has to re-do the patch (and of course, their users have to apply the new patch), because the original patch didn’t really address the whole problem it was meant to address.

Why is this happening? It seems that suppliers, pressed for time and resources, are cutting corners by not spending the time required to look for the root cause of the bug and patching that. So a researcher (or an attacker, of course) can easily go around the patch, because they do have the resources to look for the root cause. Of course, when this happens, the supplier probably ends up spending more time on the vulnerability than if they’d done it right the first time, since they have to create two patches, not just one. It’s better to do a good job the first time…

But that’s easier said than done; I realize suppliers are under pressure from all sides. One thing that can help is they can consult with their customers and try to draw clear lines regarding which vulnerabilities are worth patching and which aren’t; then they shouldn’t be afraid to tell their customers (in a VEX, or just in an email), “This vulnerability doesn’t meet the severity threshold we agreed on, so we won’t patch it. Here are several steps you can take to mitigate the risk posed by this vulnerability…”

Of course, the problem is determining what that threshold should be. I’d like to say it should be a CVSS score above say 4.0; however, there are a lot of problems with CVSS scores in general, since they’re based on both exploitability and impact – but impact is very much dependent on the software impacted and how it’s used. Is it used to run the office’s March Madness pool? That’s probably a low impact use. But, how about if the software is used to run a process that could kill people if it’s misused? That’s a high impact use. Yet, the CVSS score would be the same in both cases.

Exploitability is a different story. The more exploitable the vulnerability, the bigger risk it poses (since its likelihood of exploitation increases, no matter how it’s used). Here, you have to remember that there are two types of exploitability, as discussed in this post. One is the exploitability that is described in a VEX document; it’s an absolute exploitability, based solely on the characteristics of the product itself. Either the vulnerability can be exploited or it can’t.

While some customers might object, if the supplier issues a VEX that says the status of the vulnerability – in one or more versions of the product – is “not affected” in a CSAF VEX or “unexploitable” in a CycloneDX VEX, IMO they’re justified in saying they won’t patch the vulnerability (although the supplier might offer a “high assurance” patching option for customers like military contractors or hospitals that want most vulnerabilities to be patched, period).

The other type of exploitability is what’s found in the EPSS score, discussed eloquently by Walter Haydock. This looks at such factors as the availability of exploit code and whether there have been exploit attempts. Of course, these have nothing to do with the product itself, but are applicable to all products and users. So a supplier might have a discussion with their users about a) whether EPSS score is good enough for the purpose or whether the users should construct their own score using some other combination of factors, and if so, b) what would be an appropriate threshold level.

This is why it’s dangerous to require software suppliers – especially in contract language – to patch all vulnerabilities. Sure they’ll develop a patch, but if someone is going to figure out how to bypass it in a week, was it really worth developing in the first place?

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.
Mark Silverstone's picture
Mark Silverstone on Aug 19, 2022

While I do not dispute your observations of the software industry.  I do often have trouble, however,  relating to the issues personally. I always ask: What do these software issues mean to me? What are the impacts on consumers?

I was reminded of this again today when I read an article about vulnerabilities of Apple`s Monterey Operating System. Here is a description of the problem:

"Reports indicate the patches may have been actively exploited, so users are urged to update as soon as possible.  One kernel vulnerability enabled an application to execute arbitrary code with kernel privileges. An out-of-bounds write issue was addressed with improved bounds checking. Reported under CVE-2022-32894 by an anonymous researcher."

Does that clarify the situation? Of course, I do not how urgent the upgrade really is. My local newspaper warned that hackers could take total control of the target computer. So, I decided to update my system.  I won´t describe the result in detail. Suffice it to say that it cost me hours on the phone and a trip to the local Apple store lugging my 20 lb. iMAC, because the software did not install properly and left me bereft of a working computer for a couple of days.  Thankfully, I eventually found someone who knew what to do and fixed the problem (It was far from obvious.).

So, no, I am not impressed with the software industry. How could they have made such errors? It´s as if they never tried out the software before they issued an update.

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

I'm sorry to hear about your problem, Mark. I think a good strategy would be to apply all security patches (and doesn't Apple push them out automatically? I never have to apply them from my Windows machine), but just apply functionality updates when you need the additional functionality provided by the update. The security patches are always separate from functionality updates, so you shouldn't assume that you need to apply an update to secure your machine.

My point is that you should trust Apple to decide which patches you need and which you don't, and let them "apply" the patches for you. But I admit I don't know much about Macs - ever since the Mac SE.

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 »