Wishful thinking once prevailed that embedded systems, especially small embedded devices, rarely needed security, and if they did, simply installing a “secure” operating system or a security chip would keep them safe. Connecting devices big and small on the Internet of Things (IoT) shattered such insular thinking by exposing the massive scale of possible exploits. Secure-IC is challenging stale design assumptions to raise awareness about securing embedded systems in a new white paper.
Risks become unbounded when all devices connect
How about a straightforward question to start the discussion: Will your new product contain electronics? Back in the day, embedded systems relied on an air gap for security. Hacking into an embedded system meant bringing a cable, or more recently, a USB thumb drive, and physically connecting to the system. If the system was behind a locked door, even better.
Expectations have changed. Even the most mundane electronic devices now often have a wireless connection to communicate with the things around them. Many homes have Wi-Fi thermostats, cameras, doorbells, TVs, soundbars, and small or large appliances. My bike computer is on Wi-Fi. People also have Bluetooth earbuds and other sensors connected to a smartphone or smartwatch, which connects to Wi-Fi or a 5G network. Late-model cars have 5G connections for services as well.
Here’s where the skeptics interject, “Yeah, but no hacker wants to spend effort getting into your bike computer – there’s nothing of value there.” Hackers go after much juicier targets like servers with personally identifiable information (PII) or financial records. That skepticism increases the risk because designers and users either overlook securing embedded systems entirely or misunderstand the implications of their vulnerabilities. Billions of connected devices drive risks to unbounded levels if security isn’t designed in from the start.
A broader case for securing embedded systems
Headlines of websites taken down by distributed denial of service (DDoS) attacks are familiar. Ever think about where the DDoS attack came from? There must be server farms or a network of laptop and desktop machines in different countries generating all that internet traffic aimed at one site, right? Not necessarily.
Enterprise network security can be complex at scale, but generally, one knows where to start. When somebody spins up an application server, they think of securing it from the outside world. A bunch of application servers may sit behind a firewall or other security appliances in an enterprise setting, again points where security is at the forefront and managed accordingly.
Securing embedded systems should start from the perspective that there is no “there.” The same embedded device can be in my home, your home, and a million other homes. If someone learns how to get into one device, they can probably get into most of them. That leads to a specific vulnerable device, like a baby monitor or a doorbell, exposing privacy in various ways. But it also leads to a broader possibility – a network of vulnerable devices used en masse can do something, like a DDoS attack. As Secure-IC puts it in their white paper:
A single system security flaw opens a path to millions of opportunities for hacking.
Hackers using a manufacturer’s device maliciously create reputational harm for the manufacturer and perhaps manufacturer liability for damages inflicted – often at no risk for the hackers if they can’t be identified. Risk also extends beyond a specific device. Anything using the same model of operating system, embedded processor, or security chip can have the same vulnerabilities if unaddressed.
Nine points to consider for embedded systems security
Designers are often not experts on securing embedded systems, and even experienced teams can run into security potholes – but there is help from firms specializing in the arena. Secure-IC discusses these and more ideas and presents nine points designers must consider before designing a device in their new white paper. Point #5 is not to be understated: security cannot be added in later; it starts when the design project starts. See more discussion on that and the other eight points by downloading a copy here:
Share this post via:
Real men have fabs!