Thank you for your review. I'm not an author, but an interested party. Christian Huitema via Datatracker <[email protected]> wrote: > attacks. It addresses a number of issues, which is good. But I my mind, > the first security issue is the possibility by attackers to use SBOM > and find vulnerable devices "at scale". The text in the security > section starting with "SBOMs provide an inventory of software" does > address the issue, but not with enough force and persuasion.
I understand your concern, but I think that anything that makes it harder to
identity and update devices will result in more unpatched devices.
Finding unpatched devices *at scale* is exactly why the white hats need this.
> SBOM with software, version and dependencies. Knowing the version, the
> attacker determine immediately which vulnerabilities have been patched
> and which have not, and thus which exploits might work. Of course,
We've had this argument over and over going back to the 1980s, where we
wondered if sendmail should tell you it's version number in the string.
> information by other means." Yes the attacker could use some form of
> fingerprinting, but that takes time and effort -- finding
The biggest problem today is that devices get plugged into networks, and
administrators do not know what they are. There is an extensive set of
(mostly proprietary) methods to fingerprint devices.
Yes, fingerprinting takes time and effort, but script kiddies don't bother,
they just launch attacks.
> vulnerabilities at scale is much more convenient. I would be much more
> forceful, such as having devices configured to not provide any
> information unless access control and authorization methods have been
> properly configured.
If you are arguing that devices which have not been properly onboarding
should not give out SBOM information, **then I can buy that**
That's not the same as hiding what they are via MUD file link.
> One specific concern would be naive deployments in which users plug
> devices but do not change the default configuration -- the classic
Yes, but that already bad practice to the point where we are close to having
regulatory enforcement, so let's not bring this up over and over again.
Such a device *ALSO* will not have an SBOM or a MUD file.
> In order to publish the SBOM, the devices must have a web server
> available or some equivalent, ready to accept queries from network
> manager. That means an open port, which in most cases will increase the
> attack surface on the device. That's another reason for requiring
> configuration of access controls before enabling publication of SBOM.
I strongly disagree.
Devices that already have an open port will self-host the SBOM that way,
and devices that don't have that open port (and server behind it) will put
the SBOM at a vendor hosted location.
> The reminder of the security section, addresses other threats, such as
> an attacker with control of the devices providing false information in
> the SBOM, or an attacker hijacking the manufacturer publishing site
The SBOM is usually signed by a third party.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
