IoT Ecosystem
December 18, 2019
By Leo Dorrendorf

Key Takeaways from the California "Security of Connected Devices" Senate Bill (SB-327)

The year 2020 is approaching and the state of security when it comes to connected devices is still far from satisfactory. Industry groups such as the National Institute of Standards and Technology (NIST) are still reporting on connected devices that were released with outdated and vulnerable software, or with severe security flaws in their implementation and architecture. You can see our analysis of one recent NIST report here.

With so many connected device manufacturers still neglecting to focus on the security of their products, it is not surprising that IoT botnets continue to proliferate, threatening the Internet as a whole, and exposing both home and business customers to privacy threats and data leakage. Luckily, more and more governments around the world are beginning to take regulatory action with legislation that aims to hold device vendors and service operators accountable for not taking proactive steps to secure their connected products.

In this article, we review one such effort - California Senate Bill 327 chapter 886 which is expected to take effect on January 1, 2020.

California SB-327 Overview

On September 28, 2019, California became the first US state to pass a cybersecurity law regarding connected devices. The bill will go into effect on the same day as California’s new Consumer Privacy Act (CCPA). Originally, CA SB-327 included privacy requirements but these were subsequently removed with the current version focusing solely on data security.

The main provisions of SB-327 are relatively concise. The law broadly defines connected devices as “any device or other physical object that is capable of connecting to the Internet, directly or indirectly”, and states that manufacturers of these devices must equip them with “reasonable security feature[s],” which are:

  • Appropriate to the nature and function of the device,
  • Appropriate to the information [the device] may collect, contain, or transmit, and
  • Designed to protect the device and the information it contains from unauthorized access, destruction, use, modification, or disclosure.

In general, CA SB-327 has been received with mixed opinions by subject matter experts, with some industry observers applauding it as a positive step not only within the IoT realm, but also as a potential model for related cybersecurity fields. Others have criticized the bill as too vague and therefore generally useless, claiming it is “much ado about nothing” rather than truly promoting cybersecurity measures for awareness and accountability.

A third viewpoint suggests that in addition to its direct effects on connected devices in the state of California, SB-327 could prompt the renewal of federal legislation on this subject, just as the CCPA spurred efforts to develop federal data privacy legislation. With several IoT security bills currently pending (and possibly stagnating) in Congress, a hopeful outcome of SB-327 would be renewed interest in the subject, as well as a helpful nudge in this sphere of legislation.

Below we analyze each section of this compact and clearly written bill from a technical perspective. The quotes included here cover almost the entire text of the bill so by the end of this article, you will be able to clearly understand the practical steps that it mandates, and what it might mean for the IoT industry as a whole.

California SB-327 - Introductory text

The bill begins with an introductory section which explains that existing law already requires businesses to take reasonable care of customer data and dispose of it securely. It specifically addresses the case of connected devices which collect, contain, or transmit personal information.

The intro explains the purpose of the bill very well and concisely, so we chose to include the full text as follows:

Existing law requires a business to take all reasonable steps to dispose of customer records within its custody or control containing personal information when the records are no longer to be retained by the business by shredding, erasing, or otherwise modifying the personal information in those records to make it unreadable or undecipherable. Existing law also requires a business that owns, licenses, or maintains personal information about a California resident to implement and maintain reasonable security procedures and practices appropriate to the nature of the information, to protect the personal information from unauthorized access, destruction, use, modification, or disclosure. Existing law authorizes a customer injured by a violation of these provisions to institute a civil action to recover damages.

This bill, beginning on January 1, 2020, would require a manufacturer of a connected device, as those terms are defined, to equip the device with a reasonable security feature or features that are 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 therein from unauthorized access, destruction, use, modification, or disclosure, as specified.

The comparison of SB-327 to existing law that allows a customer who was injured by a violation of the referenced provisions to institute civil action in order to recover damages should be carefully reviewed by manufacturers of connected devices. Although CA SB-327 specifically limits private right of action, it will be interesting to see what happens when consumers who were injured by a manufacturer’s lack of reasonable security try to introduce civil actions.

California SB-327 - TITLE 1.81.26. Security of Connected Devices

This section, which consists of two paragraphs, holds the actual contents of the bill. The first paragraph is more general:

(a) A manufacturer of a connected device shall equip the device with a reasonable security feature or features that are all of the following:

(1) Appropriate to the nature and function of the device.

(2) Appropriate to the information it may collect, contain, or transmit.

(3) Designed to protect the device and any information contained therein from unauthorized access, destruction, use, modification, or disclosure.

