Cybersecurity labels can convey the cybersecurity status of a software product or connected device. But would these labels be useful, and what is a software product in connected cars and consumer appliances anyway?
The idea of cyber security labels for the Internet of Things (IoT) and consumer software has been kicking around for years, and has recently been taken up more seriously in The United StatesAustralia, United Kingdom and elsewhere In October, Singapore and Finland agreed to recognize each other’s cybersecurity labels for IoT devices.
But the labels were required to be given serious consideration in the US as part of President Biden’s cybersecurity Executive Order 14028 of May 2021, “Enhancing the Nation’s Cybersecurity.” Biden signed the EO shortly after the massive SolarWinds software supply chain attack and a series of ransomware attacks on critical infrastructure.
WATCH: Cybersecurity: let’s get tactical (ZDNet special report)
Part of the order required the US National Institute of Standards and Technology (NIST) to consider product labeling for IoT devices and software development practices for consumer software, in order to boost cybersecurity education.
NIST only sets guidelines for a US cybersecurity labeling scheme, which would likely be enforced by the Federal Trade Commission (FTC), given its existing oversight of consumer protection and data privacy laws.
As they point out, there are practical examples of labels for food safety, appliance performance, and appliance electrical safety. These help consumers make informed decisions and provide incentives to improve product safety and quality. But the software is different.
Michael Ogata, a computer scientist at NIST, says that developing the recommended criteria for labeling consumer software was a “harrowing experience,” in part because of difficulties defining where software begins and ends today.
“What is consumer software? Is your car’s firmware consumer software? What about an online service like an office suite or email client? Certainly, a video game counts as consumer software, but are a mobile game, a console game, and a PC game measured in the same way?” he writes.
Finally, a definition of consumer software emerged as: “software normally used for personal, family, or household purposes.”
One of NIST’s key recommendations for labels, whatever scheme runs it, is that they are “binary,” in the sense that the product either 1) meets the criteria at a given point in time, or 2) doesn’t. . Also, they shouldn’t “bog down” non-technical consumers with jargon.
Another complication in labeling software can be seen on soda cans that list the number of calories per serving. Is the tool used to measure calories accurate? So, an explicit and implicit claim is made about the soda cans. NIST-recommended software labels should cover both explicit and implicit claims.
These include descriptive claims and security software development claims. The descriptive statements cover whether tagged software still receives security patches and how they are delivered to consumers. Also, which body is behind the claims and when the claim was made.
On the secure development side, NIST relied on its own NIST Secure Software Development Framework (SSDF) as a basis for industry best practices. It is a non-prescriptive document, but “identifies common practices that are represented and mapped to existing formalized industry guidance.
“Our recommendations encourage scheme owners to express development requirements through the SSDF while also identifying specific elements that indicate industry best practices have been employed,” explains Ogata.
Katerina Megas, director of programs at NIST Cyber security for IoT program, offers a snapshot of how complicated it would be to create cybersecurity labels for IoT devices. After studying other labeling schemes around the world, Megan says her team made sure there seemed to be a “general consensus” developing that IoT products include not only the device, but also its supporting software, such as a smartphone app or hardware as a controller device.
Megas says the group took a risk-based view of the baseline security issue with “risk being both contextual (based on specific use) and the unique nature of the IoT products they are capable of interfacing with.” the physical world by collecting data or making changes without human intervention.
The NIST guidelines also recognized that “there is no one size fits all when it comes to IoT.” NIST seems to prefer market leaders in creating a baseline rather than having strict rules passed down to manufacturers.
“Allowing a market of standards, programs and schemes to evolve would allow the market to drive the best way to achieve desired results and offer the flexibility to adapt to a variety of stakeholder needs. Doing so would also accommodate, and not hinder, a rapidly evolving technology landscape,” writes Megas.