Menu

Why you shouldn’t listen to Pat Burns on LinkedIn

An article entitled “Why The Internet of Things and the Cloud Should Break Up” showed up on Reddit and Twitter earlier this week. It sounded promising – I’m a proponent of decoupling IoT systems so that they don’t rely on the cloud, even if they still use the cloud most of the time. What I was greeted with was a terrible opinion piece, full of misinformation.

I don’t know where to start, it’s so bad.

A FitBit wristband connects via Bluetooth with your smartphone but sends your activity data to a FitBit cloud app. Does your personal health data really need to sit in the cloud or can you extract sufficient value from it by simply keeping the data stored locally on your smartphone?

This isn’t the IoT. That’s a Bluetooth device connecting to a phone. He seems to be one of these people who will call anything connected and not a full blown machine “IoT”.

For most of the IT industry — let’s just get this on the table — the cloud today is the hammer and there’s almost nothing that isn’t a nail. And the cloud is an easy place to build an IoT application and operates without the messy hassles of embedded software, endpoint security, FCC regulations, or fertility risks, to name a few.

Firstly, using the cloud generally means adding functionality to endpoints. Take a standard IP camera, accepting connections on port 80, using port-forwarding for remote access. Add cloud functionality to allow remote streaming and the system takes more time to develop. It is not a freebie.

Secondly, using the cloud normally makes endpoint security much less of an issue. Traditional architectures, such as port-forwarding to devices, or customers running their own infrastructure, involve inbound connections to your network and endpoints. Many cloud connected devices have absolutely no ports open at all – SmartThings v2 hub for example. Because of this, endpoint security becomes a lot less difficult.

Thirdly, regardless of your architecture, if you want to use wireless connectivity, you need to deal with RF. I don’t see how the cloud avoids this.

It’s cheap and everywhere. Like beer in your dorm, the cloud today is so popular and so well-capitalized that infecting the IoT was only a matter of when, not if. Spin-offs like cloud analytics or cloud perimeter security (no laughing!) are simply too affordable and too visible to pass up. Traditional enterprise IoT pilots that used to cost $250,000 in enterprise software and systems integration services can be executed at a fraction of this price now due to the cloud.

Developing cloud systems and operating robust, secure cloud systems is a cost and complexity. People are not doing it to avoid cost.

Tools. Compared to older desktop-based tools, cloud-based environments and API’s are vastly simpler to use and integrate while offering robust functionality.

He seems to be conflating using a cloud-based development environment with operating in the cloud. Nearly all cloud based solutions need significant development in traditional languages, on a desktop. It’s not point and click.

Weak endpoints and edges. Endpoints that don’t do analytics, support real-time queries, or even support full two-way messaging tend to spew data remorselessly to an edge router and/or the cloud. Bluetooth, ZigBee, 6lowPAN, and others are all guilty as charged and as a result, they end up driving their users to the cloud.

He seems to have a bee in his bonnet about how “stealthy” wireless protocols are. There really is no link between the wireless protocol used and how much data ends up getting sent to the cloud. They are different layers – one a transport protocol, the other application. Zigbee does send a fair amount of beacon traffic, but none of this ends up outside the PAN. If your app sends a lot of traffic over Zigbee and then your gateway sends it to the cloud, that is not the fault of Zigbee.

It’s not secure. This one is hard to overstate as crummy IoT security is the sordid “yeah, but” in so many discussions about the IoT. IDC predictsthat nearly every IT network will have an IoT security breach by the end of 2016 and IT departments are in full freakout mode now. Endpoint security is comically bad and compounded with a hacker-friendly cloud, what could go wrong?

There is absolutely nothing inherent in the cloud architecture that makes it insecure. In fact, there can be a lot of advantages:

Waiting 2–3minutes for a cloud app to make time for you is a non-starter.

This is just pure misinformation. Going over the Internet adds latency. It doesn’t add “2-3 minutes”, it adds milliseconds typically. 2-3 minutes means the system has been designed badly, and this would be an issue regardless of where it operates.

