Recently, the FCC released their
latest document describing their upcoming device labeling program – which will provide
a cybersecurity “label” to IoT devices that are assessed to meet a basic level
of security. First, some history of this program:
The White House, in Executive
Order 14028 of May 2021, ordered two sets of actions
regarding cybersecurity for IoT devices:
1.
In paragraph (s) on
pages 18 and 19, the WH required the Department of Commerce, to a) initiate
pilot programs to “..educate the public on the security capabilities of
Internet-of-Things (IoT) devices and software development practices..” and to b)
“..consider ways to incentivize manufacturers and developers to participate in
these programs.” These programs should be “..informed by existing consumer
product labeling programs.”
2.
In paragraph (t) on
page 19, the WH required NIST to a) “..identify IoT cybersecurity criteria for
a consumer labeling program..” and b) “..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.”
Even though these actions were to
be performed by two different agencies, it seems NIST decided to take responsibility
for both of them: operating the program and developing the criteria to be used
in assessments. NIST came out with their preliminary ideas for both of the above
items in December 2021. I panned their ideas in two posts, mainly because I thought their
idea for operating the labeling program was doomed to fail.
It seems NIST agreed with me,
since they later dropped the idea of operating the labeling program and just
concentrated on developing the criteria for the program. After one or two
iterations, they came out with NIST.IR.8425, which provides those criteria. I think it is an excellent
document.
In November 2022, I wrote about
NISTIR 8425 in this blog
post on the website of Red Alert Labs.
One thing I noted in that post was that, despite the fact that the labeling
program was described in the EO as being for “consumers”, NIST thinks of 8425
as a “baseline” that’s applicable to most devices, whether intended for use by
consumers, business or government. The first sentence of the Abstract states
that the publication “…identifies cybersecurity capabilities commonly needed
for the consumer IoT sector (i.e., IoT products for home or personal use)”. Yet
the second sentence reads, “It can also be a starting point for businesses to
consider in the purchase of IoT products.”
In that blog post, I speculated
that the Federal Trade Commission would be chosen to operate the device
labeling program, since they're responsible for enforcing other regulations
regarding the trustworthiness of products sold in the US, as well as the
truthfulness of claims made about them by their manufacturers. But I was
surprised when in July 2023, the White House announced that the Federal Communications Commission (FCC) would run
the program, which would be called “Cyber Trust Mark”.
I was at first skeptical that the
FCC could run a program that didn’t deal directly with communications. My
skepticism was allayed last August, when the FCC issued their Notice
of Proposed Rulemaking (NPRM) for the labeling
program. While it was clear from the NPRM that the FCC was still feeling their
way through unfamiliar terrain, at least they weren’t plowing ahead with
pre-conceived ideas. Instead, they were honestly looking for advice from device
manufacturers and consumers regarding the best way to put together the consumer
device labeling program.
What I liked best about the NPRM
was that it was clearly taking the carrot’s advice on how to motivate device
manufacturers (and donkeys) to do the right thing: You don’t beat the
manufacturers with a stick until they agree to do what you want.
Instead, you offer them a deal:
For not a lot of money, they’ll receive a label that assures consumers that the
manufacturer has put in place a set of basic cybersecurity measures that will at
least protect the consumer from succumbing to some of the easiest-to-counter
cyberattacks and malware. Maybe, after the manufacturer realizes that obtaining
the label was relatively painless, they will go on to seek higher levels of cybersecurity
attainment – or at least they’ll maintain the level they have now (since the
label will need to be renewed periodically).
For all its goodness, the NPRM left
a lot of questions unanswered about how the program will work. This wasn’t
surprising, since the whole purpose of an NPRM (some of you in the power
industry will recognize the acronym NOPR instead of NPRM. This is FERC’s
acronym for “Notice of Proposed Rulemaking”) is to gather people’s reactions to
tentative ideas for new rules.
On February 22, 2024, the FCC
released a new document called “Cybersecurity
Labeling for Internet of Things”. This document,
which is called a “Report and Order”, is based on in-depth review of the
various comments the FCC received on their NPRM. It lays out the framework of
the labeling program (which is set to begin late this year) with a lot of
clarity[i], although there will soon
be a new round of documents (almost certainly the last). That round will probably
begin with a new NPRM, followed by a new comment period, then probably a final
Order that sets the program in stone, at least for a year or more. The FCC
intends to have the program in operation by the end of 2024.
While there are many gaps still to
be filled in, the FCC says the program will include the following elements:
1.
The FCC will not directly
issue labels or assess products on their worthiness to receive the label. Instead,
they will rely on three levels of third-party organizations to do this.
a.
The labels themselves
will be issued by a small number of Cybersecurity Label Administrators (CLAs).
These will probably be organizations that are already issuing cybersecurity
certifications for IoT devices, such as ioXt and UL.
b.
CLAs may apply to the
FCC to be named the Lead Administrator. The Lead Administrator will have
additional responsibilities beyond those of a CLA (see below).
c.
While a CLA will issue
a label for a device, the label applicant (a device manufacturer) will need to
submit a sample of the device for testing and assessment by a CyberLAB. The
CyberLABs will be chosen from existing device testing laboratories that have
applied for the CyberLAB designation. The Lead Administrator will authorize
CyberLABs, although labs that have already been accredited to the ISO 17025 standard
will be recognized.
2.
CyberLABs will charge
“reasonable fees” to manufacturers for conducting the assessment. Since there may
be many labs to choose from, the existence of competition might be assumed to
keep fees at a “reasonable” level. However, it is possible that particular geographic
areas (especially outside the US and Europe) will have few CyberLABs and thus
will be more prone to “unreasonable” pricing. The FCC has preliminarily decided
not to try to regulate the CyberLABs’ pricing, but it reserves the right to
revisit that decision if necessary.
3.
If a manufacturer has an
in-house lab that meets all the criteria for being a CyberLAB (and is designated
as such by the Lead Administrator), that lab may conduct the assessment
themselves. However, the label still needs to be assigned by a CLA, who will
review the results produced by the lab. The FCC strongly rejects the idea that
self-attestation might take the place of the assessment.
4.
While the criteria in
NIST.IR.8425 will be the basis for assigning the label, the FCC agrees with some
of the commenters on the previous NPRM that those criteria are too broad for an
up-or-down assessment. Therefore, the Lead Administrator will propose “technical
standards and testing procedures” for providing a
label, although the Commission itself will need to approve them. These standards
may vary based on “class of product”.
5.
The Lead Administrator
also must recommend to the Commission how often the label will be renewed. The
FCC is clear that they don’t want the label to be perpetual.
6.
The Lead Admin is also
required to “submit to the Commission reports on CLAs’ post-market surveillance
activities” (p. 28 item e); in other words, the CLAs will be required to do
some sort of “auditing” of their label holders. This will probably be a tricky
question, because:
a.
Auditing can be
expensive. What will the CLA need to audit and how will they audit it?
b.
The post-market
surveillance is different from the assessment that will presumably be made
every 2-3 years (or longer?), to determine whether to renew the label. That
will be based on cybersecurity criteria, perhaps the same ones used to assign
the label in the first place.
c.
“Post-market
surveillance” means watching for misuse of the label, e.g., asserting in
advertising that the label amounts to some sort of guarantee that the device
will never be hacked. Comments like these are hard to police. Is the CLA (which
after all doesn’t have a police force) supposed to be continually searching
through lots of published reports, blog posts, Facebook posts, etc. – in order
to learn when one of the manufacturers that has received the label based on the
CLA’s assessment has made a boo-boo in one of their public statements? Frankly,
that’s asking a lot of them, and I wonder how the FCC will ensure that the CLAs
conduct this surveillance.
d.
Also, there’s an
inherent flaw in asking the CLA to conduct surveillance of the manufacturers
they approved for a label: They will inevitably look on those manufacturers as prospects
for future business, including renewal of the label. Calling a manufacturer out
for a misstatement isn’t likely to enhance the CLA’s chances of receiving more
business from them. Because of this, I don’t expect to see the CLAs being
aggressive in their surveillance efforts.
7.
I think it would be
much better for the FCC itself to conduct random audits and other surveillance.
I would hope they’re already doing that for organizations that benefit from
their actions, including holders of various communications licenses. They
should already have most of the infrastructure and staffing needed to do this.
8.
In paragraph 105 on
page 52, the FCC says that “program participants” (which presumably means the
CLAs and the CyberLABs, although it wouldn’t have hurt to mention those names
specifically) are welcome to include additional security features in their
assessments, as long as they don’t require that the manufacturer pass these
enhanced assessments in order to receive the Cyber Trust Mark itself. They also
aren’t allowed to include the certification for he advanced asssessment on the
Cyber Trust Mark label (i.e., on the physical label on the device, or on the
web “label” to which the user will be sent when they scan the QR code on the
physical label).
9.
Does that mean CLAs
could compete with each other by offering “label plus” assessments – and offer a
separate label or certification for the additional features? After all, the
CLAs (there will likely be fewer than ten of them) will be chosen partly
because they already offer a cybersecurity certification for IoT devices. It
wouldn’t be realistic to expect them to drop everything they were doing
previously and from now on just offer the Cyber Trust Mark.
10.
On pages 52-53
paragraphs 107-108, the FCC points out that some commenters suggested that the
FCC follow the example of Singapore’s
label, which offers four levels of security in
their labels. However, they don’t waver from their commitment to a binary label
with just one level, mainly because they are worried that it will dilute the
importance of the Cyber Trust Mark if there are multiple levels. I agree with
this decision. They note that the decision can always be revised later.
11.
The FCC notes that
manufacturers are free to provide consumers additional cybersecurity
information about their product, if they believe it will make consumers more
interested in purchasing it. However, they shouldn’t provide that information
on the Cyber Trust Mark physical label itself, nor should they include it on
the web page to which the consumer is sent when they scan the QR code on the
physical label.
12.
In their NPRM from
last summer, the FCC suggested they might ask manufacturers to disclose
unpatched vulnerabilities in their devices. As might be expected, that idea met
with almost universal disapproval. There’s nothing wrong with disclosing an
unpatched vulnerability, as long as the manufacturer has already released a
patch for it. But most security professionals agree that, in general, an
unpatched vulnerability should never be disclosed unless the patch is
available.
13.
However, as I’ve
pointed out in several posts including this
one, this last sentence needs to be modified for
most intelligent device manufacturers, including manufacturers of medical
devices. This is because those manufacturers almost never report
vulnerabilities in their devices to CVE.org (Cisco™ being one important
exception to this rule) – and that is the only way the vulnerability will ever
show up in the NVD or most other vulnerability databases (only a small
percentage of CVEs are reported by any organization other than the device
manufacturer or software developer). Why don’t they report vulnerabilities?
It’s because most device manufacturers only apply patches as part of full
device updates, which are often performed only once a year or even less
frequently. I agree the manufacturer shouldn’t report a vulnerability until
it’s patched, but that shouldn’t mean the device is vulnerable for up to a year
before the patch is applied. Instead, manufacturers should apply patches to
their devices at least quarterly.
As already mentioned, each
physical device label will contain a QR code; scanning that code will take the user
to standardized information about the device. In the NPRM last year, the FCC
proposed a centralized “registry” of devices that have received the Cyber Trust
Mark, updated by some central authority (presumably the FCC), based on
information provided by device manufacturers. The QR code would lead directly
to the registry, where the information about the consumer’s device would be
retrieved and displayed. However, the FCC received comments pointing out that
it would be “complex and costly” to try to manage this database centrally.
Instead of the centralized
registry, the FCC has decided to implement a decentralized approach (still
called a registry), in which consumers that scan the QR code on the device
label will be taken to an application that pulls a specified set of data directly
from the manufacturer using an API (application program interface). This means
the manufacturer will update their own data in a server that they maintain; the
server will be accessed whenever a consumer scans the QR code on one of their
devices. There will not be a centralized database. I agree with this decision.[ii]
The FCC proposes that the
“registry” provide the following information on each device that has the label:
(1)
Product Name;
(2)
Manufacturer name;
(3) Date
product received authorization (i.e., cybersecurity certification) to affix the
label and current status of the authorization (if applicable);
(4) Name
and contact information of the CLA that authorized use of the FCC IoT Label;
(5) Name
of the lab that conducted the conformity testing;
(6)
Instructions on how to change the default password (if the default password can
be changed);
(7)
Information (or link) for additional information on how to configure the device
securely;
(8)
Information as to whether software updates and patches are automatic and how to
access security updates/patches if they are not automatic;
(9)
Guaranteed minimum support period for the product (which may be zero, but must
be disclosed);
(10)
Disclosure of whether the manufacturer maintains a Software Bill of Materials
(SBOM).
Overall, I’m quite encouraged by
this new document from the FCC. I’m sure that, after another round of NPRM (or
something like it), comments from the public and further refinement by the FCC,
the program will be one that the US can be proud of. I think the many
comparisons that have been drawn between the Cyber Trust Mark and EnergyStar
are quite apt: It’s very possible this program will be as successful as
EnergyStar has been and still is – which is saying a lot.
Even better, I think Cyber Trust
Mark will prove to be a great example – not just in the US, but worldwide – of
the fact that, when it comes to cybersecurity, the carrot is often much better
than the stick. This is especially true in a regulation-averse country like the
US, where there is literally no federal agency that could enforce mandatory
cybersecurity regulations on a wide swath of the private sector - and there’s
something like a -50% chance there ever will be such an agency.
In a free market (which describes
the IoT market in most of the world), it’s likely that the best way to enforce
cybersecurity is by enlisting consumers to do the “enforcement” using their
dollars. We’ll soon learn if that’s true.
Any opinions expressed in this
blog post are strictly mine and are not necessarily shared by any of the
clients of Tom Alrich LLC. 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.
My book "Introduction to SBOM and VEX" is now available in paperback and Kindle versions! For background on the book and the link to order it, see this post.
[i] Note
that, since nothing in the FCC document is set in stone at the moment, any of
the statements in this post may prove to be inaccurate later.
[ii] The
FCC doesn’t mention anything regarding the database on the manufacturer’s side,
which will be queried by the API. That will need to follow a strict specification.
No comments:
Post a Comment