Thursday, May 18, 2023

A big IoT cybersecurity announcement is coming next month


Executive Order 14028[i], issued in May 2021, required NIST to develop a “cybersecurity labeling program” for IoT devices. The program was never intended to be regulations, but rather a certification issued by one or more private sector organizations, which would be sponsored and encouraged by the federal government. While there has been a lot of uncertainty about when the program will be announced and what it will include, it seems that will soon go away.

In June, there will be a White House announcement about the program. Here is some information I currently have on it:

1.      The basis for all certifications will be NIST.IR 8425, which is discussed in detail below.

2.      It appears that the program will be run by the Consumer Technology Association (which runs the huge Consumer Electronics Show every year).

3.      Some organizations that currently offer cybersecurity certifications for IoT devices will be empowered to issue their own labels, but they will have to at least address the guidelines in NISTIR 8425. One of those organizations is the IoXT Alliance. One of my clients, Red Alert Labs in France, is one of the small number of organizations that has been certified as an assessor for IoXT.

Of course, I expect the announcement in June will provide a lot more information on the program. In the meantime, both IoT device manufacturers and IoT device users (which includes almost every business, and a good percentage of the people, on the planet) should take a look at NIST.IR 8425, which I think is a very good document. I wrote a post on it after it came out last fall, but below is a larger discussion of what’s in the document.

NIST.IR 8425 was released in September 2022. It appears to be the last NIST document regarding IoT device cybersecurity, at least in the near term. The NIST.IR 8259 series (including NIST.IR 8259 as well as 8259A through 8259D, all of which were developed in 2020) provides a larger set of IoT guidelines than what is included in this document. NIST.IR 8425 contains a subset of what’s in the 8259 series, which were selected with a lot of input from the software community in 2021.

NIST.IR 8425 is intended to be the set of guidelines for the device labeling program, but this is clearly meant to be a baseline for all IoT. It consists of selections from NIST.IR 8259A (“IoT Product Capabilities”, or technical requirements) and NIST.IR 8259B (“Product Developer Activities”, or manufacturer policies and processes). The specific selections from these two documents are listed on page 11 of NIST.IR 8425.

There are many things to like about NIST.IR 8425. One is that, unlike the earlier NIST documents on the “consumer” IoT device labeling program, this document is clearly aimed at IoT products for businesses as well as households. This is emphasized in the Abstract on page i. 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.”

NIST has recently stated that there will later be a set of IoT guidelines that is aimed at “enterprise” devices – presumably devices that are aimed at large businesses and government agencies. If so, those requirements will likely be selected from NIST.IRs 8259A and 8259B. NIST.IR 8425 should be seen as the initial step toward compliance with the “enterprise” guidelines, when and if they appear in the future. In the meantime, 8425 provides a good set of baseline requirements.

The remainder of this post provides comments on many of the requirements and subrequirements in NIST.IR 8425. However, these are only a minority subset of the total requirements. The reader is encouraged to read the whole document.

IoT Product Capabilities

Asset Identification (page 5)

“The IoT product is uniquely identifiable and inventories all of the IoT product’s components.

1. The IoT product can be uniquely identified by the customer and other authorized entities (e.g., the IoT product developer).

 2. The IoT product uniquely identifies each IoT product component and maintains an up-to- date inventory of connected product components.”

By “components”, NIST is referring to the four things that are part of what they call an IoT “product”. They include:

1.      The device itself

2.      Any hardware that’s required to be used with the device, like an intelligent hub

3.      Any software interface to the device, like on a smartphone

4.      The cloud backend

This requirement states that a) the “product” needs to be uniquely identifiable by users, although users are almost always just going to point to the device itself, not the cloud backend or the smartphone app (even though NIST considers these to be just as much part of the IoT product as the device itself); and b) the “product” always maintains an inventory of its components, although a footnote points out that the inventory can be installed on any of the components – such as the cloud backend.

