Last week the Federal Communications Commission (FCC) released a document describing how it plans to help secure consumer internet of things devices through a voluntary cyber labeling program. The proposed rules leave a lot of details to a soon-to-be appointed administrator, but the agency has clearly listened to consumer advocates such as Consumer Reports in crafting the proposed program.
Last fall Consumer Reports filed comments with the FCC about the creation of this program with a focus on six criteria. This proposed program strongly delivers on two of them, while leaving the door open to continuous improvement that could cover more of our requests after the cyber labeling requirements are fully developed.
In our comments we said:
- The label should evaluate the IoT product in its entirety, not as only a hardware device. This is because an IoT product includes the sum of all its parts including the cloud, the app, the networking between the device and the app, as per the NIST 8425 definition.
- Any device maker should follow basic cybersecurity principles, such as not using default or easily anticipated passwords, a vulnerability disclosure program and a patching program that include regular security updates.
- Device makers should commit to updating their device using over-the-air updates for a set number of years and disclose this support lifetime on the product’s box and at point of purchase.
- Device makers should securely store device data at rest on the device and in the cloud, and in motion when traversing local and public networks using accepted encryption methods.
- Because privacy and security are deeply intertwined, manufacturers should disclose the types of sensors inside a device, the data those sensors collect, and who has access to that data as part of the second layer of data shared by the manufacturer.
- Manufacturers should submit a Software Bill of Materials (SBOM) associated with the connected device and the cloud applications supporting it.
The program plan currently delivers on covering the entire IoT product and on including a software bill of materials. We applaud the FCC for focusing on the entire product as opposed to simply requiring cybersecurity rules for the individual device. When a consumer buys a connected light bulb, she isn’t only concerned that the bulb itself meets a baseline set of cybersecurity standards, but that her data and access to the product are protected in both the application and the cloud that supports the application. The FCC clearly recognizes that a connected product is the sum of multiple parts and has created a program that will assess all of those components for security.
We are also glad to see that the agency recognizes the importance of a software bill of materials when it comes to consumer IoT devices. Providing SBOMs is a best practice in cybersecurity frameworks for medical devices and enterprise software, and bringing that level of documentation to consumer devices is forward thinking.
We do have a few concerns about the proposal because it seemingly allows for a manufacturer to set a default password that cannot be changed. The inability to change the default password on networked DVRs was a vulnerability exploited by the Mirai botnet, which launched the current era of concern related to consumer IoT device security. It’s possible that the agency might be referring to unique passwords set into a device’s silicon when referencing default passwords that cannot be changed. We’d like to see the FCC or the eventual administrator of the program provide clarity on this feature.
There is also room for the program to include strong requirements for product updates and secure data transmission and storage if the entity appointed to administer the program and dictate the specific security requirements decides to include them. That entity could also require an IoT product to add elements that would support user privacy, but as issued today, the FCC’s rules do not require the manufacturer to share the types of sensors on the device, the data those sensors collect, and who has access to that data.
In another loss for consumers, the labeling program will require that manufacturers report a guaranteed minimum support period for the product, but noted that that support period might be zero. This is frustrating because a connected device without security updates is unsafe to operate, so any product without any guaranteed support time frame forces the consumer to gamble on the product’s longevity when they buy that particular product. We are glad to see that the program requires manufacturers share this information so consumers can better compare how long one connected product might last over another.
So let’s look at the details. The labeling program envisions a cyber label mark (pictured below) and a QR code on the packaging of any participating consumer device. Consumers can scan that QR code to find out additional security information about the product in a consumer-friendly format. The FCC has established a minimum amount of security information that consumers can access using the QR code.
The security information includes the product name, the manufacturer’s name, the date the product received the mark and its current status, the name of the testing lab that tested the product, instructions on how to change the default password (if the default password can be changed), a link for more information on setting up the product securely, where software updates can be found and how they are handled, the minimum support period, and whether or not the manufacturer has a software bill of materials available. The FCC does anticipate that this list will get additions over time.
Missing from the program are the actual sets of security rules that a product will have to follow in order to achieve the mark. The FCC says that it will work from the National Institute of Standards and Technology profile created for consumer IoT devices, but it will hire a lead administrator for the labeling program to actually create the requirements. Broadly, the NIST profile suggests how a manufacturer designs for security without actually setting requirements.
For example the NIST profile recommends that data should be secured during transmission and storage, but it does not dictate the level of encryption or security required. In another example the NIST profile suggests that devices should be updateable, but does not dictate how an update and patching program should work.
The FCC will vote on the proposed plan on March 14, and if approved, will need to find an entity to set the specific security requirements. There’s no set time frame in the document, but I know that the FCC and the current administration really want to see this program in place by the end of this year.
So there’s still a chance for more rigorous security requirements, but as it stands today the cyber labeling program will provide some transparency for consumers concerned about their privacy and security, while also leaving some pretty big gaps that still need to be addressed.
