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
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
