What’s the state of IoT cyber regulation? Part 2

In my most recent post, I described the first of two pending mandatory US cybersecurity regulations for IoT devices, the IoT Act of 2020. Now I’ll describe the second of these and the one that’s more important, the IoT “device labeling” requirement in the May 12 Executive Order on securing software sold to federal government agencies.

Paragraph (s) of section 4, on page 18 of the EO, reads: “The Secretary of Commerce, acting through the Director of NIST, in coordination with representatives of other agencies as the Director of NIST deems appropriate, shall initiate pilot programs informed by existing consumer product labeling programs to educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices, and shall consider ways to incentivize manufacturers and developers to participate in these programs.”

Paragraph (t) on page 19 reads: “Within 270 days of the date of this order, the Secretary of Commerce acting through the Director of NIST, in coordination with the Chair of the Federal Trade Commission (FTC) and representatives of other agencies as the Director of NIST deems appropriate, shall identify IoT cybersecurity criteria for a consumer labeling program, and shall consider whether such a consumer labeling program may be operated in conjunction with or modeled after any similar existing government programs consistent with applicable law. The criteria shall reflect increasingly comprehensive levels of testing and assessment that a product may have undergone and shall use or be compatible with existing labeling schemes that manufacturers use to inform consumers about the security of their products. The Director of NIST shall examine all relevant information, labeling, and incentive programs and employ best practices. This review shall focus on ease of use for consumers and a determination of what measures can be taken to maximize manufacturer participation.”

Note that paragraph (u) mandates a labeling program for consumer software. This is similar to the IoT device labeling program and indeed, NIST is addressing these two programs together (e.g. they’ve scheduled a two-day conference in September that will address both programs).

What first struck me when I read these two paragraphs was that putting labels on devices seems to be an odd way to address cybersecurity. I normally think of a label as an indication that an organization has tested a product and finds it meets certain safety standards. In other words, the product is safe to use.

Cybersecurity (or security in general) can’t be reduced to a simple “safe/unsafe” decision. In fact, let’s be honest: Seldom (and perhaps never) in our personal or business lives do most of us decide to buy a software product or an intelligent device, based solely on a judgment of the product’s level of cybersecurity.

Instead, cybersecurity is at most a final gating factor: We make the decision to buy a particular product, and before we place the order (or put it in our shopping cart, whether physical or virtual), we may ask ourselves whether there are any cybersecurity skeletons in the closet of the supplier (a device manufacturer, a software developer, the online community that developed an open source software product, etc.) that are serious enough to warrant not going ahead with the purchase or procurement. But recent history tells us that even a serious cybersecurity breach that had a serious impact on customers (think Target or SolarWinds) in the end has very little impact on demand for what the breached company sells – and in fact the impact might be net positive if the company responded well to the attack (as did both Target and SolarWinds).

So what we’re really looking for regarding the security of an IoT device (or any other product containing or consisting of software or firmware) is an indication of the risks that we are going to undertake if we buy the product. If we know what those risks are, we can then take steps to mitigate at least some of them and accept the rest. And if we buy the product without even bothering to learn about the risks (which I’ll admit is my approach when purchasing products for personal use. My general reasoning is, “Given that well-known manufacturer XYZ develops this product and/or that well-known retailer ABC sells the product, it must be secure enough for my purposes.” Whether that’s good reasoning or not is left as an exercise for the reader), we’re accepting those risks (although we all presumably take some reasonable precautions with any product we buy, like at least set a somewhat secure password, when we can do that).

So the main purpose of supply chain cybersecurity in general (and not just for IoT devices) is to help us understand the risks we undertook when we made the decision to purchase the product, not to decide whether or not to purchase the product in the first place; we may or may not take steps to mitigate any of those risks (or even to learn about them), but if we want to do that, we can. And that’s why the idea of a device label for cybersecurity seemed strange when I read about it in the EO: Since a buy/no-buy decision very rarely depends on cybersecurity considerations, how can a label help you determine what the specific risks are that apply to the device, as well as what steps you could take to mitigate those risks? That’s too much information to fit on a label.

