Is security engineering at the level of black box art, or is it at the level of sound engineering principles that once followed will result in secure system? Everybody is talking about security, but are there some rules to follow or is it a jungle of black hat hackers trying to ruin your IoT devices?
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.
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.
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.
This is the real point! If I ever make my own IoT devices, they will actually be LoT (LAN of Things). I can SSH/VPN into my home network and control from there, no need to have ANY access to any network besides the LAN.
I'm extremely selective about what devices on my network actually get internet access, and IoT is like leaving your front door unlocked (and wide open) in the worst neighborhood you could possibly imagine. I'm kind of blown away people allow these things into their home.
If you want me to put your shitty IoT device in my home, open source it and then we'll talk.
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.
I think it's hard to dispute that networked sensors/controllers can have tangible benefits.
My issue with the current trend is that 'IoT'/Internet-enabled is a way to both sell a product, and then effectively rent access to it via the 'cloud' interface. If you stop paying, your device is (mostly) useless. If they stop supporting it, your device is (mostly) useless. The actual whereabouts of any data produced by your device is probably unknown, as is its security and usage.
It's the same tired old "If you're not paying..., you're the product", except that you're actually paying.
Many of these abuses are much harder to do if you don't expose your exciting new Thing of Internet directly to the entire global communications infrastructure, but then we're back in the bad old days where people had to use software that wasn't a thin client in a browser[1].
I'd really really like a LAN of Things, or a VPN of Things, that still functions after your service has gone bankrupt or sold their souls to Oracle or something. But of businesses, especially those riding the wave of 'your data is feedstock to our deep-learning quantum magic pixies, and we'd never ever sell it all for a cheap buck[2]' would find it much trickier if that sweet sweet data wasn't coming their way.
Development & distribution, as well as actually charging for for things, become harder problems though, which means everyone wants to head to the promised land of *aaS, where A/B unicorns frolic in the fields and green/blue munchkins guide your clueless users down the yellow brick upgrade pipeline.
[1] Only mostly sarcastic.
[2] unless someone offered
> 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.
Even taking these benefits as given, neither of these things need to be connected to the internet, especially not directly. A fitness application that stores your data locally and potentially offers to sync your data across devices, sure, but for these things you describe (and most IoT things, mind you), the benefits of connecting them to the internet are minimal at best.
I don't think anyone is suggesting that IoT devices store their data in some opaque format that can only be accessed on-device. However, for most of these things the model is to treat all IoT devices as dumb terminals for a cloud service, which unnecessarily has deleterious effects on your privacy and security and makes your device's utility dependent on the provider's infrastructure.
> With the device in their possession they can extract software from the embedded system chip on the device to obtain the software running on it. By reverse engineering this software they can learn secrets in the memory of the onboard microcontroller.
Hoping to keep secrets from a physical attacker on a general purpose microcontroller is an excellent example of an IoT security anti-pattern. It's a shame the author missed the wider point.
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.
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.
There is a cost to implementing SSL on many of these chips and it often results in either paying more or not having features. Even the esp8266 had issues with size. I wonder if using an proper HMAC without data encryption would be sufficient for non-sensitive items like dumb data loggers or even control.
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.
The library doesn't always fit, let alone larger keychains. This gets you encryption but means you have less room for the software that pays. This is the balance. Also, many of the IoT devices have a few hundred bytes of ram and a few kilo bytes of flash, so public key may be out of the question. It is changing, there are devices like the esp32 that can fit a lot more along with providing wifi/bluetooth
25 comments
[ 27.3 ms ] story [ 2661 ms ] threadIf 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.
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.
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 ;) )
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.
I'm extremely selective about what devices on my network actually get internet access, and IoT is like leaving your front door unlocked (and wide open) in the worst neighborhood you could possibly imagine. I'm kind of blown away people allow these things into their home.
If you want me to put your shitty IoT device in my home, open source it and then we'll talk.
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.
My issue with the current trend is that 'IoT'/Internet-enabled is a way to both sell a product, and then effectively rent access to it via the 'cloud' interface. If you stop paying, your device is (mostly) useless. If they stop supporting it, your device is (mostly) useless. The actual whereabouts of any data produced by your device is probably unknown, as is its security and usage.
It's the same tired old "If you're not paying..., you're the product", except that you're actually paying.
Many of these abuses are much harder to do if you don't expose your exciting new Thing of Internet directly to the entire global communications infrastructure, but then we're back in the bad old days where people had to use software that wasn't a thin client in a browser[1].
I'd really really like a LAN of Things, or a VPN of Things, that still functions after your service has gone bankrupt or sold their souls to Oracle or something. But of businesses, especially those riding the wave of 'your data is feedstock to our deep-learning quantum magic pixies, and we'd never ever sell it all for a cheap buck[2]' would find it much trickier if that sweet sweet data wasn't coming their way.
Development & distribution, as well as actually charging for for things, become harder problems though, which means everyone wants to head to the promised land of *aaS, where A/B unicorns frolic in the fields and green/blue munchkins guide your clueless users down the yellow brick upgrade pipeline.
[1] Only mostly sarcastic. [2] unless someone offered
Even taking these benefits as given, neither of these things need to be connected to the internet, especially not directly. A fitness application that stores your data locally and potentially offers to sync your data across devices, sure, but for these things you describe (and most IoT things, mind you), the benefits of connecting them to the internet are minimal at best.
I don't think anyone is suggesting that IoT devices store their data in some opaque format that can only be accessed on-device. However, for most of these things the model is to treat all IoT devices as dumb terminals for a cloud service, which unnecessarily has deleterious effects on your privacy and security and makes your device's utility dependent on the provider's infrastructure.
Hoping to keep secrets from a physical attacker on a general purpose microcontroller is an excellent example of an IoT security anti-pattern. It's a shame the author missed the wider point.
So what is the alternative? He is not seriously advocating polling, is he?
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/
Just as anyone can sign anyone's email up to mailing lists.