Sun Tzu wrote “If you know the enemy and know yourself, you need not fear the result of a hundred battles” and knowing what to defend against will let you prioritize your time and energy.
Attacks are how your opponent will be trying to crack your security, so they can gain control or extract information from your IoT device. Some attacks are easy to counter, some are extremely hard. How much time and money you spend will depend on what you’re protecting and protecting against.
The most common type of attack is an automated login tool, that will try to connect to every IP address on a network and login using default passwords or common passwords. For example, if an IoT camera is connected to the open internet and has a default password and login of admin/admin, that would be super easy to automate with a script. Every time a new IoT device is sold with a default login, that’s added to the hacking list, so that the script will try anything it can. These tools are incredibly effective because they can sweep through millions of IP addresses around the world, while the hacker is sound asleep.
This attack is really easy to defend against, and you must spend the effort. Most obvious is don’t have a default password - instead, have the password distributed with the product on a sticker, just like your WiFi router has. You can guess who got bit by this security flaw after many years: router manufacturers! Make sure the password is long and complex enough so it cannot be guessed - and don’t use public information in generating the password, like a MAC address.
A close relative to automated logins is an automated vulnerability exploit tool. Say you have the bestest, longest password, but it turns out there’s a flaw in the firmware or operating system you’re running. That flaw could be exploited to allow an outsider access into the device even without a password. The good news is that these exploits are not very common if you’ve configured your IoT operating system well. The bad news is that when they do happen, they can be catastrophic. There’s no defense against them other than upgrading or patching the software, and there’s no way to predict or protect against it - even the most expensive and proprietary systems can have flaws.
In this case, all you can do is take steps to minimize the risk, and maximize the ability to repair. If at all possible, do not have a public-facing internet administration system. Disable SSH, ftp, telnet, webserving, as well as any other service you can do without. Run the latest operating system and have a way for users to update the firmware, or have automatic firmware updates that are fetched and installed by the system itself. If there’s an app, have it remind the user to update constantly. And, if possible, have a way of contacting customers so you can let them know if there’s an emergency update - it’s better to have it and not need it, than need it and not have it.
The next most common set of attacks, we’ll group together and call the “sniffing, spoofing, replay, and man-in-the-middle” group.
Sniffing is the ability to listen in to the communication going on inside or through your device.
Spoofing is being able to trick the device into trusting something it should not. Replay is sending data (often sniffed) over again to a device. Sometimes this lets the hacker repeat an event, sort of like spending the same quarter twice.
And Man-in-the-middle attacks are a little like a cross between sniffing and spoofing - you get ‘in the middle’ of the device communications, shuffling data back and forth but modifying the data to suit your hacking needs
These techniques are often used together. For example, let’s say you have an IoT device with a login website. You’ve got a unique password requirement. But, you forgot to require encryption for the connection. Your customer logs into the device from the coffee shop across the street and it turns out that their network has been hacked (due to a default login-password on the WiFi router) and someone listens to all the WiFi traffic and records the login and password for the IoT device, which they can then reuse - that’s a sniffing attack.
Or, say you want to defend against the Automated exploits class of attacker, so you create an over-the-air firmware update service that will send updated firmware once a week. A hacker buys one of these devices, and listens in to the network traffic during the firmware update and discovers you forgot to authenticate the connection. With some effort, she is able to craft a custom firmware upgrade, that creates a default-login backdoor, and deploys it in an automated fashion across the internet, targeting every installation of the device, for global domination. That’s a spoofing attack.
That’s not all the attacks you have to worry about, there’s a long tail of many more ways to trick computer devices - after all computers do whatever we ask, without judgement. For some companies, especially ones with health, safety or money on the line, there’s a lot of continuous research needed to keep up to date with attack vectors, and stay ahead. For most others, it’s better to follow the best practices we’ll outline than do nothing. And, as your company and product succeeds, you can invest more into improving security such as hiring specialists.
Some things you shouldn't focus all your time on is having your hardware manufacturer modify your design to add spy technology to the PCB. We’re not saying it’s impossible, just that while these sorts of attacks get a lot of attention, they are very expensive and time consuming, compared to the automated attack scripts that are your greatest risk. When you outsource your manufacturing, there are some risks involved - Your contract manufacturer is most likely to swap components on you, using lower quality or cloned components, or perhaps sell off your IP to a competitor, rather than trying to modify your hardware. And, if you’re the kind of company that has to seriously worry about state-level attackers, with vast resources, you are also the kind of company that owns their own manufacturing, or can afford to staff the CM with auditors.
That said, after you go to manufacturing, it's not a bad idea to disassemble and inspect a few random boards from your fabrication run, to catch quality and security issues such as "are those unique passwords really unique" Have your firmware images cryptographically signed or authenticated, and then verified post-manufacture by your in-house team (or a trusted auditor).
Of course, this isn’t all the ways that you’re going to get attacked, just some of the most common ones. So, how are you going to protect your design?