From the perspective of a connected device manufacturer, this paragraph in SB-327 does not dictate any clear or actionable steps. Although clause a) mandates "reasonable security features" and sub-clauses 1) and 2) further explain that the security features should be "appropriate" to the "nature and function" of the device and the information involved, the text does not mention any specific security controls which the manufacturer is required to apply. According to the wording of these clauses each manufacturer could release a device with the security controls they believe are appropriate. This will likely confuse consumers and manufacturers alike since it will be very difficult to objectively determine whether the applied security features were appropriate.

The wording “reasonable security features” exposes a clear gap in the connected device security market. Today, there is no objective method for determining whether any attention has been paid to the security posture of a specific connected device. Third party security certifications are useful in removing subjective criteria and demonstrating whether devices actually include reasonable security measures, which is why VDOO offers third-party certification CERTIoT.

Sub-clause 3) of SB-327 does add some focus in that the security features in question are supposed to protect information on the device as well as the device itself. This should include the device's intended functionality. When the manufacturer is facing the dilemma of whether to apply general security controls, for example to prevent the device from being enrolled in a botnet, the text above implies that they should.

According to the bill, the device and the information should be protected from "unauthorized access, destruction, use, modification, or disclosure". This could be understood as referring to security measures such as authentication, integrity controls and authorization on use or deletion, all of which can be translated to specific security requirements that can be applied by the manufacturer's engineering team. However, to the technical reader, the picture is far from clear. For example, do the protections of sub-clause 3) imply that information should be stored in encrypted form, or are programmatic authorizations and access controls enough? The bill's text leaves this and many similar questions unresolved.

The second paragraph is more concrete:

(b) Subject to all of the requirements of subdivision (a), if a connected device is equipped with a means for authentication outside a local area network, it shall be deemed a reasonable security feature under subdivision (a) if either of the following requirements are met:

Before we move on to the requirements, let's try to unpack the highly condensed sentence above.

The phrase "if a connected device is equipped with a means for authentication outside a local area network" defines a very concrete scope for the requirements detailed afterwards: they only hold for devices with an authenticated interface towards the public internet. This is an important point which we'll explain with an example.

Let’s take a smart doorbell device, for instance. If the doorbell provides LAN-only connectivity - that is, if it can only be accessed through local Wi-Fi - then the doorbell is exempt from the requirements. On the other hand, if the doorbell connects through the local Wi-Fi to an internet service such as a cloud server, then the requirements do apply.

So if the doorbell only transmits its video feed to nearby mobile phones and allows a user on the local network to unlock the door using an app, it will be evaluated differently per CA SB-327 than a doorbell that allows its owners to unlock the door for their guests even when they are not at home. This means that the same product might or might not be subject to the bill’s requirements, depending on how it was deployed and configured.

Assuming a case where the requirements do apply, what do they dictate? Unlike clause a), here the bill details two concrete security requirements:

(1) The preprogrammed password is unique to each device manufactured.

Unique per-device passwords are a highly recommended security measure. In fact, the use of predictable, repeated, or well-known passwords is one of the top security issues affecting connected devices. This poor security practice was the culprit behind the wide spread of the original Mirai botnet, and is still a major weakness exploited by current IoT attacks where hackers first try to take over devices with a few login attempts using well-known username and password combinations, before moving on to more sophisticated exploits if that doesn’t work.

In practice, generating per-device passwords can be difficult because it involves complex provisioning and management issues. The manufacturer needs to personalize each device's firmware with a unique password, which makes firmware generation, maintenance, and initial programming much more complicated. Further, these unique passwords must also be communicated to the devices' end users. This is usually done by printing the password on a label or sticker attached to the device or including it in the device's packaging some other way. If you take a look at your home Wi-Fi router, you might find a label on its underside with the initial Wi-Fi password.

Although some manufacturers choose to follow these steps, they impose quite a burden, and it is understandable that some manufacturers prefer to avoid them. This is probably why requirement 2) is offered as an alternative.

(2) The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.

This is a different way to achieve the same goal as the unique per-device passwords from requirement 1) while ensuring that the manufacturer does not have to encounter any provisioning and management issues. The problem with this option is that it shifts the burden from the manufacturer to the user because the device is inaccessible until the user runs through an initialization procedure which includes defining a password. Again, this is typical for some Wi-Fi router setups where the end user is required to choose the initial parameters for the device, including a unique password, through a web interface.

California SB-327 Definitions

The bill continues with a section defining the meanings of the terms used within, such as "Authentication", "Connected device", or "Security feature" (those should be self-explanatory to anyone in the industry, and we will not include them here).