Product Configuration (page 6)

“The configuration of the IoT product is changeable, there is the ability to restore a secure default setting, and any and all changes can only be performed by authorized individuals, services, and other IoT product components.

1. Authorized individuals (i.e., customer), services, and other IoT product components can change the configuration settings of the IoT product via one or more IoT product components.

2. Authorized individuals (i.e., customer), services, and other IoT product components have the ability to restore the IoT product to a secure default (i.e., uninitialized) configuration.

3. The IoT product applies configuration settings to applicable IoT components.”

Perhaps the most important of these three items is number 2. The product needs to be capable of being restored to its secure default configuration, and both services and other components of the product need to be able to do this. While this is essential for real “consumer” devices, business users may not want this capability, since a rogue service might reset the device when it’s performing an important function. Business users will probably want to be able to turn this capability off, at least some of the time.

Data Protection (page 7)

“The IoT product protects data stored across all IoT product components and transmitted both between IoT product components and outside the IoT product from unauthorized access, disclosure, and modification.

1. Each IoT product component protects data it stores via secure means.

2. The IoT product has the ability to delete or render inaccessible stored data that are either collected from or about the customer, home, family, etc.

3. When data are sent between IoT product components or outside the product, protections are used for the data transmission.”

Many people, when they think of protecting data stored in an IoT product, just think of protecting data stored in the device itself. However, it’s equally important to protect data stored in the cloud backend, the smartphone app, and any other components. It’s also important to protect data as it’s transmitted between the components.

Interface Access Control (page 8)

“The IoT product restricts logical access to local and network interfaces – and to protocols and services used by those interfaces – to only authorized individuals, services, and IoT product components.

1. Each IoT product component controls access to and from all interfaces (e.g., local interfaces, whether externally accessible or not, network interfaces, protocols, and services) in order to limit access to only authorized entities. At a minimum, the IoT product component shall:

a. Use and have access only to interfaces necessary for the IoT product’s operation. All other channels and access to channels are removed or secured.

b. For all interfaces necessary for the IoT product’s use, access control measures are in place (e.g., unique password-based multifactor authentication, physical interface ports inaccessible from the outside of a component).

c. For all interfaces, access and modification privileges are limited.

2. Some, but not necessarily all, IoT product components have the means to protect and maintain interface access control. At a minimum, the IoT product shall:

a. Validate that data shared among IoT product components match specified definitions of format and content.

b. Prevent unauthorized transmissions or access to other product components.

c. Maintain appropriate access control during initial connection (i.e., onboarding) and when reestablishing connectivity after disconnection or outage.”

Often, a device manufacturer will consider it enough protection if they simply instruct users to disable any physical or logical interfaces that they don’t need. But that doesn’t allow for the idea that users of some devices may need to utilize certain interfaces at some times but not others. Having that capability requires being able to control access by interface.

The fact that this requirement is here shows that this document isn’t just for pure “consumer” products. The owner of a baby monitor shouldn’t need to be able to control access at the interface level. But a business might very well need to do that.

Software Update (page 9)

“The software of all IoT product components can be updated by authorized individuals, services, and other IoT product components only by using a secure and configurable mechanism, as appropriate for each IoT product component.

1. Each IoT product component can receive, verify, and apply verified software updates.

2. The IoT product implements measures to keep software on IoT product components up to date (i.e., automatic application of updates or consistent customer notification of available updates via the IoT product).”

Item 1 is important. It says that each component – the device itself, the cloud backend, and the smartphone app – must be able to verify and apply its own updates; no component should have to depend on another component to update itself, since communication among the components can never be taken for granted.

Cybersecurity State Awareness (page 10)

“The IoT product supports detection of cybersecurity incidents affecting or affected by IoT product components and the data they store and transmit.

1. The IoT product securely captures and records information about the state of IoT components that can be used to detect cybersecurity incidents affecting or affected by IoT product components and the data they store and transmit.”

