What’s the state of IoT cyber regulation?

The first time I ever wrote about IoT security was last December, when the IoT Cybersecurity Improvement Act of 2020 was signed into law by the former president. I realized it was something that would impact the energy industry, so I thought I’d let my readers know about it - not that I expected too many of them to get excited by it, of course. As it turns out, it was one of my most popular posts of recent years.

Then in May, the Executive Order (EO) included a very interesting provision on consumer IoT device security. This hasn’t received much attention, but it will next month, when NIST convenes a two-day virtual conference to discuss this and a related provision for consumer software.

Finally, in June I was engaged by a European company that deals with IoT security regulation to help them understand what’s going on in the US in that regard. This gave me the opportunity to learn about what’s going on in both the US and Europe (spoiler alert: Europe is ahead of the US in terms of having widely-followed guidelines for IoT, although the US is definitely now ahead in terms of mandatory requirements, at least ones that are on the books for future enforcement).

Since what’s going on in IoT cyber regulation will end up affecting all IoT users – home, commercial, industrial and government – very soon (including the energy industry), I’m going to summarize what’s most important (IMHO) to know about each set of regulations. This post is about the IoT Act, and my next post will be about the IoT provisions in the EO.

If you read my December post linked above, you’ll see I really like the way the IoT Act is structured; to be honest, I wouldn’t mind seeing all of the NERC CIP standards rewritten in this way (in fact, I think that if Medium or High impact BES Cyber Systems are ever going to be allowed to be deployed in the cloud – e.g. outsourced SCADA – rewriting the standards in this way will be required. Hopefully, I’ll have time to write a post on that topic in the near future, although I did touch on this topic in a recent post).

Here’s my summary of the Act, partly plagiarized from my own post:

1.      The Act starts with a great definition of IoT devices. They must “have at least one transducer (sensor or actuator) for interacting directly with the physical world, have at least one network interface, and are not conventional Information Technology devices, such as smartphones and laptops, for which the identification and implementation of cybersecurity features is already well understood.” Note that there’s no distinction here between “home” and “industrial” IoT. As long as there’s one transducer and one network interface and it’s not a smartphone or laptop, it’s an IoT device and it’s an IoT device. It’s safe to say that the great majority of organizations in the US, and a large percentage of households, are IoT users.

2.      But the Act doesn’t apply to device manufacturers, only consumers. And the only consumers it applies to are federal government agencies. Why is that the case? I’m sure this restriction made the bill much easier to write. Since there aren’t currently any mandatory federal cybersecurity regulations on any IT/OT/IoT suppliers, if the bill had been intended to apply to suppliers, it would have run into a firestorm of opposition and might have required years to get approved (as it is, the Act required two years for approval).

3.      But what about the fact that it’s restricted to federal agencies? Does it really do the general public a lot of good if nothing they use (unless they work for a federal agency) is directly covered by the Act? I think it definitely will, for the same reason that the Executive Order will do the general public a lot of good, even though it’s also restricted to federal agencies: Suppliers of any product, but especially an IT-type product, aren’t going to take the trouble to have two separate product lines – one for the Feds and one for the rest of us schmoes. It just doesn’t make for a great advertising tag line: “Sure, this IP camera is more likely to spy on you than the one the Feds use, but it costs $10 less!”

4.      So what are the federal agencies supposed to require of their IoT vendors? The Act wisely doesn’t prescribe anything (although see the next paragraph). It simply requires NIST to, within 90 days, develop “standards and guidelines for the Federal Government on the appropriate use and management by agencies of Internet of Things devices…including minimum information security requirements for managing cybersecurity risks associated with such devices.”

5.      But NIST doesn’t have a completely free hand in developing these guidelines. They have to address “secure development, identity management, patching and configuration management.” Of course, all four of these topics are ones that I would expect would be in any good cybersecurity framework.

6.      NIST, ever the eager beavers, met the 90-day deadline (give or take a month or two) with not one document but five: NISTIRs 8259B, 8259C and 8259D, along with NISTIR 8322 and draft SP 800-213. All of these documents are good. SP 800-213 is aimed at policies and practices of end user organizations (in this case federal agencies), while 8259D provides detailed guidelines for IoT device manufacturers who sell to the federal government. So I think these two documents will be the main two governing the IoT Act.

7.      The Act requires the Office of Management and Budget to develop implementation regulations within 180 days. That would probably have been sometime in July, but I haven’t seen anything yet.

While I think the IoT Act will have a positive impact on IoT security, I think the Executive Order will have a much greater one. In fact, it may work out that what the EO requires will end up superseding the IoT Act altogether. Is Tom right about this? Or is he full of it? You’ll be able to decide for yourself when the exciting conclusion to this series arrives in your inbox (or browser) in the very near future. Please try to contain your excitement.

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.