In the past 3-4 years, NIST has produced a dizzying array of guidance documents for IoT security. This isn’t because they can’t make up their minds. It’s because: a) the IoT marketplace has been going through rapid change, and b) NIST has been ordered to undertake at least two “regulatory” mandates for IoT (in the IoT Act of 2020 and the IoT device labeling program mandated by Executive Order 14028), even though they’ve never been a regulator. The mandates changed multiple times after they were given to them; in both cases, they’ve finally been withdrawn from their purview.
Thankfully, now NIST’s duties regarding IoT seem to have returned to their traditional role, which they are quite good at: developing risk-based cybersecurity frameworks that are mandatory for the federal government and merely advisory for the private sector. The end product of the various NIST documents and initiatives regarding IoT security in the past few years is a new Interagency Report: NIST.IR 8425.
This is a very good document, and it was worth the many interim documents, workshops, etc. that led to it. Don’t get thrown off by the fact that it’s titled “Profile of the IoT Core Baseline
for Consumer IoT Products”. “Consumer” is in the title because these were originally intended to be the guidelines behind the device labeling program in EO 14028, not because the NISTIR only addresses security of consumer (i.e. household) IoT devices.
The recent workshop at the White House showed that that they now have a better idea for the device labeling program. They would like the FTC to run the program, although whatever criteria they use for assigning the label will almost ccertainly be NIST's - probably NIST.IR 8425. The FTC is a logical choice to run the program, since they're responsible for enforcing other regulations regarding the trustworthiness of products sold in the US, as well as the truthfulness of claims made about them by their manufacturers.
This move by the White House freed NIST to take the guidelines they’d published in February for the device labeling program and turn them into their final set of guidelines for both business and consumer (i.e. household) IoT products. NIST did this with only minor changes to the document, based in part on comments they’ve received since February
The fact that NISTIR 8425 is intended to address both consumer and business (i.e. commercial and industrial) products is made clear at the beginning of the Abstract on the first page. The first sentence states that the publication “…identifies cybersecurity capabilities commonly needed for the consumer IoT sector (i.e., IoT products for home or personal use)”. However, the second sentence reads, “It can also be a starting point for businesses to consider in the purchase of IoT products.”
With the words “starting point”, NIST is clearly leaving the door open for more extensive business-oriented guidelines in the future. Any businessperson who yearns for more extensive guidelines today can always go back to NISTIRs 8259A and 8259B, both of which are good documents and go beyond what’s included in NISTIR 8425 (in fact, most of the guidelines in 8425 were selected from 8259A and B).
But NIST’s choice of words means that businesses wanting to base their IoT program on a recognized framework (at least, recognized in the US) would do well to follow NISTIR 8425 now, since any further NIST guidelines for business IoT are likely to build on that, not replace it. This applies both to manufacturers of IoT and IIoT devices that are designing new products or
beefing up security on existing products, and to commercial and industrial firms that are looking for guidelines they can use to assess the security of the devices they buy.
There’s another use case for NISTIR 8425 in those commercial and industrial firms: as the basis for contract language. But please do me a favor: Before you write a contract term that reads something like, “Vendor must comply with NISTIR 8425”, keep in mind that “comply” is a meaningless term when it comes to this document (and to most other NIST documents).
For example, look at the first requirement in the “Data Protection” section on page 7: “Each IoT product component protects data it stores via secure means.” Of course, there are lots of ways to “protect data” by secure means. Which one should the manufacturer implement in the device?
That will very much depend on the destination of the device. If the device is for dry cleaning establishments, its security requirements can be much less strict than if it were going into, for example, a nuclear power plant. A device intended for a nuclear plant would probably need to employ the latest encryption technology to secure the data stored by the device, while a device
intended for a dry cleaner might not need encryption at all. For them, just requiring the user to enter a password when they first log into the device might be all the protection required.
This is why simply asking a device manufacturer for “compliance” with NISTIR 8425 will never work. Instead, the term might read, “Vendor shall be prepared to provide evidence that they have implemented a product risk management plan based at minimum on the guidelines provided in NIST.IR 8425” – or something like that. That way, the manufacturer will be assessed on whether it is taking steps in each area of capability listed in the NISTIR (there are ten “capabilities”, all but one of which have between one and three subordinate capabilities. The “Documentation” capability lists a large number of subordinate capabilities, which isn’t surprising).
However, there is one requirement that I think should be addressed by all device manufacturers, regardless of who their users are: They should register their device with the National Vulnerability Database (NVD) and report any vulnerability they learn of, in either the software or firmware installed in the device, as being found in the device (even though the
software vendor may have already reported the vulnerability for their software). It seems very few IoT manufacturers are doing this now; yet it is the only realistic way for users of a device to learn about the vulnerabilities found in it.
My reason for requesting this is described in the last section of this article, which I wrote with Isaac Dangana of Red Alert Labs. RAL is a client of mine that works with IoT manufacturers to secure their devices, and with IoT consumers to verify that the devices they buy are and remain secure. While the article officially discusses SBOMs for IoT and IIoT devices, the need to report vulnerabilities for the device itself has nothing to do with SBOMs. Rather, it’s needed so that IoT and IIoT users can properly secure their devices.
This blog has been published originally by Tom Alrich on Tom Alrich's blog.