Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-sbom-access-09

[Michael Richardson <[e-mail]>]

Christian Huitema <[e-mail]> wrote:
    > 2) I am not concerned about the disclosure of software vulnerabilities
    > per software versions, but I am still concerned about the inventory of
    > devices. Especially if there is an easy way to query devices and find
    > what software version they are running. Attackers are going to love an
    > automated way to find out which devices run what vulnerable version.

Let's remember that this is an extension to *MUD* (RFC8520) to embed an SBOM pointer.

So in order for a passive attacker to see the pointer, they have *already*
seen the pointer to the MUD.   To date, MUD doesn't specify a way to load the
MUD from the device itself without embedding the IP of the device in the URL.
( https://datatracker.ietf.org/doc/html/draft-jimenez-t2trg-mud-coap-00
proposed a self-reference though)

If the MUD file is version of firmware specific,
  see: https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-05.html#name-updating-the-mud-files-in-p
  for a discussion of when/how one might change the *MUD* URL when the firmware
  changes)

then the attacker does not even need to read the SBOM, or have one
present, to know what software version the device is running!

If the SBOM is self-hosted, then the device gets to answer correctly about
its versioned SBOM.  If the SBOM is hosted by the vendor, then the URL in the
MUD will need to change when the version changes, and this might mean that
the MUD URL also has to change.

So what I'm really saying is that the ship has already sailed with RFC8520.
An attacker really does not need the SBOM to find out what MUD capable
devices are present, and potentially which versions of firmware they are running.

It's not trivial to get the MUD URL out of a device though.  You can't really
just knock.  LLDP is pretty hard to do unless you are directly connected at
L2 as the switch, but I suppose it might be possible to get it over WiFi.
(I never tried)
The MUD URL shows up in DHCP requests, and they can be observed when they are broadcast.
The IDevID location for MUD URLs is usually only present by observing some
TLS (1.2) handshake, perhaps as part of BRSKI.

In summary, getting an automated way to find out which devices are vulnerable
to attack is going to help the defenders far more than it helps the
attackers.

But, I did agree that unconfigured devices which have not been onboarded with
an administrative credential should not answer queries about their SBOM.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-