Early Review of draft-ietf-opsawg-sbom-access-09
|Requested revision||02 (document currently at 18)|
|Team||Security Area Directorate (secdir)|
|Requested by||Joe Clarke|
|Authors||Eliot Lear , Scott Rose|
|I-D last updated||2022-09-15|
Secdir Early review of -09
by Christian Huitema
Yangdoctors Early review of -02 by Ebben Aries (diff)
Genart Early review of -03 by Russ Housley (diff)
Opsdir Early review of -03 by Niclas Comstedt (diff)
Secdir Last Call review of -14 by Christian Huitema (diff)
The authors have requested a specific review from SEC DIR and YANG Doctors. On the security side, a look at veracity of the SBOM vulnerability proposal in additional to its general usefulness. On the YANG Doctors side, Eliot has said he regularly makes YANG mistakes so guidance would be appreciated.
|Request||Early review on draft-ietf-opsawg-sbom-access by Security Area Directorate Assigned|
|Reviewed revision||09 (document currently at 18)|
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.