NIST outlines what IoT and software ‘security labels’ could look like | ZDNet

Cybersecurity labels could convey a software product’s or connected gadget’s cybersecurity status. But would these labels be useful, and what is a software product anyway in connected cars and consumer appliances? 

The idea of cybersecurity labels for Internet of Things (IoT) and consumer software has been kicked around for years, and has recently been looked at more seriously in the EU, Australia, UK and elsewhere. In October, Singapore and Finland agreed to recognize each other’s cybersecurity labels for IoT devices.

But labels were required to be seriously considered in the US as part of president President Biden’s May 2021 cybersecurity Executive Order 14028, “Improving the Nation’s Cybersecurity”. Biden signed the EO shortly after the massive SolarWinds software supply chain attack and a spate of ransomware attacks on critical infrastructure. 

Part of the order required the US National Institute of Standards and Technology (NIST) to consider product labelling for IoT devices and software development practices for consumer software, in order to boost cybersecurity education. 

NIST only makes guidelines for a US cybersecurity labelling scheme, which would more likely be enforced by the Federal Trade Commission (FTC), given its existing oversight of consumer protection and data privacy laws.

NIST released its guidelines for such labels on February 4, and now its two leads for consumer software and IoT have shared their views on the pros and cons of cybersecurity labels.

As they point out, there are working examples of labels for food safety, device performance, and the electrical safety of appliances. These help consumers make informed choices and provide incentives to improve product safety and quality. But software is different.

Michael Ogata, NIST Computer Scientist, says that developing the recommended criteria for consumer software labelling was a “nerve-wracking experience”, in part because of the difficulties in defining where software begins and ends today. 

“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?,” he writes.

A definition of consumer software eventually emerged as: “software normally used for personal, family, or household purposes.”

One of NIST’s key recommendations for labels, whichever scheme runs it, is that they’re “binary”, in that the product either 1) does meet the criteria at a given time or 2) does not. Additionally, they should not be “bogging down” non-technical consumers with jargon.  

Another complication in labelling software can be seen in soda cans that list the number of calories per serve. Is the tool used to measure calories accurate? So there’s an explicit and implicit claim being made on soda cans. NIST recommended software labels should cover both explicit and implicit claims.

These include both descriptive claims and security software development claims. Descriptive claims cover whether the labelled software is still receiving security patches and how these are delivered to consumers. Also, what body stands behind the claims, and when the claim was made.

On the secure development side, NIST leaned on its own NIST Secure Software Development Framework (SSDF) as the basis for industry best practice. It’s a non-prescriptive document, but it “identifies common practices that are represented in, and mapped to, existing formalized industry guidance.”      

“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,” explains Ogata. 

Katerina Megas, a program manager for NIST’s Cybersecurity for IoT program, offers a snapshot on how complicated it would be to create cybersecurity labels for IoT devices. After surveying other labelling schemes around the world, Megan says her team was reassured that there seemed to be a developing “general consensus” that IoT products include not just the device but also its supporting software, such as a smartphone app or hardware such as a controller device.

Megas says the group took a risk-based view of the question of baseline security 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.” 

NIST guidelines also acknowledged “no-one-size-fits-all when it comes to IoT.” NIST appears to prefer the market leads in creating a baseline rather than having hard rules handed down to manufacturers.  

“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,” writes Megas.