Safety and Security and the Internet of Things
Ross Anderson blogged about his new paper on security and safety concerns about the Internet of Things. (See also this short video.)
It’s very much along the lines of what I’ve been writing.
Comments
Confirmation bias
Rhys • June 8, 2017 1:23 PM
Agree with Ion.
What might’ve been better was to have sought contradictory points or papers here.
I see bigger questions not being asked that should be answered.
Safety is currently balkanized into the delivery mechanisms of the industrial supply sector- whether by government of private sector or, alleged, self-regulation. (e.g. vehicles- NTSB or IIHS, FDA or Chicago Board of Medical Examiners…etc.)
I think many of you may remember that Ford had decided that the Pinto model gas tank was sufficiently safe for their go to market ambitions. Ford argued with confirmatory (backfire) bias as long as they could. As was done with the “K” cars by others.
For manufacturers, safety is a matter of residual liability. For victims, safety is…?
Surprising that we still can’t come up with a test range, or proving ground, or demolition derby to move from test-for-success to test-for-failure.
Ross Snider • June 8, 2017 1:54 PM
There’s been a lot of chatter about upgrading the firmware on IoT devices, but my biggest worry is LoRa/Sigfox and other lightweight, unauthenticated protocols these devices are planning to use.
Tim • June 8, 2017 4:22 PM
Why is it necessary to use the internet as a delivery channel for patches to automobile firmware? It seems to me that the problem gets much more manageable if updates can only be delivered by direct connection (via wire) between known/validated endpoints. This also fits in with the business model of the dealer that needs a periodic visit to the dealer to extract cash from the customer. I know that this is not a the way that the world is moving, but providing a wifi/bluetooth interface for this purpose is hugely expanding the attack surface for a questionable use case. I miss the good old days when it was the job of security people to just say: “NO!”. In this case, “Hell NO!”.
VS • June 8, 2017 8:34 PM
The security of IOT requires either:
1) Subscription based fee model
2) Decoupling of OS from the app function
In free markets, you can’t expect consumer device makers to use the first sale fees to provide support for years. Evidence shows that this kind of wishful thinking does not work, to keep wishing that it would just change by itself is magical thinking.
1- Subscriptions may create the right incentive to provide updates.
2- Decoupling, like what Ubuntu is doing with Ubuntu core, separates OS from app and allows the OS to be updated by the OS maker long after the device-maker has moved on.
tyr • June 9, 2017 1:53 AM
What continually amazes me is the buying
into models that are flawed inceptions.
Once you decide that contiuous upgrades
are the way software should be built the
whole set of unintended consequences has
arisen around it. Back in the day we were
using bulletproof operating systems that
were not upgraded continuously. Then
Gates foisted his crap that would be fixed
with the next release on the gullible who
have created the next layer of the mess on
their understanding that things should be
broken and require constant upgrades to be
able to work.
You can see the same thing in Polanyi as
he deconstructed the falsehoods that are
the underpinnings of modern society.
Once you get enough fools to buy into a
false model it becomes the reality you
have to fight with and it can’t be fixed
by any amount of effort.
The KISS model and Occams Razor will get
you a lot further than the idea everything
has to have a WiFi interface to the world.
Tim van Beek • June 9, 2017 3:31 AM
@Tim: “Why is it necessary to use the internet as a delivery channel for patches to automobile firmware?”
It is not necessary, but there are several reasons why it will be used:
- Warranty. Manual patches by dealers/garages will cost the automaker some 100 Euros/Dollars for every vehicle that still has warranty.
- Ease and speed. A rollout of patch software to every dealer/garage takes time and is costly.
- Publicity. You don’t want to inform your customers that they need to drive to the next dealer/garage ASAP to get a fix for a critical error (which may not even be possible, see point 2) if you can fix that over night without much fuss.
@tyr: “Back in the day we were using bulletproof operating systems that were not upgraded continuously.”
Back in the day we used to write programs with all zeroes only, because we didn’t have the one yet! It wasn’t easy to get anything interesting done, but at least we had full understanding and control over what we were doing!!
Drone • June 9, 2017 6:19 AM
It is easy to stamp out the manufacture of vulnerable/insecure IoT devices. If a company’s IoT product causes harm: (1) Ban the sale/import of said company’s products, and (2) criminally prosecute said company’s Senior Management (not some lowly EE!)
Even if you really can’t criminally prosecute said company’s Senior Management because the company is based in a country with no real rule of law (ahem China), just the banning of the dangerous products would likely be enough incentive for a manufacturer to exercise reasonable care when securing their products, especially if they are facing potential banishment from large markets like the US and EU.
The LAST thing you want to do is put Big Government Bloat in CONTROL of testing, and qualifying IoT devices. That process is slow, expensive, ineffective, and stifles innovation.
Just look at the FCC trying to regulate EMI compliance, what a disaster. Don’t believe me? Just ask your local Ham Radio Operator how horrible the interference has become from “FCC Qualified” devices these days. What the FCC should be doing instead is vigorously criminally prosecuting select examples of EMI violators as recurring reminders to ALL manufacturers that they better not produce crap!
wiredog • June 9, 2017 6:42 AM
Harry@1
Y2K was a major problem. The reason it didn’t cause more disruption was that a lot of effort (and money) was expended fixing it. There were a few glitches, but nothing major.
Rachel • June 9, 2017 8:33 AM
Drone
a country with no real rule of law (ahem China)
Wow. You really sound like you know what you are talking about.
I am excited in anticipation of reading how you back up your extreme statement with your copious, real life experience living in China?
Anon • June 9, 2017 8:48 PM
@wiredog: The real story with Y2K was that it wasn’t the problem it was blown up as being. Even if nothing was done, the worst that would have happened was systems would use the wrong date!
ab praeceptis • June 9, 2017 9:30 PM
Anon
“Y2K was that it wasn’t the problem it was blown up as being. Even if nothing was done, the worst that would have happened was systems would use the wrong date!”
Wrong. A suddenly skipping backwards date would f*ck up a whole of routines, incl. OS innards, that are chronology based.
As a quick dtrace will show you quite some processes do clock_gettime syscalls, some of them thousands of times per second.
Robin • June 9, 2017 10:54 PM
It gets even worse. A lot of IoT devices have cheaply produced wireless modules, Wi-Fi, Bluetooth, Z-wave etc. These have their own firmware on them. (Like, say, the Nordic nRF8001) Even if the vendor of the actual device decides to keep their firmware up to date, chances are that the provider of the communication module won’t support it for more than a few years, if that.
JD Bertron • June 10, 2017 1:09 PM
As long as government interferes with what insurance companies can and should offer in their policies, the responsibility, and blame for inadequate protection of the security of the IoT.
Calling for more government intervention is not only stupid, it’s also irresponsible.
Sanyam Chawla • June 10, 2017 2:39 PM
My concern is :
I want to pentest on IOT Devices.
I want to find vulnerabilities in our communication device and application.
But i dont know how to intercept communication means how to track communication
Communication channel
From To Communication Type
IOT Sensors -> IOT HUB : Zigbee Protcol
HUB -> Server XML
Server -> Application JSON
Can anyone help me what tool should use to intercept communication and find vulnerabilities?
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Harry • June 8, 2017 7:38 AM
Y2k oh no!