It may not be faithful. The integrity of your data in the cloud is only as good as the people and systems hosting it. Sensors in your manufacturing facility in Taipei showing you running at 50% below your normal run rate or showing a supply chain hiccup? Hedge funds and competitors enjoy learning about this kind thing!

The integrity of your data on your self-hosted platform is only as good as the people and systems hosting it. Again, nothing inherent about cloud. I would rather have a skilled operations team managing intrusion detection, performance monitoring and disaster recovery than burden a sysadmin with yet another system in-house.

Getting out may be easier than getting in. Once you’ve married a cloud service, how easy will it be to disengage/migrate to another solution at some future date? Is standardization and interoperability in a state that will increase the risk of vendor lock-in? What if the cloud vendor is bought by your competitor and changes policies?

Which is equally true of any bought-in platform. Just remove the word “cloud” from the above paragraph. Vendor lock-in is real however.

A new golden rule of IoT network design is to store sensor data as close as possible to its point of origin and limit its sharing across the network unless absolutely necessary.

You can’t just invent golden rules. Many people want low-cost, low-power endpoints with no storage and no persistence, pushing everything to more powerful gateways or servers. The AWS and Azure IoT platforms both accommodate for this. This is Pat Burn’s golden rule, to sell his product.

The endpoint is key to the golden rule. Better processors, cheaper memory, and better networking stacks from companies like Haystack are evolving endpoints from dumb terminals to independent, distributed computing devices with real-time query (think Google for the IoT) and NoSQL-like filesystem support. Endpoint-centric designs also have the bonus of being more stealthy and secure, faster, cheaper, and better stewards of battery life and wireless bandwidth. In short, good IoT network design should begin with the endpoint in mind and “dumb” endpoint technologies that beacon or create unnecessary security risks should be phased out

I just don’t know where to begin on this.

The enemy of security is complexity. Are you actually trying to argue that having hundreds of endpoints in a distributed network, able to store data and be queried, are going to be more secure than, say, a memory-based RFID tag? Or a transmit-only 8-bit PIC based humidity sensor?

Firstly, that is very, very specific. “Poor architecture of the wireless protocol”. Not “Weak implementation of the wireless protocol” or “devices using wireless protocols”.

Secondly, neither of the links provided are breaches. A breach is the result of a system being exploited. One is information leakage, the other is a report of a vulnerability.

Thirdly, the Jeep hack was nothing to do with the wireless protocol. Jeeps could be using wired Ethernet and the same issues would have been present.

Fourthly, nearly every IoT breach in recent news has been carried out over the Internet. Not local attacks to the wireless protocol. There is a lot of research into wireless security, and there are a lot of noise at conferences, but the bulk of issues occur over the Internet remotely. Hackers are not sat outside homes and business cracking your Zigbee or wireless burglar alarm.

Avoiding or minimizing the chances of unauthorized discovery is not technically difficult. But today’s IoT technologies like Bluetooth, 6lowpan, Sigfox, LoRaWAN, and others make unauthorized discovery very easy and it creates the worst kind of angst in IT departments.

Most of the protocols make discovery easy because it is intentional. They layer security with discoverability, enabling systems which people can actually use and are actually deployed (unlike Dash7).

The link doesn’t support that unauthorised discovery is causing angst in IT departments. He seems to often do this – provide a link which is vaguely related but doesn’t support the argument. It would be fair to say “IoT is causing angst in IT departments”.

Most wireless IoT technologies were originally conceived as ways to stream large files (Bluetooth, WiFi) while some were designed to be “lighter” versions of WiFi (e.g., ZigBee). Today they are being re-positioned as “IoT” technologies and security, to put it nicely, is an afterthought. Oh yes — some have tried to “layer on” security and may profess to support encryption

