IoT Security Anti-Patterns

Can you really protect the device software if the hardware encryption element is separate from the microcontroller? Wouldn't it be trivial to sniff the decrypted cypher text of the software with a logic analyzer on the pin between the microcontroller and encryption ASIC even if you can't get the actual key out of it?

My guess is that no, it's not about pub/sub specifically, but rather that "you" can address & subscribe arbitrary hosts anywhere on the internet via a naive implementation.

Segregating your 'dumb' controller/sensor nodes and restricting their ability to talk elsewhere via routing, firewalling or proxies would reduce the risk of a single crappy device leaking onto the internet. At the cost of some centralisation of control in your gateway/router/whatever, of course. And you still need some form of crypto on your local network to protect against local/physical attackers.

Is it a coincidence that this post comes a few days after CF announces a "private network for IoT"[1]? My wirelessly-enabled Crystal Ball says no. I wonder if it's because the IoT is itself a big enough pie with current attention on (lack of) security, or if it's more to protect their main business from Mirai N+1/DDoSoT or whatever.

[1] https://blog.cloudflare.com/orbit/

No, I think it's a weird variant of pub/sub where the client can subscribe in a way that causes the server to poll the client. Or, in the described case, any other random client.

Just as anyone can sign anyone's email up to mailing lists.

I would say it's like sound engineering for architecture:

If you're willing to incorporate it in the design from the outset, use specific components, and organize the project with that as a focus, you can make quality things.

Most things end up as an echo-y, impossible to hear cacophony as soon as there's many actors involved, because they just don't care and don't plan for it -- it would be a "waste of money", because it still performs economically without that.

You even have parallels like adding things to existing projects to try and fix them, and that not being nearly as effective than had you designed it better in the first place.

As a system developer, you have the defender's dilemma: You have to defend against all possible attack vectors, and the attacker just needs to exploit one. There are many, many rules to follow w.r.t security of your system -- too many for this small textbox :).

Systems are heterogeneous, and so are the exploits. A great example of this would be getting into a smart TV through broadcast signals (Weeping Angel).

A good place to start would be at the system level with a DREAD, DREAD-D, STRIDE or other model analysis. This is often a creative process, and experience counts.

It isn't at all a black box art. It is true that some exploits can get pretty esoteric, but the vast majority are very simple. Don't use a default password. Don't type your passsword anywhere you shouldn't. Implement a sane access control policy. Use security software in the way it was intended to be used. That is enough to prevent 99% of attacks.

Since there is no security panacea -- all systems are vulnerable given enough attention and focused skill -- it seems more of an art than a science. Like all software engineering, proper security requires careful balancing of tradeoffs and prioritization of security mitigations.

Just like you design software with the end user in mind, you should design security systems with the attacker in mind. Just like you prioritize features for by your expected user personas, you should prioritize security measures by your expected attacker personas. And just like you always want to cover the "basics" of UX, you always want to cover the "basics" of security.

First you should take care of the "low hanging fruit," meaning you should implement industry best practices at all levels of the stack. Hopefully this is sufficient to mostly mitigate any threats of getting caught in widely targeted attacks, like mass scans for Wordpress vulnerabilities.

Unfortunately, implementing security best practices is only the beginning of defending against motivated attackers focused specifically on you as a target.

Once you've taken care of the easy wins, you have to balance the tradeoffs of engineering effort and complexity required to make certain mitigations. In practice, this means that what your security system will look like largely depends on the question: What is your threat model?

If you are an IoT vendor, your threat model is becoming a node in a botnet. That means you need to defend against a focused attacker reverse engineering your product to find a vulnerability that can be used to root the device remotely. Unfortunately this is basically impossible to defend against, but you can make their job much more difficult with binary obfuscation, symbol stripping, aslr, etc. Your best hope at that point is the attacker gets frustrated and decides to target some other product.

If you're a search engine (cough cough) your threat model may be people scraping your search results (as hypocritical as that is...) In that case your first priority might be catching bots and serving up captchas.

Point is, your "security engineering" largely depends on your domain and threat model, just like "traditional" software engineering depends on domain and user base.

(That said, IANASecurityProfessional ;) )

The issue is that it's a process that needs to be kept in mind from design through development. There's a sound process, but it's not something you can apply afterwards, and obviously it adds cost.

With IoT, one generally has control of the devices, so one can distribute their own keys without having to "trust" the authorities. In that case, something like libsodium could handle the communication between devices.

I don't think the average consumer has much of a need. Industry and government does. IoT sensors on infrastructure such as lamp posts could make bulb replacement easier to track. Same with various machines. You can track health and productivity for better maintenance.

Some might like the convince of an IoT device like the Echo. That's a personal choice. Properly developing both sides of the device spectrum should improve quality and security.

People are stupid and cheap, and inappropriately use the Internet as a WAN.

Says the guy who posted this comment through a device connected to the Internet.

I don't think rejecting a technology entirely is the best way to avoid abuse. I get that some of these devices are a little silly, i.e. WiFi-connected toasters, but a lot of IoT devices have great potential for making the world a better place. For example, the FitBit and other health trackers can do wonders for helping people get healthier, and devices like Bluetooth-enabled glucose monitors can even save lives.

This idea that we shouldn't even consider connecting tools to the internet because the internet is scary and dangerous feels like a knee-jerk reaction to me. I believe there is a right way to build these tools where the risk added is minimal to non-existent. Refusing to pursue this tech at all because some people do it wrong just feels like ludditism to me.

Imagine what would have happened if people abandoned computer technology after the first few viruses were discovered.