Guest opinion: California’s security law is a good start; let’s build on it

We asked Adrian Sanabria, advocate for Thinkst Applied Research, about his thoughts on the law and its implementation. Among the questions we asked:

· What is the law missing?
· How will this law affect manufacturers (in terms of restrictions and what they will be able to deliver vs consumer expectations)?
· Do you think some industries will be more affected than others?
· How would you define a connected device?
· How would you explain/define “reasonable security”?

Sanabria’s response follows:

Overall, I want to make it clear that the California IoT Law should be seen as a win. Killing off default passwords is a big win, though we all recognize more steps will need to be taken. I imagine there was pressure to compromise on how much security to force on businesses, especially those manufacturing consumer products, where a sudden landslide of new, prescriptive security requirements could have a negative impact on user experiences and revenue. Imagine how frustrating using a voice assistant would be if there was only a single extra step required, to validate each spoken command.

“Alexa, play music”
“Confirming, you want to play music?”
“Yes, Alexa, play music”
“Playing music”
“Alexa, volume 5”
“Confirming, you want to change the volume from level 3 to level 5?”
“ YES ALEXA, VOLUME 5″

Part of the reason we’re seeing such vague language (“Appropriate to the nature of…”) is because devices are so varied now that specific requirements like we see in the credit card industry’s PCI DSS, would likely make some types of devices unusable. The problem is, “Appropriate to the nature of…” isn’t enforceable language. “Appropriate” is debatable and relative, leaving the password requirements the only enforceable part of SB 327.

Default passwords on IoT devices have caused significant problems for decades (the Mirai botnet is the most severe example), so many manufacturers have already made changes that comply with SB 327. However, there are always vendors and businesses that will resist doing the extra work of building in security best practices until legislation or regulation forces them to do so.

The password requirements shouldn’t be onerous for most manufacturers to comply with, but even these simple requirements don’t apply well in some cases. For example, there’s no way to enter a pin on your Bluetooth headphones to pair them with your phone. While that example sounds silly, there are real security risks. Most modern headphones have built-in microphones, so you don’t have to take them off to answer a call. How do we prevent someone from remotely pairing with our headphones and using that microphone to listen in on private conversations?

The definition of “connected device” is fairly clear in the law’s language but has some potential gaps. There are many examples of IoT devices that don’t connect to the internet (and would, therefore, be exempt from this law) that could be attacked if anyone is in physical proximity to them. These devices don’t need to connect to the internet, but they do have wired or wireless interfaces that could allow someone to tamper with them. The law also specifically calls out Bluetooth, which is problematic, given that there are many other wired and wireless IoT protocols aside from Bluetooth that sound like they may be excluded by this statement (I’m not a lawyer!).

For example, most IoT home automation devices (lighting, shades, switches) use the ZigBee, Z-Wave or 6LoWPAN protocols (there’s a list of them here). The language used in this law would seem to specifically exclude these protocols since these devices are neither assigned IP addresses nor use Bluetooth. Other potentially excluded devices include RFID and NFC tags, which are becoming increasingly more common for accessing cars, hotel rooms, and ‘smart’ locks.

I’d define a connected device as any device that can be reconfigured or manipulated over a wired or wireless connection. I suspect even this broad definition could have gaps or cause issues, however – it’s necessary to walk through dozens or hundreds of examples to get these definitions right.

Building on SB 327 (and I do think we should build on it), I think it’s important to avoid security requirements that are too prescriptive, as this approach tends to reward compliance with the letter of the law over practical security enhancements that make us safer.

Instead, I think it would be more effective to require security assessments based on a product’s ‘risk profile.’ For example, a car would have a high-risk profile. A car with self-driving capability and poor security could become a weapon in the wrong hands. Bluetooth headphones have a much lower risk profile. A manufacturer would have to pay a third party to perform a security assessment of their product initially and after major changes/revisions. This third-party assessor would determine what “appropriate security” means and how it should be applied to the product. This is similar to work done by the FDA to ensure medical devices are safe and by UL to certify electronics and many other types of products as safe.

About the author:

Adrian Sanabria has an extensive background building security programs, defending large financial organizations and performing penetration tests and has spoken at numerous industry events such as the RSA Conference. As a consultant, he has designed compliant and secure solutions for large retail organizations and performed security assessments for domestic and international clients. Previous experience includes a role as the security architect and chief incident handler for Elavon, one of the largest payment processors in the US.

DISCLAIMER: The views expressed in this contributed post are that of the author, and don’t necessarily reflect the views of EdgeIR.com. Contact us if you want to contribute a guest post.

Article Topics

device edge  |  edge computing  |  IoT  |  law  |  legal  |  security  |  Thinkst Applied Research