On October 21st, there was a coordinated Distributed Denial of Service (DDoS) attack on an internet infrastructure company called Dyn. The attack resulted in a nationwide slowing of many web properties on the internet.
The image above shows the areas affected by the internet outage. This attack had widespread effects for hours that day.
The attack was strongly assisted by Internet of Things (IoT) devices that still had the default, out-of-the-box username/password configured. This was a low moment for the IoT world. Changing default logins is basically Security 101. I can clearly remember in just about every training class I’ve ever been in -- whether for hardware or software -- that there is a default, and the absolute first thing you have to do is change the password. On the flip side of this, one of the first things you learn when you learn to hack is to look to see if the default has been changed, because people don’t always change it. Friday the 21st showed us what can happen when you don’t.
IoT, The idea of "smart devices" that don’t require human interaction, is growing up fast. There are more devices out in the wild every day. In fact, we sell them. The ESP32 Thing is another example of a device, in the wild, that is perfectly suited for helping you create great IoT computer systems.
IoT systems are computer systems, and computer systems are inherently insecure. An individual computer will have clear vulnerabilities. Networks will have flaws. The Zero Day attacks will always exist. It is simply true that the business of computer, network and systems security is large in and of itself because the threat is ever-present. IoT will probably not be any different. We've seen this issue with large distribution of firmware problems before, and we'll see it again. The fact that IoT devices are computers makes them at once the same and, because of the scale, pretty different.
There will be no magic bullet for IoT, just as there isn’t for any other type of compute device. Any device inside of an IoT system will be a vector for attack.
Smart devices, or IoT end points (basically any compute devices on a network), need to become dumber. If you are going to have a large-scale network of nodes, they need to do less, especially if they are commercially built. These devices will be inherently smaller and have less compute power. Running complicated security routines on the device will be one of the first things removed in the name of cost and simplicity. In my opinion, more things should be removed. Devices become a problem when a standard function gets exploited. Maybe it’s time to strip down what these devices can do and simplify their functionality.
Simple firmware that shouldn’t inherit extra functionality includes protocols designed from the ground up to do the simple tasks their creators actually intended, and nothing extra that doesn’t need doing. Do you need a single-board computer for this, or will a microcontroller with a simple command and no way to remotely update the code work in your situation?
How can you make your system safer? I asked this very question to friend of SparkFun Josh Datko. Here is what Josh had to say:
When I talk about this I consider three entities:
- How does the maker secure their projects?
- How does the consumer buy secure products?
- How does the professional engineer build secure products?
For all of them, the answer is to think about what's called in security jargon a "threat model" – basically, a risk analysis. So I'd say to the maker, if she is trying to blink an LED over WiFi for a demo, the security needs are probably pretty low. BUT, what happens with that ESP32 when you are done? Did she wipe the WiFi creds before throwing it away?
The answer to #2 is a bit harder. Right now, we don't have a good way for consumers to know things are secure. But what I say is, "Do you need that connectivity feature?" For example, take smart door locks. I would never buy a smart door lock; I don't want it connected because, to me, the risk of electronic attack is greater than the risk of physical lock picking.
However, UL is making a good effort here. There is a new standard, UL 2900 (full disclosure, Josh is on the technical panel), where vendors can get a UL certification for their product. It's a pretty comprehensive certification.
I do think certifications will help the industry here. It puts the onus on the OEM, where it belongs. UL 2900 isn't a silver bullet, as you point out, but it is progress.
Finally, #3 is harder still. It's the same answer as to the joke, "How do you get to Carnegie Hall? Practice." Building secure stuff takes study and practice.
With Josh's thoughts in my head, I want to give you some things to think about when trying to make your system more secure. Think along the lines of the threat model:
- At every link in the chain, what is the security layer?
- Can I remote into the device? Do I need to?
- Did I change the password?
- Do I have a better method of gaining access? Network?
- Did I create a standalone IoT WiFi network? Is it secure? Does it share passwords or connection points with anything else in my home?
What about servers? Do I have passwords on them? Are there safer ways to connect? (There are.) Am I using a third-party system? Is the password on that different from other systems? Is two-factor authentication an option? If so, turn it on!
Does this seem like a lot? It should – security is complicated.
Michael Collins, a good friend of mine, just happens to have actually written the book on network security. I asked Michael about these issues as well, and his response was perfect: "One of my basic points about security... security is restrictive. Security is fundamentally about restricting functionality, whereas most design is about broadening it."
The devices that SparkFun sells are open by design. When discussing the concept of security vulnerabilities with our hardware, our engineers see them as an accessibility feature designed to lower the barrier of use for our products. They are right. The problem is that access, by its very nature, is insecure. Making devices that are simple to connect means they’ll be a little less secure. Hopefully you can follow our advice and ensure that a device with a little less security is now connected to a network with a bit more as the trade-off. Worried that isn’t enough? You can always grab our CryptoShield:
Overall, good computer and network security practices don’t go away with IoT; they actually become more important. If any compute device, end point or node in the network can be vulnerable, having more of them can only increase the problems. IoT security will be a field in the near future, but it is just an extension of the computer security field as it exists now.
Tutorial idea: Basic IoT/network security. Topics could include disabling unnecessary functionality in common hobbyist boards, segmenting one's home network into multiple VLANs, and setting up separate wifi networks for IoT devices.
If this isn't in the works already (very possible) consider on the list.
Try not to take your own IoT gadgets to work. There are loads of potential security attentiveness toward wearables. Each endeavor ought to have an unmistakable BYOD approach, and it's regularly a smart thought to deny individual IoT gadgets from associating with the system, or if nothing else restrain them to a visitor arrange. Track and evaluate gadgets. Organizations need to track everything associated with the system and screen the stream of movement. Gadgets should be evaluated to decide the level of get to they ought to have, to keep them completely fixed and state-of-the-art, and to secure information end-to-end to safeguard its respectability (read more). Obscure gadgets ought to hail a caution. Understanding which gadgets are associated and what they're doing is an essential for appropriate security.
Actually it is worse than you describe.
Many of the devices had telnet and SSH available without the ability to change the password for those protocols, or to disable them.