This might seem like an odd requirement, since it says the product needs to capture information about the state of IoT components, but it doesn’t even attempt to say anything about what that information is. A footnote at least gives some examples:

Information about the state of IoT components that would be useful to detecting cybersecurity incidents is highly contextual to the IoT product, its components, and its operation. In most cases, temporal information such as time-stamp or location data (digital or physical) should be captured. Software and hardware version and operational state (e.g., known fault or exception thrown) may help detect cybersecurity vulnerabilities (e.g., specific software or hardware may have known vulnerabilities). Cybersecurity state information may also contain records of commands and actions received by and executed by the IoT product or other data that is meaningful to the IoT product and how it works, and are therefore useful to detecting incidents.

Clearly, this is something that needs to be configurable by the integrator of the device, although probably not by the end user. 

IoT Product Non-Technical Supporting Capabilities

Until this point, all of the items have been “IoT Product Capabilities”. The remaining items are all classified as “IoT Product Non-Technical Supporting Capabilities”. That is, these relate to the capabilities of the manufacturer or integrator of the product, not to the capabilities of the product itself.

Documentation (page 11)

This is a long section and lists over 30 individual topics that need to be addressed in documentation by the manufacturer. Of course, if any of these topics is not relevant to the type of device in question, the manufacturer should indicate that the topic is not applicable. Below are topics I consider particularly relevant:

Item 1.a.vi. (page 11): (The documentation must address) The IoT product developer’s assumed cybersecurity requirements for the IoT product.”

The developer’s “assumed requirements” should include everything in this document, but they could always include more. For example, NIST.IR 8425 includes a subset of the requirements in two larger documents: NIST.IR.8259A and NIST.IR.8259B. A manufacturer that wants to go beyond what NIST.IR 8425 requires might decide to follow most or all of the 8259A and B requirements.

Item 1.d.iv. (page 12): (The documentation must address) Consideration for the known risks related to the IoT product and known potential misuses.”

This is very important. It implicitly acknowledges that, with IoT products being put to such diverse uses, there’s no way that a single set of requirements can address all known risks to the product. On the other hand, NIST wants manufacturers to acknowledge any product-specific risks they know about, even if they’re not fully mitigated. By including this requirement, NIST is requiring the manufacturer (or integrator) to point out product-specific risks to users. (My opinion is that, if the manufacturer has already mitigated a risk, they shouldn’t feel obligated to point it out, unless there remains some residual risk that needs to be mitigated. And any serious risk shouldn’t be pointed out in documentation, but perhaps in private verbal communication with users. Of course, if there really is a serious risk in the product, for which there is currently no mitigation available, why is the manufacturer putting the product on the market at all, except because…no, that can’t be…they prioritize making money over the security of their customers! What a ridiculous idea…)

Item 1.d.v. (page 12): “(The documentation must address) Secure software development…practices used.”

It would be wise for developers to say they’ve followed NIST’s new Secure Software Development Framework (SSDF), although they will need to be prepared to show how they’ve followed it. As with any NIST framework, the manufacturer needs to perform a risk assessment, which determines which of the items in the framework they will address and which they will not address. However, the developer needs to be able to state that they have at least considered every item in the framework, and provide a reason why they have not addressed any particular item.

Item 1.d.v. (page 12): (The documentation must address)…supply chain practices used.”

This phrase refers to the practices the manufacturer follows with respect to their own suppliers – i.e., the developers of the hardware and software included in the device. It would be best if the manufacturer could indicate they follow a particular framework of supply chain practices. NIST’s primary supply chain security format is NIST SP800-161, which is far too detailed for this application. However, the NIST Cyber Security Framework (see below) describes a good set of supply chain security practices, which might be appropriate in this context.

Item d.vi. (page 12): (The documentation must address) Accreditation, certification, and/or evaluation results for cybersecurity-related practices.”

