Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IOT Developer Security Checklist

simplesecurity.sensedeep.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: IOT Developer Security Checklist

#31

Post by petra »

ohazi wrote: post #17

There's a fundamental problem here, and I don't know how it should be addressed. I agree that manufacturers should be able to silently patch firmware for security holes. But I decidedly do not want them silently adding, removing, or changing functionality. I find this practice absolutely infuriating, and it's a big reason why I abhor the current IoT ecosystem. Sometimes I get busy and don't have time to read a change…

You could get your operating system from one vendor, while the application code be inside of an isolated container from the product vendor, with you easily controlling changes to each one. Same could go for the cloud.

I think Android things is built around this idea, with manufacturers having no control on security updates.

For simple, standalone features, this could work well. But when your features are dependent on interacting in some way with other people's connected products, this might not work.

Re: IOT Developer Security Checklist

#32

Post by trobayhasteman »

aeronautic wrote: post #16
trobayhasteman wrote: post #12

Sure the list has valid points, but those don't pertain anymore to IOT than any other internet connected application.

True point. The difference is that enterprise apps understand the need to patch and update. IOT devices and device builders largely do not. IOT devices today look pretty much like any other internet device too. Linux, good CPU horsepower, ample memory and internet connection. More than a few exploits that work on enterprise servers can be adapted for IOT devices. Add to this a lack of awareness of basic security issu…

> lack of awareness of basic security issues among device builders

I'd hate to think users were just as guilty, after all that would implicate me, but much of the IOT functionality should be firewalled or restricted to LAN, if access via handheld is the target rather than turning the stove on while on vacation. Regarding manufacturers from the POV of a consumer, they should just build devices without malfunctions. That's not a matter of security but quality.

Re: IOT Developer Security Checklist

#33

Post by veli_joza »

solatic wrote: post #30
ohazi wrote: post #17

There's a fundamental problem here, and I don't know how it should be addressed. I agree that manufacturers should be able to silently patch firmware for security holes. But I decidedly do not want them silently adding, removing, or changing functionality. I find this practice absolutely infuriating, and it's a big reason why I abhor the current IoT ecosystem. Sometimes I get busy and don't have time to read a change…

If you compare to the Linux ecosystem, you can see why IoT upgrades are broken. In the Linux ecosystem, software releases are typically independent from packaging, as well as from package managers and their update configurations, allowing users the freedom of being somewhere on the spectrum from completely unstable rolling release distributions to highly stable releases like Debian Stable. Software which auto-updates…

The packaging system is only a part of puzzle. I can control what happens with my Linux laptop, but it's much harder when 10+ devices around you are constantly updating. There's also the thrust issue - we all want exploit patches to be applied automatically while feature changes are different thing altogether (remember when Sony pushed update to PS3 that disabled OtherOS support).

Maybe a good legal solution would be to allow automatic updates, but only if user is informed about changes and she can downgrade/revert at any time. Also, the stuff that Microsoft does with Win 8/10 upgrading should be punishable.

Re: IOT Developer Security Checklist

#34

Post by veli_joza »

pavement wrote: post #6
MattBearman wrote: post #2

I feel like the first two items on this list should be: - does this really need to be online? - really ?

I like to use the XYZ metric. (aka: eXamine Your Zipper ) 1. Does the zipper on the fly of your pants need to be automated? 2. Does the zipper on the fly of your pants ever need costly repairs? 3. Does the zipper on the fly of your pants need regular maintenance? 4. Does the zipper on the fly of your pants expend disposable accessories? 5. Does the zipper on the fly of your pants need to be context aware? 6. Does the…

Your list is very cynical. "If zipper doesn't need it, why should your TV have it?" This way of thinking prevents the benefits we could have as appliances around us become connected, once the security issues are addressed.

Let's use the fridge as an example:

1,5) I don't need it to be automated, but I would love to get notification when food's about to go bad or when we are out of milk. Temperature is already automated, but we could squeeze out more efficiency if it was context aware and more intelligent (it could keep some compartments on higher temperature than others).

2,3) Appliances sometimes need maintenance anyway, but preventive maintenance would be less costly.

7) Phone apps are terrible way to control anything, to me they are just a stop-gap solution until something better comes (reliable voice control for start, then AR interfaces).

8) This would lower the cost and allow poorer households to own one; I don't mind advertising if full price gets rid of them. Kindle is great example.

9) YES! But for my benefit, and not for benefit of manufacturer and third parties. My fridge could recommend new interesting meals based on my cooking. It could also warn me about unhealthy habits and help with my diet. Over the years it could improve my quality of life without significant effort from my side.

10) No. DRM should not exist.

Re: IOT Developer Security Checklist

#35

Post by veli_joza »

seizethecheese wrote: post #8

Beginner question: what about if the device doesn't accept over the air updates? What sort of security concerns are there for such a device that wakes up periodically to send data over HTTP.

You still have to defend against MitM attacks, that could steal your data. A recent example is Samsung smart TV that could be controlled with voice. If someone can route TV connection to his server posing as Samsung's server, she can eavesdrop you in your living room.

Another problem is that during the lifespan of product, several critical exploits could be found that would compromise the security if not patched. There already efforts to defeat SSL and we may need to upgrade to more advanced protocol in near future.

One last problem is that in your case the device needs to have server address hardcoded. The company could go out of business and you would have no way to redirect it to alternate unofficial server. Therefore, firmware upgrades are pretty nice to have in IoT.

Re: IOT Developer Security Checklist

#36

Post by pavement »

veli_joza wrote: post #34
pavement wrote: post #6

Earlier quoted context omitted.

I like to use the XYZ metric. (aka: eXamine Your Zipper ) 1. Does the zipper on the fly of your pants need to be automated? 2. Does the zipper on the fly of your pants ever need costly repairs? 3. Does the zipper on the fly of your pants need regular maintenance? 4. Does the zipper on the fly of your pants expend disposable accessories? 5. Does the zipper on the fly of your pants need to be context aware? 6. Does the…

Your list is very cynical. "If zipper doesn't need it, why should your TV have it?" This way of thinking prevents the benefits we could have as appliances around us become connected, once the security issues are addressed. Let's use the fridge as an example: 1,5) I don't need it to be automated, but I would love to get notification when food's about to go bad or when we are out of milk. Temperature is already automat…

By my purely speculative opinion, only 4, 5, and 6 apply to televisions, and only 4 applies to refrigerators.
Post reply on HN