Early Review of draft-ietf-opsawg-sbom-access-09
review-ietf-opsawg-sbom-access-09-secdir-early-huitema-2022-09-15-00

This is an early review of this document by the Security Directorate, as
requested by the WG.

The document is well written, but in my opinion the security section needs a
bit of work.

The document proposes to have devices publish a software bills of material
(SBOM) describing which software they run, what version, what dependencies.
Network managers could retrieve that information and then obtain from the
manufacturers the list of vulnerabilities in that version of the software. They
could use the information to isolate devices or force device software updates
quickly after a vulnerability is disclosed. This seems like a nice feature for
improving IoT security. But then, I am concerned that if not deployed
correctly, the same mechanisms could be used by attackers to degrade the
security of the IoT devices. I am also concerned that adding a service to
publish SBOM increases the attack surface on the device.

The security section is extensive but in my opinion would benefit from some
organization, such as clearly delineated subsections for specific 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, butnot with enough force and
persuasion.

Let's suppose an attacker that have access to the IoT, either because ports
were left open in a firewall or because the attacker has somehow breached the
perimeter. The attacker will obtain from the device the 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, attackers today could just throw
exploits at devices in the hope that one will work, but reading the SBOM makes
the attacks more efficient and stealthy. In short, without precautions, defense
at scale enables attack at scale.

The obvious defense is for devices to only provide such information if the
client is explicitly authorized. The text says that, but use MAY after
providing excuses such as "the attacker could derive the information by other
means." Yes the attacker could use some form of fingerprinting, but that takes
time and effort -- finding 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.

One specific concern would be naive deployments in which users plug devices but
do not change the default configuration -- the classic
user=admin/password=admin issue. The lack of configuration itself is bad
enough, but combining it with vulnerability detection at scale seems foolhardy.
The security section says that "to further mitigate attacks against a device,
manufacturers SHOULD recommend access controls." I would go further. Again, I
wish we recommended a default posture in which no such information is provided
until access control has been configured on the device.

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.

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 providing false
information about vulnerabilities, or directing devices to update their
software with attacker provided software. This is well written, but I am
concerned with weasel-words like "These data nodes may be considered sensitive
or vulnerable in some network environments." Which data nodes? What are the
environments in which the information becomes "not vulnerable" or "not
sensitive"? Is that a hidden reference to some kind of perimeter security? Do
WG members still trust perimeter security? Even if perimeter defense was
effective, we must be concerned lateral exploration after an initial break, or
usage of IoT devices as persistent beach-heads for further exploitation. Let's
be more direct, please.