This item refers to general cybersecurity-related practices, not specifically supply chain practices. The most widely used cybersecurity framework in the US now is the NIST Cyber Security Framework (CSF). The CSF is something like a security maturity model. It delineates three tiers of cyber practice. The organization needs initially to determine into which tier it falls, and then develop a plan to achieve the next tier. To establish conformance with this requirement, the manufacturer could provide a copy of the initial assessment and the tier to which they were assigned, as well as their documented plans to move to the next tier.

Item 1.f.i. (page 12): (The documentation must address) Steps taken during development to ensure the IoT product and its product components are free of any known, exploitable[ii] vulnerabilities.”

This requirement seems to indicate that an IoT product (or any standalone software product) can never be secure unless all “known, exploitable” vulnerabilities have been patched. In fact, there is general agreement in the software community that having some number of unpatched low-severity vulnerabilities does not in itself pose much if any risk to software products or intelligent devices. Therefore, requiring suppliers to patch every vulnerability of any severity level is likely to lead to a mis-expenditure of resources, which will ultimately result in higher prices to consumers.

A better way to word this requirement would have been, “Steps taken during development to ensure the IoT product and its product components are free of any serious, exploitable vulnerabilities.”

Item 1.f.ii (page 12): (The documentation must address) The process of working with component suppliers and third-party vendors to ensure the security of the IoT product and its product components is maintained for the duration of its supported lifecycle.”

This requirement is much more understandable when it is restated using the active, not passive, voice: “The device manufacturer needs to implement and maintain a program to work with component suppliers and third-party vendors to ensure the security of the IoT product and its product components.”

New vulnerabilities are identified all the time by security researchers and sometimes by hackers. Thus, no matter how rigorously the supplier followed secure software development practices, new vulnerabilities can be identified in any product at any time. The manufacturer needs to acknowledge this fact by implementing and maintaining a vulnerability management program, which includes identification of new vulnerabilities in software or firmware installed in their product, and providing patches for any of those vulnerabilities deemed to be serious.[iii]

Item 1.f.iii (page 12): (The documentation must address) Any post end-of-support considerations, such as the discovery of a vulnerability that would significantly impact the security, privacy, or safety of customers who continue to use the IoT product and its product components.”

The previous requirement addresses the issue of vulnerabilities that occur during the period that the IoT product is under support by the manufacturer, meaning the manufacturer takes responsibility for patching significant vulnerabilities. However, that responsibility ends when the product is no longer under support. This is a normal practice in the software and intelligent device worlds: The manufacturer makes it clear that, as of a certain date, they will no longer provide updates or patches for a particular version of a software product or device. After that date, customers who do not upgrade to a supported version (or move to a competitor’s product), yet continue to use the product, will run the risk that a serious new vulnerability will be discovered in the product, for which the manufacturer will not provide a patch. As long as the manufacturer provides sufficient advance notification[iv] of the end of support, their customers cannot claim they are being treated unfairly.

This requirement takes into consideration the fact that, no matter how much advance notice a manufacturer provides, there will always be some customers who will not upgrade. What will happen if a serious vulnerability is discovered after the end of support? Often, even if one of the “holdout” customers now wants to upgrade, they will run the risk of suffering a serious breach before they can complete the upgrade. While the manufacturer is free to adopt any policy they wish in this situation, they might decide to develop a patch for the vulnerability and offer it to the holdout customers for a fee. They also may offer a post-end-of-life support contract, which usually carries a hefty fee.[v]

1.g.iv. (page 13): (The documentation must address) Policy for disclosing reported vulnerabilities.”

Disclosing reported vulnerabilities is always a difficult question to discuss in a policy context. Of course, if the manufacturer has developed a patch for the vulnerability, there is no question they should disclose the presence of the vulnerability in their product, although this should be done at the same time that they announce the availability of the patch. By the same token, there is not much question that the manufacturer should not disclose the presence of the vulnerability if they expect to have the patch available in a short amount of time, perhaps one day.

