This past September Governor Brown signed into law Senate Bill 327, which is the first state law designed to regulate the security features of Internet of Things (IoT) devices. The bill sets minimum security requirements for connected device manufacturers, and provides for enforcement by the California Attorney General. The law will come into effect on January 1, 2020, provided that the state legislature passes Assembly Bill 1906, which is identical to Senate Bill 327.
Connected devices are already part of our everyday lives, and will increasingly include a large number of the consumer products we use daily, including automobiles, smart TVs, home monitoring and management systems, toys, wearable health-related monitors, and a range of appliances. Moreover, critical industries, including the transportation, manufacturing, agriculture, healthcare, and energy sectors, are increasingly relying on data from sensors and smart devices to increase efficiencies, reliability and accuracy in delivery of services and products. Our city landscapes are also changing with the integration of smart traffic lights, smart lighting, smart cameras, smart buildings, and smart security.
While this ubiquitous interconnectivity will bring substantial benefits in terms of increased analytic accuracy and diagnostics, productivity and efficiency in the provision of services, and advances in public health, hackers will also find ways to exploit vulnerabilities in IoT devices to steal data, cause outages, disrupt or modify system functions, and commit other malicious acts.
The new law is intended to address these threats by requiring manufacturers to build security into the design, manufacturing, and functioning of connected devices.
Who does the law apply to?
The law applies to manufacturers of “connected devices” sold or offered for sale in California, as well as component parts suppliers for such manufacturers. Manufacturers and third-party parts suppliers are required to ensure that “connected devices” incorporate “reasonable security features” designed to protect the device and the data collected, stored, or transmitted on the device, from unauthorized access, destruction, use, modification, or disclosure. The law specifically exempts from coverage developers of third-party software or applications that consumers themselves may add to their connected devices and businesses regulated by the Health Insurance Portability and Accountability Act of 1996 (HIPAA).
What is a connected device?
Under the new law, a “connected device” is defined as “any device, or other physical object that is
capable of connecting to the Internet, directly or indirectly, and
assigned an Internet Protocol address or Bluetooth address.”
In other words, if a product or “thing” can communicate and interact over the Internet, and can therefore be remotely accessed, monitored and controlled, then it is a connected device. Because the law is intended to mitigate the risk of unauthorized access to those networked devices that are a part of the Internet of Things ecosystem, if a device is only accessible with a local connection (i.e. on the same Wi-Fi network, or using Bluetooth only, with no control from the Internet), it does not fall under the definition of a connected device.
What is technically required?
If you are a manufacturer of a connected device or one of its component parts, then the law requires you to
Ensure the device is equipped with “reasonable security features”; and
Complies with the specific authentication requirements that are described more fully below.
Reasonable Security Features
Although the IoT law does not define what “reasonable security features” means, it does recognize that the “reasonableness” of security safeguards are risk-based and highly dependent on the type of product, its intended use, and the technology on which it relies. Specifically, the law states that a connected device’s security features must be:
appropriate to the nature and function of the device;
appropriate to the information it may collect, contain, or transmit; and
designed to protect the device and any information contained in the device from unauthorized access, destruction, use, modification, or disclosure.
Although this requirement is consistent with the risk-based principles for assessing “reasonable security” in traditional cybersecurity contexts, it does not provide much practical guidance to manufacturers of connected devices. Notwithstanding this inherent ambiguity, lawmakers and regulators have started to promulgate guidance documents on best practices and standards, primarily on an industry-by-industry bases. For example, the Federal Trade Commission (FTC), which has broad authority over consumer product safety under section 5 of the FTC Act, issued the Internet of Things Privacy & Security in a Connected World guidance document in 2015. The FTC has also taken enforcement action against connected device manufacturers, thus developing a set of regulatory expectations for manufacturers with respect to cybersecurity. See, e.g., In the Matter of TrendNet Inc. (Jan. 2014); In the Matter of ASUSTeK Computer, Inc. (Feb. 2016). In the eHealth industry, the Federal Drug Administration (FDA) has promulgated several guidance documents relating to the development and manufacturing processes associated with the security of connected medical devices, as well as the continuing post-market expectations on manufacturers to secure devices throughout their lifespan. See Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (10/2014) and the Postmarket Management of Cybersecurity in Medical Devices.
Similarly, the FTC and the National Highway Traffic Safety Administration (NHTSA) held a workshop on security and safety of autonomous vehicles in June 2017, in part to discuss developing standards.
Finally, for those IoT manufacturers who sell to the federal government, in 2017 the Senate passed a bill entitled the Internet of Things Cybersecurity Improvement Act of 2017 (S. 1691), which would establish security requirements and a certification processes for manufacturers that supply connected devices as government contractors.
2. Authentication Features
The CA law also contains specific requirements on authentication features to address access to IoT devices. If a product or device is connected to the Internet such that it is assigned an IP or Bluetooth address for authentication purposes, then the law requires that the default password to access or use the device must be unique (i.e. the same pre-programmed or hard-coded password may not be used across devices); or, functionally, the users are required to generate a unique password at the time of first use or access.
The law’s focus on authentication likely stems, in part, from the Mirai botnet attacks that caused significant website outages in October 2016. In that attack, hackers exploited a hardcoded default password in the firmware of a particular component part used in home routers and video recorders (DVRs) to take control of millions of those devices to attack critical systems on which the world wide web depends.
Enforcement & General Regulatory Framework
The California State Attorney General, as well as local city, county and district attorneys, are charged with enforcing the new law. The law does not establish a private right of action for alleged violations. However, the law does not preclude potential civil claims or enforcement by federal regulators, including the FTC for “unfair” and “deceptive” practices.
What can manufacturers do now?
In short, what constitutes reasonable security features in connected devices will be highly dependent on the risks posed by the particular technology and product – for example, what is reasonable security for a refrigerator may be different from what is reasonable for an implanted heart defibrillator. Despite the lack of clear guidance on what “reasonable security” means, the following baseline features for IoT manufacturers to consider in setting up their product development programs can be gleaned from current regulatory guidance:
Security by Default: Security features should be built into the product from design inception and considered throughout the product’s lifespan.
Secure Software Development Lifecycle (SSDL): Developers should be trained in and comply with established software development best practices (e.g., ISO/IEC 27034-1).
Supply Chain Diligence: Manufacturers should conduct due diligence on their component parts manufacturers (hardware, firmware, and software) and impose contractual requirements to ensure they are also following security best practices.
Integrity of the Development Process: Manufacturers should ensure employees are adequately trained on security; the development environment and Intellectual Property are properly protected; and standard quality assurance processes are followed.
Ongoing Monitoring and Maintenance: Because security extends beyond the factory floor, programs should be developed for post-marketing patching, monitoring, vulnerability handling, and product end-of-life practices.
Moreover, in developing an IoT device, there may be a host of other privacy issues to consider with respect to the collection, processing, and transmission of data. This is especially important if your device will be collecting children’s data.