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 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 report any vulnerability they learn of, in either the software or
firmware installed in the device, to CVE.org.
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.
Any opinions expressed in this
blog post are strictly mine and are not necessarily shared by any of the
clients of Tom Alrich LLC. If you would
like to comment on what you have read here, I would love to hear from you.
Please email me at tom@tomalrich.com.
No comments:
Post a Comment