Scope of California SB-327

The bill's next section contains legal statements which further explain its scope. Some of them warrant careful attention:

1798.91.06.

(a) This title shall not be construed to impose any duty upon the manufacturer of a connected device related to unaffiliated third-party software or applications that a user chooses to add to a connected device.

This clause explains that the manufacturer is only responsible for the state of the device as deployed. If the device is later customized by the user (for example, by installing other software or applications) then the manufacturer is not responsible for the security of the newly installed software.

(b) This title shall not be construed to impose any duty upon a provider of an electronic store, gateway, marketplace, or other means of purchasing or downloading software or applications, to review or enforce compliance with this title.

Similar to the above, this leaves third-party application stores and any software installed after the device is purchased out of scope. Only third-party software integrated as part of the sold device is in scope for the bill.

(c) This title shall not be construed to impose any duty upon the manufacturer of a connected device to prevent a user from having full control over a connected device, including the ability to modify the software or firmware running on the device at the user’s discretion.

Again, end-users can customize their devices but if they do then the manufacturers are not responsible for the results.

(d) This title shall not apply to any connected device the functionality of which is subject to security requirements under federal law, regulations, or guidance promulgated by a federal agency pursuant to its regulatory enforcement authority.

This is an interesting point. Some devices could be subject to security requirements under federal law. This includes medical devices (further addressed separately below) but also, for example, cryptographic modules which are covered by federal regulations if sold to the United States government. Rather than making the requirements above cumulative with any applicable federal regulations, the bill prefers to leave such devices out of scope. A better approach may have been for CA SB-327 to state that adherence to federal regulations implies that the vendor meets the intent of this bill.

(e) This title shall not be construed to provide a basis for a private right of action. The Attorney General, a city attorney, a county counsel, or a district attorney shall have the exclusive authority to enforce this title.

Although SB-327 purports to protect customer data and privacy, only the authorities can take actions against offending vendors, not the customers themselves.

(f) The duties and obligations imposed by this title are cumulative with any other duties or obligations imposed under other law, and shall not be construed to relieve any party from any duties or obligations imposed under other law.

(g) This title shall not be construed to limit the authority of a law enforcement agency to obtain connected device information from a manufacturer as authorized by law or pursuant to an order of a court of competent jurisdiction.

The two paragraphs above pertain to the legal scope of the bill and are largely self-explanatory.

(h) A covered entity, provider of health care, business associate, health care service plan, contractor, employer, or any other person subject to the federal Health Insurance Portability and Accountability Act of 1996 (HIPAA) (Public Law 104-191) or the Confidentiality of Medical Information Act (Part 2.6 (commencing with Section 56) of Division 1) shall not be subject to this title with respect to any activity regulated by those acts.

As mentioned above, medical devices are covered by their own regulations and are not subject to this bill.

(i) This title shall become operative on January 1, 2020.

Summary: SB-327 is a Good Start, but Should be Expanded

California Senate Bill (SB) 327 is definitely a step in the right direction, as it outlines the regulator's major goals and defines the initial actionable measures that need to be applied. However, the bill is very vague in defining most of the necessary protections and leaves a lot open to interpretation. The only steps which are technically well-defined - two alternative methods of equipping the device with a unique password - are a drop in the sea of cyber-security requirements. As a result, although these steps address one of the most common attacks in the IoT space, all other cyber-security topics are left unaddressed.

For comparison, the UK DCMS Secure by Design effort includes a "Code of Practice for Consumer IoT Security" which describing 13 security requirements. It defines the first three requirements as top priority: unique passwords (same as in CA SB-327), vulnerability disclosure, and software updates. The document then goes into further requirements such as secure communication, credential storage, information privacy, and more. The UK document is based on considerable research efforts, and it makes sense for the US regulator to adopt similar requirements.

Although as it stands today, California Senate Bill 327 does not address several critical pieces of the cyber-security landscape, it is useful in exposing critical gaps in the product security market. 3rd party certifications that support objective determination of a product’s security state would go a long way towards helping customers make informed decisions, as well as towards holding manufacturers accountable for the way they handle security issues when it comes to their connected devices.

In addition, regulations such as CA SB-327 should also be introduced and adopted at the U.S. Federal level with a scope that reaches far beyond what is procured by the Federal Government. Finally, manufacturers must perform their due diligence, well above and beyond what is mandated by this legislation, including analyzing their products for weaknesses prior to shipping using tools such as VDOO Vision.

Read more about ensuring optimal security for Connected Devices

Share this post

You may also like