Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

[Toerless Eckert <[e-mail]>]

On Fri, May 28, 2021 at 06:08:27PM -0400, Michael Richardson wrote:
>     > Can not quite parse this. Rephrase pls. I was just thinking about known
>     > exploits for specific software versions as the reason for not making
>     > the SBOM available to anyone who asks.
> 
> The need for all entities in all sorts of supply chains to know exactly what
> possible issues there are.
> This will lead to many audits, mandated by national security concerns.
> Manufacturers who feel shy about revealing what they used, will find themselves
> with multiple month delays at borders.
> I also think that we are going towards mandatory disclosure of all breaches.

Thanks. Interesting. And agreed.
But i think this is mostly orthogonal to the problem at hand unless the manufactur
could really track software changes performed by users. And i would guess
at least in th IETF there seem to be enough participants trying to minimize
tracing by vendors.

>     > I ran into that problem i think
>     > more than a decade ago when customers asked to not have software
>     > version be included in LLDP information freely available to anyone on
>     > the same LAN. Such as the virus infested employee PC whereas that virus
>     > would hen easily find attackable network equipment. Not much different
>     > when there is a well-known URL that such attacking systems could probe.
> 
> Right, "Think about the children".

I think it is "think of the children" (https://www.youtube.com/watch?v=RybNI0KB1bg)

> So, now IT can't find the vulnerable PC either.

There are enough other mechanisms. And of course, if all this information was
broadcasted into a trusted domain like ACP, the story would be different.

> The malware never needed or cared about the LLDP version.
> What's the proof?  The presence of virus infected PCs.

Well, the more info an attacker has, the less probing it needs to do, and the
less probing it does the less its catched by heuristic, oops, artificially
intelligent, IPS.

>     >> We also already know how to integrate MUD with BRSKI, and this
>     >> connects MUD with SBOM, so really, I don't think we need more.
> 
>     > So tell me, how do you think a registrar would be able to include SBOM
>     > information in its decision whether to, or what certificate to give to
>     > a pledge during the EST enrollment. I don't see a solution for that
>     > without a solution like he one i proposed.  I may of course be missing
>     > something.
> 
> Because SBOM is just an attribute that is part of remote attestation.

Thats fine. I agree that we should look into an optional remote attestation
step after upgrading the TLS connection and before handing out keying materials.
I guess i need to read up more. Rats ?! ;-)

Cheers
    Toerless

> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
[e-mail]