The White House held a workshop to discuss developing a program for securing IoT devices, scheduled to start in 2023 and to apply at first to two “particularly vulnerable” types of consumer devices: WiFi routers and home security cameras. What’s most important is how the device manufacturers will be motivated to comply with the program. Instead of threatening them with terrible consequences unless they meet certain cybersecurity requirements, suppliers will be “persuaded” to meet the requirements by the fact that, if they don’t do that, they won’t receive the device label that consumers will be trained to look for when they’re buying an IoT device.
In other words, the government will in effect warn the manufacturers, “If you don’t want to make any changes at all to your current security measures (or lack thereof), you’re free to follow that course. However, assuming we’re successful in making the public aware of the importance of looking for the cybersecurity label on any device they buy, you may find you don’t have as many customers as you might have been expecting.”
The news articles on the workshop made clear that the explicit model for this program is the Energy Star program, which uses a label to let consumers know which appliances meet certain energy efficiency standards. That program has been very successful.
Of course, a cybersecurity device labeling program is a fairly new idea. The most successful implementations of that idea so far have been in Singapore and Finland. Both of these are very small markets, so it’s not possible to draw real conclusions about what the program’s success means for the US. That being said, both programs have been successful, and Singapore’s has recently been extended to medical devices. Both programs require third-party testing in order to obtain the label.
Another country that has implemented a device labeling program is Germany. However, that label is an informational one. It indicates that the manufacturer attests they meet about five security requirements. If the manufacturer is willing to make these attestations, they will receive a label (the program is voluntary, so no manufacturer has to participate at all).
Admittedly, relying solely on attestations isn’t ideal, since the manufacturer could always lie. However, if the manufacturer suffers a breach and it becomes apparent that they had lied in one or more of the attestations, their label can be revoked. Since having attested falsely about their cybersecurity would undoubtedly reflect very negatively on the manufacturer, it’s reasonable to assume that most attestations will be truthful. If a manufacturer has terrible security, they won’t bother to apply for the label at all, but I strongly doubt they’ll lie to get it.
Note that this the meeting last week wasn’t the first time the White House has talked about an IoT device security labeling program. In Executive Order 14028 of May 2021, the WH ordered NIST to “…identify IoT cybersecurity criteria for a consumer labeling program…” within 270 days. Almost exactly on the 270th day, NIST published this document. It had two parts.
The first part was a set of “criteria” (i.e. requirements) for the device labeling program. In my review of a predecessor to that document in December (which remained mostly unchanged in the final version), I said I thought they were exactly what was required: NIST called them “outcomes-based” criteria and I would call them “risk-based”.
But the two terms are synonymous: The manufacturer is required to achieve a general outcome, but the exact steps by which the manufacturer does that are up to the manufacturer, and need to consider the level of risk posed by the device. That is, the steps a manufacturer needs to take for a security camera at a bank are more rigorous than what is required for a baby monitor, although the outcome might be considered the same. The post I just referenced discusses this idea in more depth.
The manufacturer also needs to consider the environment in which the device will be used. A nuclear power plant is inherently much riskier than somebody’s back porch, even though the same security camera might be used in both locations. Obviously, the security measures taken will be much more severe at the nuclear plant, even though the device being protected is exactly the same as the one on the back porch.
The second part of NIST’s February document discussed how the device labeling program would work. It listed three possible types of labels:
1. Informational, which isn’t based on an assessment, but simply provides information on security measures taken for the device (e.g., the German label referenced above)
2. Tiered, in which there are multiple levels at which the product can be evaluated. The level attained by the product is shown on the label.
3. Binary, which is essentially a “pass/fail” designation. NIST indicated in the document that they preferred this label type. Energy Star provides a binary label.
In my December post I noted that, while I don’t have a problem with a binary label per se, I do have a problem with trying to combine a binary label with outcomes-based criteria. The reason is simple: Outcomes-based criteria require the organization to tailor how they comply with the criteria according to the degree of risk posed by the device (also, by the environment). It will be up to the assessor to determine whether the manufacturer’s compliance actions were appropriate for the risk posed by the device and its location.
On the other hand, a binary label doesn’t allow for any considerations of risk or anything else, in determining whether the device deserves the label or not. The assessor needs to be able to make an up-or-down decision, period. That’s only possible with prescriptive requirements, not outcomes-based ones (the December post provides examples of both types of requirements, to illustrate this point).
How did I recommend that NIST resolve this contradiction? I didn’t. I said NIST had to choose outcomes-based criteria or a binary label, but they couldn’t have both. Since I strongly favor outcomes-based (risk-based) requirements in general (and I’ve probably written 50 posts about this idea, with reference to different aspects of the NERC CIP standards), I didn’t want NIST to sacrifice those. So I suggested that NIST use an informational label, not a binary one.
And what did NIST do (drumroll, please)?...Last month, they published an IoT security framework called NIST.IR 8425, which is very close to the set of criteria in the February document (the categories of criteria are exactly the same, while the criteria in each category differ slightly). It’s safe to say that NIST decided to stick with outcomes-based criteria, which is good. But what happened to the labeling program in the February document? Did NIST stick with the binary label?
When I published my most recent post (on IoT security certification) in LinkedIn, Dale Peterson asked in a comment why I hadn’t mentioned “the very recent USG announcement that they will define IoT security labeling.” I hadn’t seen the story on the White House conference yet, so I thought he was referring to the EO. In my reply, I pointed to the February document and the fact that NIST seemed to have been taken out of the device labeling business, since the criteria from the February document had been made into their own NISTIR, with no mention of labeling.
But I now realize Dale was referring to the meeting last week. My response should have been:
What was announced by the White House recently seems to be the end of the idea that NIST can run a certification program (my last post was about the ioXt device certification program, which is of course not a government effort). NIST is quite good at writing non prescriptive security frameworks, but they showed in December and February that they’re not good at all in developing up-or-down certification programs.
However, that doesn’t mean the White House will be good at developing a device certification program, either. They may very well make the same mistakes that NIST did – although they may boldly break new ground and make completely new mistakes!
My advice to the White House (not that I’ve been asked, of course) is the same as what I gave to NIST (and that was in response to a request for comments in December, although it wasn’t an official comment period): If you try to marry a label that’s really a certification (as NIST wanted to do with their “binary” label) with a set of non-prescriptive guidelines (like NIST.IR 8425), you’re trying to do the impossible. You might as well try to square the circle or invent a perpetual motion machine.
Make the label an informational one, and make sure the label provides real information (perhaps attestations, like the German label). Then let the consumers make up their own minds about whether the product is secure, based on what they read on the label.
Some consumers won’t look at the label at all, of course. That’s too bad, but there’s no point in even pretending that cybersecurity is anything but a risk management exercise (it’s definitely not a matter of scientific calculations, like Energy Star, although it’s amazing the number of people who think there’s some sort of formula that will make you secure). A risk-based decision has to be made by the individual, period.
This blog has been published originally by Tom Alrich on Tom Alrich's blog.