Until recently, security in embedded software was not widely discussed. Now, if you attend any IoT conference, you will find it on the agenda of numerous presentations. Vendors of new frameworks, processes, or communication protocols all mention security even if it’s only an aside, as in, “Oh, and it’s secure.” Given that your system is only as safe as your weakest connection, it’s imperative to understand and plan for security threats you may encounter when you connect your system to the Internet of Things.
Today, embedded systems (systems with built-in intelligence that are not yet connected to the Internet) are in a similar predicament as were PCs 20 years ago: no antivirus software, no firewalls, no protection. Experience can be a great teacher. We can’t afford to make the same mistakes we made then, because the stakes of security breaches today are much higher. We need to apply the knowledge and understanding gained in the PC era. But in doing so, we need to understand that those best practices cannot be incorporated using a copy/paste mentality.
Security through Obscurity: If you can talk to it, you can hack it
Traditional embedded systems, because they weren’t connected to the Internet, could claim that they were secure. You could lock an embedded system in a room on the 50th floor of a high-rise, and no one would be able to hack into it. But once you grant access to the device, even if it’s through a local network, it can be subject to Internet-based attacks.
There are many reports of security breaches and hacks showing up in the news. As you hear about them you think, “This couldn’t happen to our company,” but in reality the chances of intrusion are high. Just the simplicity of the point of attack is cause for concern. For example:
- Target – Network hackers attacked the Target point-of-sale system, which was not connected to the Internet, but was connected to their in-store network. Their HVAC system was being controlled and monitored over the Internet by a local contractor. The contractor was hacked – which gave the hackers access to Target’s HVAC system and they then used it as the attack vector to reach Target’s POS system.
- Dyn – DDOS (distributed denial of service) attacks repurposed (hijacked) a large number of IoT devices so that they could be formed into powerful botnets. This was possible because Internet-connected devices such as cameras and printers have notoriously lax security, especially against malware infections.
When you’re developing new software for your embedded system, how do you make sure your device is protected from these threats?
IoT security: Understand your threat model
You’re probably thinking, “I get it, but what do I do now?” There are multiple factors to consider and various ways to apply security. If you focus on these three areas, you will be well on your way to a secure embedded system.
Identify the risks; uncover your weak links
- Identify pieces of code or system access points that create vulnerabilities
- Understand what an attacker can achieve by exploiting these vulnerabilities; you need to think like an adversary here
- Reinforce those weak links. If not physically secure, define criteria to secure it.
Understand what it is you are protecting
- Are you protecting the system, or the data? In order to protect the data, you must also protect the system, but not necessarily vice versa. A protected system could still display or communicate data in the open.
- Don’t go crazy protecting data that doesn’t matter; focus on what is important and valuable
Determine who your likely attacker would be
- Is it a hobbyist looking for fun, fame, or fortune? A nation-state cyber-soldier? A terrorist or saboteur? Or a competitor looking to steal your ideas and customers?
- The level and type of security you implement will depend on who is behind the attack.
Assessing your security strategy
When tasked with securing your particular hardware, the first thing to ask yourself is, “Do I have the expertise on my staff?” As you look across your team of developers you might find an abundance of hardware or mechanical engineers, and may even find a group of software people. Although these people are experts in your domain, they quite likely have never had to deal with security.
A logical step is to engage your IT department for security advice, but securing a server is quite different from securing an embedded device or system. Servers are locked in a room, limiting physical access to them. In addition, the tools to protect and monitor servers are quite different than those to protect embedded systems.
In the embedded systems environment (where you add connectivity into a physical device or system) you must also consider:
Physical Access – Physical attacks are much more likely to happen on an embedded device because you usually build more than one – maybe even several thousand, which means your potential attacker will have easier access avenues. For instance, hackers can purchase a camera and probe and play with it for weeks until they figure out how to break or repurpose the device to do terrible things.
Lack of monitoring – Embedded environments generally have no means of monitoring for tampering or illegitimate access. They have to live on their own and either succeed or fail. Which brings us to the final difference.
Software updates – The majority of embedded devices out there today will never be updated. Whatever security holes or bugs exist in that first release, that’s what is going to be in play for the life of the device. Allowing access to the device for remote updating can fix these issues, but if you do that, you expose yourself to an even more insidious threat – the ability to replace the code on the device – and so you must plan for that.
If you discover that you don’t have the security expertise in house, you’ll end up looking for a company that possesses the knowledge and understanding of embedded systems. The good ones will have extensive experience in solving security issues for companies that are in the same situation as you find yourself. In many ways the technique for attacking, say, a camera can be much the same as for an HVAC system; expertise in embedded system security is quite transferable (although the seriousness of a breach varies widely, obviously). Make sure whomever you choose has the same level of domain expertise in embedded security as your team’s domain has expertise in your industry.