Layering encryption onto a transport protocol is completely valid. It’s widely acknowledge that ZigBee, Z-Wave and WiFi, if implemented correctly, are secure from the risk profile that is involved. Skilled hackers are not sat outside your house, waiting for you to pair you Hue bulbs to the hub and grab the keys. It is not happening. Even if they did, all they can do is turn your lights on and off.

I have no idea why they “profess” to support encryption. They all offer encryption. WPA2 is actually a very secure protocol.

hacks for all of these technologies are quite public yet fundamentally traceable to one original sin:

these wireless IoT technologies don’t know how to keep quiet.

What? What hacks of wireless protocols can be traced to not keeping quiet?

No, drones are being used to map Zigbee broadcast traffic. This is not enabling anyone to hack Zigbee anymore than putting your house number on the door of your house enables someone to pick your locks.

this type of hack provides all sorts of information about each endpoint, including manufacturer ID.

This is not a hack.

This need to be “discoverable” — and this is not limited to ZigBee, Bluetooth or WiFi but to most wireless IoT technologies — requires a near-constant advertising of a device’s presence, leading to any number of “disaster scenarios” that others have extensively written about.

The link, again, doesn’t support that a wireless protocol being discoverable will lead to any disaster scenario. Just pile the links on and hope no one checks.

There is no technical reason that the Internet of Things cannot embrace silence, or stealth as I prefer to call it, as a first principle of endpoint security. Stealth is not a silver bullet for IoT security (there is no silver bullet) and stealth alone won’t protect a network from intrusions, but dollar-for-dollar, stealth is the simplest, cheapest, and most effective form of IoT security protection available.

There is, quite literally, nothing to support this position.

A endpoint, receiving and sending plaintext, unauthenticated commands and data, will not see a noticeable improvement in security. Passive monitoring of the channel will still leak data, and active tampering will cause havoc. The stealth must be broken for the device to send, and this can be seen.

An endpoint, receiving and sending encrypted, authenticated commands and data, will not see a noticeable improvement in security. The data is still encrypted. Unauthenticated commands won’t be carried out.

This is just garbage.

Dollar for dollar, it might be worth making your nodes quieter, but not at the cost of switching from a widely adopted, widely inspected wireless standard to Dash7.

He tries to explain why:

Cloaking. It is harder to discover, hack, spoof, and/or “stalk” an endpoint if a hacker cannot locate the endpoint.

Endpoints need to send. Being stealthy can reduce the traffic but there will still be traffic. Stealth is only a weak layer of security through obscurity.

This has absolutely nothing to do with how stealthy communications are from the node. If you enable your node to be queried, it can be queried. In fact, querying and accessing data from the edge of a network almost negates attempts at being stealthy as you will see an increase in complex and important traffic of the wireless network.

Minimize interference. Less data being transmitted minimizes the opportunities for interference and failed message transmissions. Contrast this with the tragedy of the commons at 2.45 GHz, where WiFi, ZigBee, microwave ovens, and other countless other technologies engage in wireless gladiatorial combat and cause too many customers to return their IoT gadgets because they “don’t work”.

Again, this has very little to do with stealth. 434MHz – that Dash7 uses – has as many issues with contention as 2.4Ghz. In the UK, there are many more poor quality, untested, non-standards compliant transmitters in the 434MHz band than there are on 2.4Ghz.

Access control. Stealthy endpoints make it easier to control access to the endpoint by limiting who can query the endpoint.

Again, absolutely no link between stealth and access control. If you limit access to something, you limit access to it.

Storage. Less data being transmitted reduces storage costs. Storage vendors, on the other hand, love the non-stealthy IoT status quo.

Again, what? If your endpoint decides to ditch data, then your cloud can also decide to ditch data. This has nothing to do with stealth of the wireless protocol – it’s about volume of data at the application layer.

I'm a security researcher and reverse engineer. By visiting this site, you must realise that any or all files on this site may be jam packed full of the finest exploits, tricks and other gubbins. You might also get geo-located and port-scanned for fun and profit.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
If I really want to track you, by tricking you into visiting this site, then it's going to be a lot more subtle than a browser cookie.