It turns out, although I didn’t know this until recently, that the idea of device labeling for IoT device cybersecurity has been around for a while in Europe. In fact, perhaps the best such program (albeit one that’s almost infinitesimally small compared with the program that will be required in the US) is one introduced by the Finnish government in 2019 (and no bad puns about whether or not the program is Finnished or whether or not it only applies to Finnished products. Bad puns are forbidden in this blog. I can assure you that I’ll never sink to using this low form of humor, such as asking whether the army fights to the (last) Finnish. After all, what kind of blogger do you think I am?).

There are three main components to the Finnish IoT device labeling program:

First, the manufacturer has to certify that the device complies with 18 of the 70-odd requirements, which are referred to as “Provisions”, in the ETSI 303 645 standard for IoT devices. This standard may become mandatory in Europe at some point (in the sense that the European Parliament will enact legislation requiring it). But more importantly, this will almost certainly become a de facto standard for commercial, industrial and home-based IoT devices in Europe.  

It may seem odd that the manufacturer has to certify compliance with just 18 of the requirements of ETSI 303 645. Why not all of them? For one thing, since Finland is part of the European Union, their IoT manufacturers will ultimately have to be in compliance with all of the standard anyway. But the real reason is that whoever drafted this law understood that the term “IoT device” covers a huge range of products, from baby monitors and doorbell cameras to protective relays and RTUs (remote terminal units).

This means that, for any particular IoT device, a large portion of the provisions in ETSI 303 645 won’t apply. The 18 requirements chosen by the Finnish were sufficiently general, that it can reasonably be expected that they’ll all apply to the great majority of IoT products. Examples of the 18 provisions are “a manufacturer should have a ‘public vulnerability disclosure policy’, ‘installation of updates should be secure’, ‘all unused interfaces must be disabled’, and ‘there should be no hard coded credentials in the system’.”

You might well ask, “How much good does it do for the user to know that the device they bought meets just 18 very general – and fairly easy to comply with – requirements?” My answer is “Probably not much.” However, the second step in the program directly addresses this gap. Instead of simply requiring that the organization comply with all of the ETIS 303 645 provisions or something like that, it requires that a third-party “inspecting body”, which is approved by a government agency called Traficom, should do a threat-modeling exercise for the device.

The term “threat modeling” is one of those terms that’s thrown around a lot and is used with a variety of meanings – so it’s almost meaningless (no pun intended here. Remember: This blog doesn’t do puns!) to discuss the meaning of threat modeling in general. However, in the context of the Finnish device labeling requirement, the term means that the inspecting body needs to consider both what the device will be used for (e.g. a baby monitor isn’t usually used for purposes that require high security, but a protective relay usually is. On the other hand, protecting personal information is a big concern for baby monitors, but it’s an almost nonexistent concern – except for login information, of course – for protective relays), as well as the setting in which it will be used (e.g. a room in a private home in the case of a baby monitor, vs. a Transmission substation where a cyberattack might affect thousands or even millions of people, in the case of the relay).

Using these two considerations, the inspecting body needs to identify all important cybersecurity threats that might apply to that device. Some of them will apply to many devices (like password strength), while others may be specific to the particular device. For example, one significant threat that applies to smart speaker devices like Amazon Echo™ is that, because they are continually listening to conversations for the magic word “Alexa”, if compromised they might be used to eavesdrop on conversations that occur in the home. In fact, DoD recently put out an advisory to employees working from home not to have smart speakers in the same room where they are working.

Third, when the inspecting body has identified the important cyber threats that apply to the product, they need to develop a test plan to determine whether each threat poses an actual risk. In my way of speaking, if a threat poses a risk, this means either the likelihood or impact of the threat being realized is high.

Since the device can have many uses, it’s very hard – nay, in my opinion it’s impossible – to determine the degree of impact of a threat being realized in all cases. Therefore, what’s important is likelihood, which can be high or low. If likelihood is high, the risk of the threat being realized is high, and mitigation measures should be taken to reduce the likelihood to low. And if likelihood is low, this means the risk is already mitigated (which might be by Mother Nature or other completely external forces, e.g. the risk that a forest fire will damage a region of the Sahara Desert is about as close to zero as it could be), and no further mitigation measures are warranted.

