Hi Christian,
Thanks for your review. To summarize:
* You are concerned about a lack of a "MUST" for authorization for the
information.
* You are concerned that a device might need to run a web server.
* The use of the term "some network environments" is vague.
To address your second point first, it helps to keep in mind that what
is described in this draft is not a retrieval mechanism but a
*discovery* mechanism. The device does not at all need to offer an
SBOM, in which case Internet-based retrieval methods are offered. I
agree with you that devices should not offer a web server for this
purpose alone for the very reasons you state, and would be happy to
make that clearer.
The reason we use "MAY" is that there is a philosophical difference
within the SBOM community about whether the information should be
freely available. Here is the argument for the information being
freely available, at least in some circumstances:
* There are many reasons for this, and the circumstances vary widely.
For commonly used CPE that is almost entirely based on OpenWRT, what
precisely does one think on is hiding, given that one can easily
scan either the source or a docker image? On the other hand, for an
MRI scanner that uses a modicum of OSS, whose images are encrypted,
then yeah, maybe security through obscurity will work for a while.
Those two examples are poles, with many devices fitting in the
middle. To be clear, if the software/firmware image is accessible
in any way, a fairly accurate SBOM can be generated by the attacker.
* As to attacks at scale, if the information is authenticated and
authorized – at scale – we must assume that it will leak to the
attacker, leading to information asymmetry in favor of the attacker,
at scale.
Your argument goes the other way, and I won't recapitulate it. In the
end, only deployment experience will help us understand which approach
is better. The draft doesn't take a position on any of this. Since
it's simply a discovery mechanism, it is entirely up to the
implementation to decide what authentication and authorization model
to use with the underlying substrate.
With regard to "some network environments" text, I agree with you that
is poorly written. The nature of the device as mentioned above is
probably more the issue. I'll try to come up with better wording.
Regards,
Eliot
On 16.09.22 00:36, Christian Huitema via Datatracker wrote:
Reviewer: Christian Huitema
Review result: Has Issues
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.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
