New FTC report: a sneak preview of the coming regulated IoT

The US Federal Trade Commission (FTC), in a January, 2015 staff report titled 'Internet of Things: Privacy and Security in a Connected World', gives us a first glimpse of how Federal consumer protection policy for the IoT is likely to shape up.

The report warns of new risks, and familiar but amplified risks, stemming from the massively expanded attack surface that the IoT's billions of sensors and other networked devices - along with the copious amounts of data that they'll produce - will bring. Major areas of concern include:

  • Threats to personal safety and property - hackers disabling household locks, changing the settings on medical devices, commandeering cars, crashing drones into crowds of people, etc.
  • Harvesting and misusing personal information - everything we've been hearing about Internet privacy violations for the past few years, now coming to you on steroids. New and widely varied data sources - from sensors, for example - along with advances in data science, will allow marketers, cybercriminals, and other actors both friendly and otherwise, unprecedented insights into the attitudes and behavior of individuals. We're looking at a real double-edged sword here.
  • Compromised IoT devices, leveraged to launch attacks against consumer networks. Compromised consumer networks, leveraged to launch attacks against other networks. We've already seen cases of kitchen appliances being pressed into the service of botnets. That's just the beginning.

The FTC notes that these risks might be exacerbated by vendors who don't understand the security ramifications of their IoT-enabled products, maybe due to inexperience (washing machine vendors never had to worry about cyber attacks before). Or, who are focused on marketing inexpensive products to the point that they believe basic security controls - the ability to patch a sensor's firmware when a vulnerability is found, for example - can't be economically built into the product.

Not surprisingly, the FTC recommends that security be taken into account when designing, building, and operating any IoT-enabled system, and recommends the following:

  • Reasonably limit collection and retention of consumer credit information ("data minimization").
  • Build security into products from day one by conducting initial risk assessments, designing the products according to data minimization principles, and testing security controls - before taking them to market.
  • Give security training to employees, and make sure security issues are addressed at the appropriate level of responsibility in the organization.
  • Retain service providers that are capable of maintaining reasonable security and oversight.
  • Implement a defense-in-depth strategy for systems where material risks are found.
  • Limit access to information systems (relating both to the product and the manufacturing organization) to authorized individuals.
  • Monitor products for vulnerabilities throughout their life cycle, and patch known vulnerabilities if possible.
  • Give heightened attention to security if the product poses physical security or safety risks, collects personal information, or connects to other devices/networks in a way unauthorized access is possible.

On the privacy front, the FTC'S basic expectation is that vendors and operators will communicate their customer's privacy options to them both clearly and prominently - not buried in fine print somewhere. Some possible approaches on how to do this are suggested, including:

  • Setup wizards that provide privacy information.
  • Video tutorials to guide consumers through privacy settings.
  • Privacy information sent to customers via text or email while, or immediately after, the product is being configured.
  • QR codes attached to the product which, when scanned, would take the customer to a website with privacy information.
  • "User experience hubs” that store data locally and learn the customer's privacy preferences based on prior behavior.

Finally, the report calls for "strong, flexible, and technology-neutral" Federal legislation that would strengthen the FTC's ability to enforce cyber security policy in its domain, including mandatory notification by vendors and operators to affected consumers in the event of a data breach.

My take on the report? It's a landmark document and a positive first step. It acknowledges (at a high level) the IoT's key risks, and the need to protect consumers against them. The FTC does fall short here of taking a firm stance on privacy, beyond the very broad notion of data minimization. So the $64,000 question of how those petabytes of IoT-generated data will be throttled remains wide open. As the IoT develops and matures, I have a feeling that the FTC is going to be busy - really busy - dealing with this.

If you're a vendor or operator in the IoT space, I'd definitely recommend downloading the report here and incorporating it into your product thinking. But don't stop there. Good security - the kind that will protect your company's reputation and revenues when push comes to shove - never comes from just following compliance requirements to the letter. Especially when they're as high-level as this document. Go the distance, do your own risk assessments, hire qualified security help, and build an appropriate level of security into the DNA of your IoT-based products. That way, you'll be building a positive feedback loop of trust for both your company and the whole consumer IoT industry, at the same time.

A version of this post appeared originally on Peerlyst.

Does the US need a mandatory smartphone kill switch?

Bit of controversy going on in the States, where some groups are proposing a mandatory "kill switch" on every smartphone, while others are proposing ... not that. Who's right?