For example, in the case of the Amazon Echo threat discussed earlier, the inspecting body might decide that this threat is low, due to controls that Amazon has implemented to protect the audio stream the device “hears”. In this case, the body will deem this threat to pose minimal risk, meaning users need not take any further mitigation measures for it. So this threat will be deemed not to pose a risk in the Echo device, and it won’t be included in the test plan.

In the Finnish program, when the inspecting body has developed their test plan, they must submit it to Traficom (the government agency that operates the device labeling program). Traficom can disapprove the plan, in which case the inspecting body needs to revise it and resubmit it; otherwise, the plan is approved, and the inspecting body can go ahead and conduct the testing.

Finally, the testing body conducts the tests and submits the test plan and the results to Traficom. Traficom reviews these, then decides whether or not to grant the label. Traficom decides whether whatever residual risk remains (after the results of the device testing are considered) allows the device to be sold in Finland.

I think the Finnish model would be an excellent one for the US program, with two important modifications:

First, the US program has to operate with minimal government involvement, both for budgetary reasons and for general regulatory philosophical reasons (as long as human life isn’t directly at stake, the feds usually don’t want to be directly involved in auditing or testing. So the Consumer Product Safety Commission and the National Highway Traffic Safety Administration are directly involved in investigating cases that come up for them, since these could often have an impact on life safety. But it can’t be said that the cyber compromise of an IoT device would directly impact human life, except in rare cases (e.g. if a baby died because his or her parents couldn’t hear their distress cries, due to a cyberattack having disrupted communications with the baby monitor).

This means that the Office of Management and Budget, which is charged with implementing all of the EO’s provisions[i], won’t want to be in the business of certifying “inspecting bodies” – which may be called “laboratories”, as they are in Europe. Rather, they would certify the organizations that certify the labs, and might even go one step further: certify the organizations that certify the organizations that certify the labs.[ii]

The second difference between the Finnish IoT device labeling program and the likely US program is that the latter won’t be required for a device to be sold in the US, or even to the federal government. A manufacturer will be able to decide for themselves whether or not they want to participate in the program. If they decide not to, they won’t be shut out of the market, but they will have a harder time selling their product – especially to federal agencies, since the agencies will be required to ask their IoT device suppliers to participate in the labeling program, and they’ll have to justify to auditors any case in which they bought from a supplier that didn’t participate (i.e. the supplier doesn’t have a label at all, regardless of what it says).

So what will the “label” say, if it isn’t “This device is safe/unsafe to buy”? The label (which will probably be a document accessible by scanning a QR code or entering a URL found on the product or in its accompanying documentation) will list the threats that were identified through threat modeling and the degree of residual risk for each threat, after any mitigations that have been applied by the manufacturer. Additionally, the document will list mitigations that a user organization, which is concerned about one of the risks, can take to at least partially mitigate it. For example, if the organization (a federal agency, a private organization, etc.) wishes to partially mitigate the risk due to the fact that a device allows users to authenticate using weak passwords, they could locate the devices only in access-controlled rooms. 

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the National Technology and Information Administration’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. 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.

---

[i] Although the EO allows OMB to decide whether to bring in another agency to run any particular program. You’ll notice that paragraph 4 (t) quoted above mentions the Federal Trade Commission (FTC) as being involved with the device labeling program. This makes a lot of sense, and comports with my idea that, sooner or later, all government agencies will be involved with cybersecurity, and not just for securing their own systems. 

[ii] This is essentially how the EPA’s Energy Star program works: the EPA approves Certification Bodies. The CBs then approve Accreditation Bodies, who accredit the laboratories that test products for energy consumption. The Accreditation Bodies accredit based on ISO/IEC 17025, an international standard for testing laboratories (which is independent of the subject being tested). This is the basis for cybersecurity laboratory testing in Europe, and most likely will be the basis here as well, for the IoT device labeling program.