We'll drop SBOMs on UK.gov to solve Telecoms Security Bill's technical demands, beams Cisco

Britain's Telecoms Security Bill will be accompanied by a detailed code of practice containing 70 specific security requirements for telcos and their suppliers to meet, The Register can reveal. The Telecom Security Bill (TSB), which is near the end of its journey through Parliament, has been rather unpopular with some ISPs who …

[Primus Secundus Tertius]

Manage risks and money

"...the pragmatic risk management of these things"

I.e. it costs money so ignore it.

[Clausewitz 4.0]

Congrats, Responsible approach

I would say the childs are growing up.

Instead of banning an equipment or supplier with FUD talking for geopolitical purposes, ask for a fix to the identified weakness.

The world is indeed changing.

[Pascal Monett]

Oh really ?

"There's always that risk that customers come to you and say, I can't possibly buy your product, because you've got maybe one version out of date of OpenSSL. "

Are you trying to make me believe that you have customers that actually check out the technical aspects of your product before buying it ?

Because that would be a first, in my experience. Generally, the customer buys the product, then finds out what doesn't work and IT has to spend time (and possibly money) to solve the issue. Then the manager responsible can strutt his stuff in front of the Board and boast about how he made incredible gains for the company.

[Anonymous Coward]

Re: Oh really ?

It's a long shot to say any of them would even understand (the consequences of) the statement:

"The Chinese firm was, among other things, using "70 full copies of 4 different OpenSSL versions" which contained 10 "publicly disclosed" vulns, some "dating back to 2006".

And said in a tone, as though Cisco itself doesn't have any dirty laundry.

[Anonymous Coward]

Re: Oh really ?

We've actually had quite a number of customers who ask us to complete security inquiries that include numerous technical details, and more than a few who scan product installations for third-party components with known vulnerabilities. It's becoming common in the enterprise-software market.

[Mike 137]

And so we have churn

"It might not be vulnerable, but... it's out of date, therefore it must be bad..

How many folks question whether the newest version could also be "bad"? More often than not it's proven to be, or we wouldn't constantly need new versions.

[Michael Wojcik]

Re: And so we have churn

So we should ignore updating, because there's no difference between a version with both published and unpublished vulnerabilities, and a version with only unpublished ones?

If refraining from using computers at all fits your needs and threat model, then by all means feel free to do so. Otherwise your objection has no practical value.

[tip pc]

SBOMs as a security management concept have come in for some criticism recently because they could create the illusion that picking (for example) one specific software library and saying "job done, it's secure" doesn't set the expectation that the library will need updating in future.

This kind of problem was endemic in Huawei's mobile network equipment firmware, as NCSC's Huawei examination cell revealed in 2019. The Chinese firm was, among other things, using "70 full copies of 4 different OpenSSL versions" which contained 10 "publicly disclosed" vulns, some "dating back to 2006".

Referring to the TSB, Cisco's Jackson illustrated the SBOM problem from the vendor's perspective:

There's always that risk that customers come to you and say, I can't possibly buy your product, because you've got maybe one version out of date of OpenSSL. It might not be vulnerable, but... it's out of date, therefore it must be bad. And you then end up with a really difficult conversation from a commercial perspective as to how you manage those things and get down to the pragmatic risk management of these things.

So because the conversation might be difficult they choose to ensure its not even contemplated buy steering conversations away from it.

if they have some super duper mitigation that makes it safe to include vulnerable libraries then they should speak up.

[Anonymous Coward]

Yet another checklist

This has all the makings of another checklist like some of the infamous ISO checklists.

SBOMs are a snapshot in time and can be out of date in weeks, if not days. But I would assume every vendor will use them and the TSB will accept them.

[Anonymous Coward]

Misdirection from Cisco (again)!

Quote: '.....there are "no undocumented administrative mechanisms"...'

*

Logic failure: how do I test for "the absence of a feature" within some huge binary image?

*

Oh....I see now....Cisco will give me a letter saying that "the product complies"......with a matching certificate from the NSA!!!!

*

I need to take a look at the Snowden papers again!!