Friday, March 8, 2024

The FCC’s device cybersecurity labeling program takes shape!

 

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