I've seen an increasing number of job postings for IoT pen-testers pop up within the last year, so it's on the rise. Still far outshadowed by traditional security job posting though.
Assuming your IOT device only connects to your server on the cloud, isn't it possible for amazon(or someone else),to just to sell you the communication module that gives you a secure link to the cloud , including updates etc - meaning you, as the embedded developer need only very little to none security expertise ? And you as the purchaser of an IOT product, know that security is handled by some serious player, and is probably handled quite well ?
Seem this could be valuable for the industrial IOT, at least.
AWS IoT got out away ahead of the competition on this, partnering with Atmel/Microchip on the ECC508A crypto-chip. [1] Microchip acts as the certificate authority, using ECDH to generate and store keys in hardware, at the fab facility when the chip is manufactured. They add in some pre-configured AWS server policies, giving OEMs the ability to connect devices to AWS IoT without setting up their own authentication infrastructure. Removes a lot of the possibility of an embedded developer screwing up cloud security.
Still, in many serious industrial "IoT" deployments, operational data is never sent to a cloud or 3rd party server, and stays in on-premise data centers, or is simply discarded after a quick sanity check. This is slowly changing (see GE Predix, Siemens MindSphere, Bosch IoT Suite), but there are still a lot of issues around architecting safety-critical systems that can support bi-directional communication with the internet and 3rd party data centers.
There are some trying to do this. Shawn Fanning's Helium is one of them.
I looked at Helium. Problem is that when you sell your own design and don't publish your designs and standards you become a single-source vendor.
As a manufacturer, I can't go with single-source vendors. I need backups and pricing competition and etc etc etc. So here we are, still writing code for WiFi radios and leveraging legacy OSS stacks to do the encryption and transport.
Mark from Helium here. Fair point on not publishing designs. You're not the first to bring this up and we have plans to make this a non-issue in the future. Shoot me a note - mark@helium.com - if you're up for talking further. Any other thoughts / critiques would be most-appreciated.
Helium are interesting, and there's a need for second sourcing, but also, i'm starting to think that the real problem is about creating percieved value for the end customer, like i explained in my other comment:
It's an interesting idea, and I've thought about it as well.
My first objection would be that I wouldn't put some black box module from a company like Amazon or Google on my design. Too many issues about what's inside and other things like Google's tendency to follow the shiny and discontinue products for no published reasons.
My idea was more along the lines of Amazon or Microsoft selling AWS and Azure-enabled hubs or concentrators that did all the backend lifting and presented a simple REST or MQTT interface on the local network for data ingestion. Then you could connect any 802.11 radio to it and send data over an encrypted channel without having to worry about the heavier layers about it (TLS, DNS, Certs, SAS tokens, endpoints, etc).
Yes, the router path makes sense. In a way, it's modular security - if the customer cares about security - he should pay a bit more for the right router, if not - it's his decision.
Btw, Amazon does some interesting stuff with AWS greengrass, including a router, it's quite similar to how you view it. And i'm sure they'll take of telling end users.
So security, or rather the usual lack thereof, will be a thing to keep an eye on.