On the surface,  it seems like a no-brainer. Smartphone theft is rife in the US, where 113 of the little goodies purportedly go missing every minute (presumably from different people) - resulting in $2.6 billion in annual losses. Plus, the thefts can often turn violent, leading to even more undesirable consequences. The simple solution: someone swipes your iPhone, and all you do is make a quick call to the phone company. They remotely send a command down to the device that will "brick" it (that is, render it permanently useless, except for things like building walls and even then, perhaps not the material of choice). None of your passwords are compromised, no online accounts broken into, and all you've lost is the device, which for sure is a headache, but at least you've avoided identity theft. And this would be a great deterrent to would-be thieves as well, since they're usually looking to sell the stolen devices, which tend to fetch a higher price when they're actually working.

Not so fast, though.  According to the CTIA (the US wireless trade association), this plan has a few fatal flaws:

  • The "kill" command would have to be made known to every mobile network operator, so it couldn't be kept secret. It would quickly become common knowledge on the street, and then think of the potential for abuse ... "revenge brickings", attacks on random devices "just for the lulz", and so
  • The risk isn't limited to a single device at a time. Large-scale, automated denial of service attacks could be launched against groups of devices (within a big company or government agency, for example) by incrementing the MSISDN (phone number), the IMSI (unique identity of the customer) or the IMEI (unique identity of the device).
  • Customers victimized in this manner would suddenly be unable to make emergency calls, possibly putting their safety in jeapordy.
  • This approach eliminates any chances of reactivating the phone if it's reported lost or stolen, and then later found. This is a very common scenario. I've had it happen myself more than once. The customer would still have to go to the expense of buying a new device.

What the CTIA doesn't mention is the cost of implementing a kill switch on every single device, which, I suspect, is their real reason for opposing the idea. Note that they don't offer any kind of alternative approach in their position piece on the topic (PDF). That's because, I suspect, they would rather not make any changes at all. The security problems that they cite are solvable (see below), but not for free. The cost to mobile operators and device manufacturers of doing this would be non-trivial. They'd have to agree on a standard protocol, possibly do some hardware modifications, and put the feature into every new device, the real estate inside of which is already extremely scarce and subject to fierce contention. Security would improve, but the cost of that improved security would be borne by the mobile industry, instead of consumers and government who are absorbing it now.

The problem with that way of thinking is, in the US if there's a problem affecting a very large number of consumers, which this one is, and it's not going to go away, which it isn't, and you as a provider of products and services don't solve it proactively, the regulators have a tendency to step in and solve it for you, and usually not in the ideal way that you'd envisioned.

Now they could spend the money on lobbyists to try and defeat any impending regulatory threat, or they could just bite the bullet and invest it in security upgrades, which will have the net effect of increasing trust in the smartphone market. Which is something the US mobile industry in particular could use a giant heaping platter of, especially if it sees providing things like payment services in the future. As a bonus, with better security in place, the carriers may find insurers more than willing to work with them to defray costs. Just speculating here, though.

Anyway, I'm going to side with the CTIA here on the basis of their stated security concerns, because they're legitimate, but only for now, because I think they need to take some action, as opposed to doing nothing.

Here's how I would do the security part:

(1) Still implement the kill switch, but restrict its use to certain, well-defined high risk situations , and put a lot of security around its use by the mobile operator (extra strong user authentication, execution only under dual control, and perhaps even a mandatory court order).  And sent securely over the Internet, not the GSM network, with strong device authentication, transaction validation, and message encryption. Reason for this is, there are some scenarios where the ability to permanently brick a device remotely would have very high security value ... for example, if the device was known to be  in use by someone who was planning a major crime or terrorist attack.

(2) For garden variety thefts and losses, implement a reversible kill feature in software, again activated securely over the Internet. This could selectively disable certain features on the device that would be valuable to a criminal, but keep things like the ability to make emergency calls. It would also enable  reactivation to full functionality later on by customers whose devices just fell between the sofa cushions and then they panicked. Reactivation would be also have to done with strong security controls, of course I would make them go physically to a mobile operator shop , or to another trusted facility, like a post office, to do this), and use some form of multifactor authentication.

This way you get the best of both worlds. Go ahead and pass the cost on to consumers ... but we know that will happen anyway. I believe a good many, if not most, of them won't have a problem with paying a bit extra for the warm and fuzzy feeling it will give them about the safety of their "Precious".

I'd be really interested to know how other countries are tackling this problem. I'm sure it exists in every other country where there are smartphones, which is what, every country ... and I'm sure some are approaching it more rationally than others.