US Senators To Introduce Bill To Secure 'Internet of Things' (reuters.com)

Dustin Volz, reporting for Reuters: A bipartisan group of U.S. senators on Tuesday plans to introduce legislation seeking to address vulnerabilities in computing devices embedded in everyday objects -- known in the tech industry as the "internet of things" -- which experts have long warned poses a threat to global cyber security. The new bill would require vendors that provide internet-connected equipment to the U.S. government to ensure their products are patchable and conform to industry security standards. It would also prohibit vendors from supplying devices that have unchangeable passwords or possess known security vulnerabilities. Republicans Cory Gardner and Steve Daines and Democrats Mark Warner and Ron Wyden are sponsoring the legislation, which was drafted with input from technology experts at the Atlantic Council and Harvard University. A Senate aide who helped write the bill said that companion legislation in the House was expected soon.

Comments

Devil is in the details

[Lord_Byron]

It's good they're trying to do something, but the devil is in the details. For example, define "vulnerability". Anyone who's tried to remediate Nessus findings knows what I mean - those Low findings that just. won't. go. away. And do they mean internal or external vulns? etc, etc. And these things won't be determined in the law, they'll be decided by the bureaucrats implementing it. Pray that they're smart.

A non-legislative approach

[MobyDisk]

He added that the legislation was intended to remedy an "obvious market failure" that has left device manufacturers with little incentive to build with security in mind.

This guy gets it. But I was hoping for a market solution. The government could start by requiring vendors of US government products to meet certain guidelines. States could require that police and government tech meets a standard. That typically makes civilian companies jump on board and require similar guidelines. Then individuals start to say "Oh, I only buy IP cameras that meet FIPS-12345 standards."

This approach is nice because it is flexible, and allows the market to decide what standards to apply. I fear Senators trying to write tech legislation.

An Idea

[DickBreath]

I have suggested this plan before.

Make the manufacturer (not seller) of an IoT device liable for any actual damages that are caused by their IoT device getting hacked.

That's it. No government standards. No registration. No certification. No mandated testing facilities. (But the market could create certifications and testing facilities on its own.)

What this would do is change the perverse incentives that currently exist to the correct incentives. Suddenly manufacturers would be all about security! It would be Job #1. Manufacturers might standardize and cooperate on secure Linux distributions upon which they base their products. They might cooperate to improve everyone's security.

Suddenly manufacturers might consider whether they should have an update mechanism (or not).

Manufacturers might consider whether certain things should even be connected to the cloud at all!. Do we really need a cloud connected toy teddy bear?

Oh, yes. The retail price of some IoT devices might increase due to the manufacturer's cost of security measures. But that is as it should be. Right now the perverse incentive puts the costs on innocent parties that get DDOS'ed (or worse) by hacked IoT devices. This would fix that.

Re:Instead of Perimeter Security

[bluefoxlucid]

I've actually thought a lot about IoT security, as well as independence from service providers.

I had at some point started this but uh. Was ... diverted.

The idea was to have an IoT hub that acts as the gateway to your IoT device. An IoT device or client would connect to an IoT hub via some system (e.g. Bluetooth) that's not flat-out open (e.g. you have to push a button and confirm pairing). The IoT hub uses a self-signed TLS certificate and exchanges it with a newly-generated certificate on the device or client. Viola: identity.

It works with self-signed certificates because you have to be physically present to exchange them: you've verified face-to-face with the issuer, so the certificate is valid. Because of this trust, the IoT hub can sign extra certificates, acting as a CA.

The IoT hub can get itself an IPv6 Internet address. If so, it can exchange that address to your client (e.g. phone, Yubikey) or IoT device (which might now be in another building, communicating over the Internet to your hub!). Now your devices know how to talk to the hub, and can tell it their address if they so desire when they're somewhere off in another network or on the local LAN.

When your phone, computer, or anything else tries to talk to the IoT Hub, the HTTPS connection initiates over TLS using the exchanged keys: each device authenticates the other by validating certificates first. Your entire attack surface is the Kernel's network stack and facilities it uses; the code paths in the Web server that handle the request; and the code paths in your encryption library that validate e.g. Curve 25519 ECC (TLS 1.3 required). If you have an exploitable vulnerability and it's not in that set of code, then your IoT Hub and your IoT devices are patently unhackable, period.

Let's face it: You can't hack what you can't access. The surface I describe above is equivalent to the air gap when you unplug a network cable, except this air gap might be hackable. If you can't hack that air gap, you can't hack what's behind it.

That leaves you one big, important piece of security: key management. You have to keep those private keys on the client devices away from malicious actors (hackers, worms, trojans). Pass-through to a Yubikey U2F would be great, but ...tricky. The only way to use a hardware security key is to validate the certificate, then do a U2F validation, enlarging the attack surface. In theory, the client software could send a challenge to the Yubikey, get a response, and send a signed session key down the pipe encrypted with the IoT Hub's public key; but you can't use the Yubikey to decrypt something sent encrypted by the certificate, so it's a no-go.

This is actually app-to-app 2-factor if you're doing it by TLS exchange, then U2F: the app "knows" (permanently stores) its TLS key, and it "has" (is running on a machine physically capable of accessing) the Yubikey.

So, yeah. Unhackable IoT proxy, for some reasonable definition of "unhackable" (that being the reduction of probability of hackability by restricting the portion of running code in which vulnerabilities will enable a successful exploit).

The other part was to provide service, either in proxy or right on the IoT hub, packaged as Docker containers. You'd have to provide authentication per-app, validated by IoT device identity (i.e. your Nest Cams each have a separate key, and those keys identify them, and those devices are given access only to the Nest Cam service) or by Client identity (each client application would have a separate key) both at the front-end Web server and by the service itself. Services may be clients of each other.

So what have we got?

You can access your IoT devices through your own public IP, rather than bouncing through a cloud service.

You may be able to disconnect your IoT from the cloud. Google has a lot of stuff with the Ne