However, the discussion becomes more difficult if the manufacturer has not yet developed a patch for a serious vulnerability that they know is present in their product. The policy will depend on the answers to several questions:

1.      Has the vulnerability been publicly disclosed and is there general awareness of it – at least in the hacker community?

2.      Has the vulnerability begun to be actively exploited in the general community?

3.      Has it been revealed that the vulnerability is present in the product in question, or have active exploits of the vulnerability in that product already begun?

If the answer to question 1 is No, it would not be a good idea for the manufacturer to reveal that their product is vulnerable. If the answer to question 1 is Yes but the answer to question 2 is No, it would also probably not be a good idea for the manufacturer to reveal that their product is vulnerable (of course, in both of these cases, the manufacturer should expedite development of the patch as quickly as possible).

If the answers to questions 1 and 2 are Yes but the answer to 3 is no, the answer to the question whether the supplier should announce the vulnerability in their product is not clear-cut. The manufacturer needs to determine a) how long it will take them to develop the patch, and b) how quickly exploits of the vulnerability are spreading. The more imminent the availability of the patch, the more the manufacturer should lean toward not revealing the vulnerability.

However, if exploits are spreading very rapidly and it is possible that one or more of the devices will be attacked before the patch is available, the manufacturer should probably announce that the device is vulnerable and recommend a mitigation, including perhaps removing the device from customer networks pending the patch being available.

If the answers to all three questions are Yes, there is not much question that the manufacturer should announce that their device is vulnerable, and – unless there is an effective alternative mitigation already available – suggest that customers remove the device from their networks, pending availability of the patch.

Product education and awareness (page 16)

This section addresses a deficiency in documentation for many software products and IoT devices: The documentation describes the cybersecurity capabilities of the device but says nothing about why those capabilities should be used and how the customer might decide the proper policies and settings.

The section makes clear that the IoT device manufacturer should do more than just recite technical details about their product in their documentation, especially when it comes to security capabilities. They need to discuss the following:

1.      Why the customer might want to change the default configuration settings.[vi]

2.      The different options for access control (including password settings), and considerations for deciding appropriate policies.

3.      Securely managing data on the device and its components (especially the cloud component).

4.      Maintaining security of the device and its components, including after support from the manufacturer has ended.

5.      Managing vulnerabilities in the device and its components.



[i] Section 4, subsections (s) and (t)

[ii] The word “exploitable” is important. As IoT device manufacturers start to issue software bills of materials (SBOMs) to their customers regularly, the customers are likely to be alarmed to discover many vulnerabilities, when they look up the components (dependencies) listed in an SBOM in a vulnerability database. However, probably over 95% of vulnerabilities in software components do not pose a risk to the user of the device, because an attacker would never be able to “exploit” them to penetrate the device; this is often because of how the component was incorporated into the product by the developer. In the near future, it is hoped that a “VEX” (Vulnerability Exploitability Exchange) API will be available to inform users that particular vulnerabilities found in software components are not exploitable in the product itself.

[iii] The definition of “serious” is up to the individual supplier and should be based on their customers’ requirements. For example, if an IoT device is mainly used in high-security military applications, almost any exploitable vulnerability may be considered serious enough to warrant patching. However, as already mentioned, in most IoT use cases, it is not necessary to patch every vulnerability – just those that have a high likelihood of occurring, those that would have a serious impact if they did occur, or both.

[iv] What constitutes “sufficient notification” will vary by the type of product and other circumstances. Generally, notification should be provided at least a year in advance, and sometimes longer.

[v] Sometimes, a manufacturer will consider a new vulnerability to be so serious, that they will make an exception and “backport” a patch for the out-of-support versions of their product. Of course, a customer should never count on their doing this.

[vi] Of course, the manufacturer should never reveal the default settings themselves.

No comments:

Post a Comment