On January 31, 2019, Commissioner Elliot Kaye of the Consumer Product Safety Commission (CPSC) released a framework for safety standards on devices connected to the Internet of Things (IoT). Commissioner Kaye’s framework discusses how, in devices ranging from wearable fitness trackers to elevator controls, firmware or software vulnerabilities could lead to death, injury, or illness. (The framework does not focus on data security or privacy issues).
Commissioner Kaye’s framework is not an official, binding standard – the introduction states that the goal of the framework is “promot[ing] discussion and debate.” Nevertheless, the ideas expressed in Commissioner Kaye’s framework may provide useful guidance for manufacturers contending with California’s IoT security law, which goes into effect on January 1, 2020 (Cal. Civil Code §§ 1798.91.04-06).
California’s law requires manufacturers to equip devices with “reasonable security feature[s]” to prevent “unauthorized access [or] use,” among other things – likewise, the Commissioner’s framework cautions against “criminalization / weaponization” by unauthorized users. With one exception, the California law does not generally expand on what measures are “reasonable.”
Voluntary standards, advisory guidelines, and “reasonableness” standards permeate cybersecurity law, often without providing clear, useful solutions. Fortunately, the Commissioner’s framework includes methods that may help manufacturers determine and document their decisionmaking about which security features are “reasonable” enough to meet their obligations under California law. For example, the framework suggests:
- Engaging a “qualified safety supervisor” to supervise product development; processes and focus on how security vulnerabilities could lead to injury;
- Obtaining industry standard certifications for key components;
- Requiring separate user authorization for especially dangerous actions and automatically overriding user commands where sensors indicate hazardous conditions; and
- Relying on physical safeguards rather than software protections, where possible.
More importantly, the framework encourages creative thinking about how unauthorized access (or other vulnerabilities, like power outages or failure to download software patches) could lead to danger. A “reasonable” approach might not require effective prevention of every possible hazard, but thinking through unusual scenarios could help developers see beyond narrow threats and come up with comprehensive solutions.
As an (admittedly) simplistic scenario, consider a toy that can be controlled remotely over the Internet. Product designers may be primarily concerned with ensuring that the software does not cause the toy to malfunction in a way that hurts the child playing with it by overheating, sparking, or exposing sharp edges – and therefore, might code for an automatic shutoff if the toy’s processor runs at a rate that could risk overheating.
Thinking creatively, however, a vulnerability in the toy’s software could effectively provide bad actors with a mobile, limited-function robot alone in a victim’s home. Thinking through the outlandish things hackers could do with the toy – obstructing entryways, destroying property, or triggering motion sensors linked to security alarms (potentially causing a police response) – might help designers realize that the toy should not be operable unless an authorized user is physically nearby. This fix would, of course, also better-protect children playing with the toy – they would be less at risk of injury if a parent is in the room.
