NIST gears up for software security and IoT labeling pilot programs

Intended to help consumer make more secure software and IoT device purchases, the labeling guidelines are voluntary and self-policing at this time.

President Biden’s wide-ranging cybersecurity executive order issued last May directs the National Institute of Standards and Technology (NIST) to create pilot labeling programs to educate the public on the security of the internet-of-things (IoT) devices and software products they buy. The order requires NIST to produce by February 6, 2022, IoT cybersecurity criteria for a consumer labeling program and, separately, identify secure software development practices or criteria for a software labeling program.

To those ends, NIST held a workshop in September and solicited comments from stakeholders and experts. Based on the input received in these efforts and after issuing preliminary draft papers that outline various approaches, NIST issued draft Baseline Criteria for Consumer Software Cybersecurity Labeling on November 1 and a discussion draft on Consumer Cybersecurity Labeling for IoT Products on December 3.

After NIST produces both the IoT and software criteria in February, it will begin a labeling pilot testing phase. That phase will consist of NIST engaging with organizations that currently offer consumer labeling options. NIST says it may also decide to establish measures to demonstrate further proof of concept based on the criteria it publishes.

No one-size-fits-all for software security labels

Numerous challenges stand in the way of creating labels for inherently complicated software products. As NIST’s most recent software labeling report states, “There is no one-size-fits-all definition for cybersecurity that can be applied to all types of consumer software,” because risks associated with any piece of software are innately tied to the software’s intended use. The cybersecurity considerations appropriate for a mobile game will differ from those applied to, for example, an online banking app or running a media station in a car.

NIST stresses that it is not trying to design the software cybersecurity labels itself but instead is laying out a set of “desired outcomes” that allow and enable the marketplace of software makers, third-party labeling providers, and consumers to make informed choices. Nevertheless, NIST has developed tentative technical criteria for security labels on how software makers should attest to them and what information providers should make available to consumers.

These draft attestations, which are discussed in granular detail in NIST’s latest draft paper, are:

  1. Descriptive attestations that identify who is making claims about information within the label, what the label applies to, when the attestations were made, and how a consumer can obtain other supporting information required by the label
  2. Secure software development attestations, which in essence contain information on the recommended secure software development practices that were employed
  3. Critical cybersecurity attributes and capability attestations that describe features expressed by the software resulting from implementing a secure software development process
  4. Data inventory and protection attestations that highlight how data are stored, processed, or transmitted by the software

On December 9, NIST held a second workshop to discuss the status of both its IoT and software labeling efforts. Speaking at the workshop, NIST Computer Scientist Michael Ogata said that “all of the attestations in the technical criteria have to be satisfied to display the label on a piece of software. However, it does not address how the attestations should be represented on the label. You can think of this in terms of, if a label evolves into something that is a seal of approval, then that would engender all of the technical criteria but maybe not display them.”

One hitch in the plan is that these labels are voluntary, with no government requirements or recommended verifications that the software providers can back up their attestations. “NIST is not really in the space of doing that right now,” Ogata said.

IoT labels could be binary

Like its approach with software labels, NIST will identify critical elements of an IoT labeling program in terms of minimum requirements and desirable attributes rather than setting up its own program. NIST plans to specify desired outcomes that allow providers and customers to choose the best solutions for their devices and environments.

The challenge for any IoT labeling program is that, as NIST notes in its paper, “Consumers generally do not have the expertise to distinguish between different technical or conformity assessment requirements.” For this reason, NIST is tentatively suggesting that the IoT labels be “binary,” a “seal of approval” label showing a product has met a baseline standard.

The tentative broad general guidelines NIST has developed for IoT label criteria include:

  1. Product identification, which is likely necessary but may be omitted for some IoT product components if, among other things, product component identities are not generated, managed, or used by the IoT product
  2. Product configuration, which may not be needed if configuration by the customer of IoT product features offers no cybersecurity benefits
  3. Data protection, which will likely be necessary on all components
  4. Interface access controls, which will always be necessary on all components
  5. Software update, which will likely be necessary for most IoT product components in some form
  6. Cybersecurity state awareness, which will be necessary for all IoT products and should cover all IoT product components since vulnerabilities and threats can arise from any component
  7. Documentation, which will always be necessary, but specific information may not be meaningful to all IoT products
  8. Information and query reception, which will always be necessary given the nature of the consumer marketplace and the need for proactive support of cybersecurity by IoT product developers
  9. Information dissemination, which will always be necessary given the nature of the consumer marketplace and the need for proactive support of cybersecurity by IoT product developers
  10. Education and awareness, which will always be necessary, but specific information may not be meaningful to all IoT products

NIST is looking to map to detailed standards about the technical criteria behind the IoT labels, but “keep in mind this whole process is under construction,” NIST Information Technology Specialist Paul Watrobski said during the December 9 workshop. “We expect flow back and forth as we develop criteria based on standards, and they can be modified as it becomes clear certain criteria are important.”

Voluntary nature of labels lets vendors invent their own schemes

As is true with the software labeling initiative, the IoT labeling program is voluntary and not backed by government requirements. As NIST envisions the outcome of its work, it is up to third-party labeling vendors to tailor the baseline product criteria, define the conformity assessment requirements and develop the label associated with the information.

“As things are right now, if things are left voluntary, there are no legal or financial repercussions on the vendor if they do a bad job,” Dr. Andrei Costin, CEO and co-founder of IoT firmware security firm Binare.io, tells CSO.

Any third-party label then “becomes a marketing label. It gives vendors all the freedom to invent their own labeling scheme that they can use as marketing. But it also causes confusion for the consumer because if it’s not an apples-to-apples comparison [to competing label providers], it doesn’t tell anything to the consumer. A consumer will still make a badly informed decision,” Costin says.

“If everything is voluntary and they can choose their own labeling, basically they will be free to put everything that makes their product look marketing-wise more attractive [on their label], but in essence, it will not be more secure,” says Costin. “These things definitely need policy or political support, whether a law or a regulation from regulatory bodies. Otherwise, it will just be another piece of standardization, which is really nice but doesn’t serve the purpose.”

However, after NIST meets its February deadlines on the labeling initiatives, it must mount pilot programs to gauge these and other potential problems. Under Biden’s executive order, NIST must submit a report by May 12, 2022, to the assistant to the president and national security advisor (APNSA) that contains a review of the pilot programs. As part of that review, NIST is obligated to consult with the private sector and relevant agencies to assess the effectiveness of the programs and determine what improvements can be made in the future.

Copyright © 2021 IDG Communications, Inc.

Microsoft's very bad year for security: A timeline