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