Re: [Suit] How are firmware and firmware versions expressed in manifest?

[Dick Brooks <[e-mail]>]

I agree with Eliot on this point “I like the concept, because in industrial much of the tooling is already flagging quite a lot of false positive CVEs.”

 

The current vulnerability reporting domain has a very poor signal/noise ratio (lots of false positives) and the latency between vulnerability discovery and CVE data repository awareness can be significantly longer than it should be to effectively mitigate a vulnerability.

 

This is perhaps the biggest problem I’m facing, making it difficult to determine an accurate trustworthiness level (score) for a software object.

 

I have to agree; MUD – what were you drinking when that became the best choice?

 

Thanks,

 

Dick Brooks



 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Suit <[e-mail]> On Behalf Of Eliot Lear
Sent: Tuesday, June 09, 2020 5:27 AM
To: Hannes Tschofenig <[e-mail]>
Cc: Michael Richardson <[e-mail]>; [e-mail]
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

 

Hannes





On 8 Jun 2020, at 13:27, Hannes Tschofenig <[e-mail] <mailto:[e-mail]> > wrote:

 

I have to look at the links Eliot shared but I hope that people are not overly excited about the value of having information about what software version is on their devices for the purpose of drawing security conclusions. You have been at many hackathons where we created firmware for Cortex M-class devices and we used, for example, Mbed TLS in many instances. Does this tell you anything about the security? Can you draw conclusions when you hear that version X has a security vulnerability? Should you be concerned when a security researcher was able to mount a fault injection attack against a specific MCU with a specific version of Mbed TLS running on it? No, not really because you have to know what compile-time configurations were used to build the firmware, what hardware it is running on and what run-time configuration is present.

 

Actually, the people who should be concerned are the manufacturers, who are going to receive calls from customers who have learned that the manufacturer used EmbedOS but didn’t know that the option in a particular device is disabled.  This is an aspect of SBOMs that is understood to be problematic, and so discussion is gradually shifting to something they call Vulnerability EXchange (VEX) (I hate the name, but as someone who created something called MUD I have no real leg to stand on).  The idea behind VEX, fuzzy as it is, is that one would be able to query to determine if the manufacturer has investigated and affirmatively determined whether a particular product has a particular vulnerability.  I like the concept, because in industrial much of the tooling is already flagging quite a lot of false positive CVEs.

 

Eliot