For many decades, consumers have relied on labels to help them make decisions about which products to buy. Sometimes the labels make assertions about what ingredients or components the product uses. (What’s in that peanut butter?) Other times labels claim a level of performance. (How much storage does that laptop have?) These statements may come from the manufacturer or from a third party who has reviewed and perhaps tested the product. (This appliance has been tested to meet specific electrical safety standards) Labels have assisted manufacturers and retailers to help consumers make more informed purchasing choices. Presumably, labels also have improved the quality and performance of available products by upping the ante for manufacturers and retailers who compete for consumers’ business.
That’s the motivation behind a key provision in the May 12, 2021, Executive Order (EO) on Improving the Nation’s Cybersecurity. The order assigned NIST a host of responsibilities, most aimed at improving cybersecurity related to the software supply chain. NIST also was tasked to develop cybersecurity criteria and labeling approaches for consumer software and Internet of Things (IoT) products and then to initiate pilots based on those criteria.
The EO set a 270-day deadline for these two efforts; NIST delivered “the goods” on February 4. The pilot consists of NIST seeking contributions from stakeholders regarding current or potential future labeling efforts for consumer IoT products and consumer software, and how those efforts align with the NIST recommendations.
Let’s look at what we’ve heard and learned so far. Below, the lead of each effort reflects on what the road toward the labeling criteria looked like. First, some background...
Rather than establishing NIST’s own program, we aimed to identify key elements of labeling in terms of minimum recommendations and desirable attributes. The labels themselves are intended for use by consumers, many of whom will not have a detailed background in technology or cybersecurity—but those building IoT and software (or involved in the labeling process) needed to understand the technical aspects of our recommendations. We also knew that any requirement has the potential to add cost and some burden.
So, who would “own” a consumer-oriented cybersecurity labeling effort? Anything that is to be labeled meaningfully calls for a formalized labeling scheme (or program) managed by a scheme owner. There are a variety of ways a labeling scheme can be constructed, with many players involved. To complicate matters, there is no one-size-fits-all prescription for tailoring cybersecurity requirements to software or IoT products. A scheme may set differing requirements for varying classes of products: consumer software and IoT products have certain characteristics in common, but they also differ in key respects. These decisions will ultimately fall on the scheme owner.
We recommend that a scheme owner develop a label that is binary; it should convey compliance with the labeling criteria without bogging down non-technical consumers. The product either does or does not meet specified criteria at a particular point in time. This simplicity also takes into account the limited space for label information on many IoT products and their packaging. It also reflects that software may have no physical component and will need to be represented in a digital “storefront.”
Some of our recommendations require conveying more information than a binary label can offer. That’s where the multilayered component comes in. This allows a binary label to point a consumer elsewhere to access more detailed information. It also accommodates the ever-moving target for cybersecurity performance that reflects threats and capabilities that may change as new vulnerabilities are discovered or software and IoT products are updated.
While there is overlap between consumer software and IoT products, they differ enough to warrant slightly different approaches for how the technical criteria were structured. So we produced one set of recommendations for each.
With that background, let’s hear from our two leads…
Thoughts from Michael Ogata, NIST Computer Scientist
Developing the recommended criteria for consumer software was a unique and, yes, nerve-wracking experience. We first had to wrap our heads around the target for these labels: that is, what is consumer software? Is the firmware in your car consumer software? What about an online service like an office suite or email client? Certainly, a video game counts as consumer software, but do you measure a mobile game, a console game, and a PC game in the same ways? We realized that a concrete definition wasn’t vital to the effort and could even hurt it by being too limiting. We opted to use the more general description that consumer software was software normally used for personal, family, or household purposes. This allows scheme owners to match and suit the needs of the stakeholders they wish to reach. This flexibility influenced the structure of our recommendations.
A label is a proxy or a vehicle for someone making claims about what is being labeled: “This soda has 120 calories per serving” or “this lamp has passed inspection.” However, these explicit statements belie implicit claims: “my calorimeter is accurate” or “the inspection process was carried out correctly and has requirements appropriate for the product being labeled.” A binary label conveys all the explicit and implicit requirements of the labeling scheme. The recommendations in our document took the form of claims (both explicit and implicit) that should be conveyed to the consumer by the label. However, NIST's approach gives a future scheme owner leeway to tailor labeling schemes to match their needs.
The software recommendations are split into two groups: 1) descriptive claims and 2) secure software development claims.
The descriptive claims identify certain critical facts about the label and the software being labeled. These cover acts such as: who is standing behind the claims made in the label, when those claims were made, and what constitutes the software under the purview of the label. The descriptive claims also convey to the consumer important cybersecurity information, such as whether the labeled software is still receiving security related updates and how those updates are delivered to the consumer.
The secure software development claims convey to the consumer that industry best practices were used during development. Those claims rely heavily on the NIST Secure Software Development Framework (SSDF), which generalizes industry best practices. The SSDF doesn’t require an organization to follow a specific set of practices. Rather, it identifies common practices that are represented in, and mapped to, existing formalized industry guidance. This is helpful to consumers because “industry best practices” can vary widely from developer to developer, even within the same industry. Our recommendations encourage scheme owners to express development requirements by way of the SSDF while also identifying specific elements that signal that industry best practices have been employed.
The recommendations we made set a strong foundation for any organization looking to establish and maintain a labeling scheme for software consumers.
Thoughts from Katerina Megas, Program Manager, NIST Cybersecurity for Internet of Things (IoT) program
On the other hand, when we started developing the criteria for consumer IoT, we wanted to reflect what we’d heard at our October 2020 workshop on consumer IoT and recognize that the landscape of IoT cybersecurity had strong existing foundations. We also aimed to build on buy-in for the work our Cybersecurity for IoT program has undertaken since October 2017. Given the consumer focus, we would need to adapt and tailor the core baseline described in the NIST IoT “8259” series. The baselines define technical abilities for IoT devices and non-technical supporting activities needed from device manufacturers for the security of IoT devices in real world applications.
Although we hadn’t developed our May 2021 white paper “Establishing Confidence in IoT Device Security: How do we get there?” with any specific market sector in mind, some themes from prior interviews and other feedback also helped to inform this effort. For example, we had heard: certain categories of customers cannot be expected to take extensive actions with respect to IoT security; the diversity and scale of IoT devices precludes having a single approach for establishing security confidence; confidence mechanisms (which are intended to provide varying types and degrees of assurance) can exacerbate problems of market fragmentation through narrow certifications or can mitigate by providing a certification that is recognized broadly; and customer awareness and training are essential to expanding the recognition of IoT security confidence mechanisms. We strived to keep these uppermost in our minds.
Before “picking up the pen” to start adapting the core baseline, we conducted an informal landscape review to identify and understand what standards, programs and schemes were out there. We found common threads across multiple efforts, both domestic and international, which showed a developing “general consensus” on the core baseline. This was good news! We also found that some efforts focused not just on the IoT device delivered in the box, but on the IoT product which consisted of the device and supporting software such as a smart phone app or hardware such as a controller device. Other efforts were more prescriptive and potentially brittle when thinking about a sector as diverse as the IoT. We also were reminded about the challenge of managing labeling schemes in a rapidly changing landscape such as IoT, where the threats and maturity of the market continue to evolve, as do expectations for security.
We rolled up our sleeves and started writing, applying the insights just described and our program’s core principles. First, we adapted the core baseline to consider the complete IoT product, because the landscape review showed support for this and it provided manufacturers with the flexibility to implement the core capabilities across all components of their products (rather than just on the IoT device). This approach was also better aligned with the general consumer, who likely sees a label on a product as everything that delivers the “smart” features and doesn’t distinguish whether access is controlled by the device itself or by the app on their smartphone, for instance.
Next we considered tiers. Based on our IoT cybersecurity program’s experience, we knew our work needed to be grounded in an understanding of risk, with risk being both contextual (based on specific use) as well as on the unique nature of IoT products being capable of interacting with the physical world by collecting data or effecting changes without human intervention. Tiers could potentially reflect increasing levels of risk. But, when we considered whether the average consumer would be equipped to determine the appropriate risk level for their use case or device, we decided to first establish a baseline starting point that represented a meaningful minimum. This baseline should clearly relate to cybersecurity events that have impacted IoT in the past as a guidepost. As the market and schemes evolve over time, profiles and tiers tailored to the product types might be identified and developed to address risk levels. Another one of our principles states that no-one-size-fits-all when it comes to IoT. And we embrace the NIST Cybersecurity Framework approach of describing desired cybersecurity outcomes rather than being prescriptive. Allowing for a marketplace of standards, programs, and schemes to evolve would permit the market to drive how best to achieve the desired outcomes and offer the flexibility to suit a variety of stakeholders’ needs. Doing so also would accommodate, and not hinder, a rapidly evolving technology landscape.
Perhaps most importantly, like many other NIST efforts, including the consumer software cybersecurity labeling assignment, our IoT labeling program placed a premium on stakeholder engagement. Hearing from a wide range of stakeholders representing diverse perspectives – consumers, cybersecurity researchers, and manufacturers – we developed and refined our recommendations. Now we look forward to learning about what existing or new labeling scheme owners think and might plan to do to use labeling to inform consumers about cybersecurity aspects of products they are purchasing. We can’t wait to hear!