The AndPlus Blog

In 2015, cybersecurity researchers Charlie Miller and Chris Valasek demonstrated that a Jeep Cherokee could be hacked and its critical systems commandeered over the internet. They were able to completely disable the vehicle in one scenario; later they showed how they could arbitrarily control the vehicle’s acceleration, steering, and braking. Chrysler recalled 1.4 million of the vehicles to patch the exposed vulnerabilities, at great expense (and embarrassment) to the company.

Chrysler was lucky. Miller and Valasek could just as easily have been “black hat” hackers, driven not by a desire to improve automotive cybersecurity but by malicious intent to cause mayhem, kill or injure people, or put a major automotive manufacturer out of business under the certain flood of lawsuits that would result.

Lessons Not Learned

Unfortunately, Miller and Valasek’s excellent adventure in Jeep hacking revealed vulnerabilities ignored by many developers of embedded software and systems. For many, it’s been business as usual, informed by some faulty premises:

• “I implemented password protection, so the device is secure.”
• “It’s just a wireless sensor device. No hacker would be interested in exploiting it.”
• “The device does only one thing, so it’s not vulnerable to cyberattacks.”

All of these notions are false.

Why Embedded Systems Are So Vulnerable

There are numerous reasons why hackers are particularly interested in internet-of-things (IoT) devices and other embedded systems and software as targets for hacking:

• Embedded systems are accessible. If you want to hack into a device, you purchase one and go to work on it, with little or no chance of your activities being detected. It’s much easier and lower-risk than trying to get through layers of physical or electronic security to sneak into someone’s database server.
• Embedded operating systems are often not sufficiently locked down. A device might be installed with a full Linux or Android operating system, and use only a fraction of its features. The unused features are vulnerabilities that can be exploited if they are not disabled or locked down.
• Embedded systems can be difficult to patch. The ability to field-update embedded software has to be designed into the system. If the designers fail to understand the importance of device security (on the assumption the risk is low), they may implement this ability poorly or not at all. Or, they may eliminate that ability in the name of reducing development and production costs.
• There are too many devices to reliably patch. In Chrysler’s case, the automotive industry has a well-established recall process, in which every owner of a recalled vehicle can be notified and can take it to one of the thousands of dealerships nationwide. Not so much for most consumer and enterprise product manufacturers, which may not have robust recall processes and may have millions more devices to deal with. Even where a patch is available and easily implemented, a huge number of devices can be counted on to go unrepaired, leaving vulnerabilities available to exploitation for years to come.
• Developers are lazy. It’s a sad fact that some developers take shortcuts; they “borrow” code from other projects or download it from the internet and incorporate it without fully understanding it. Any security vulnerabilities in those codes are then propagated through a whole new generation of devices.

And hackers know security is often not a top priority (or any priority) for developers of embedded systems, so these devices represent easy and popular targets.

What to Do?

Given both the current ubiquity of embedded systems and their expected explosive growth, the cybersecurity risk is serious and growing. The security of these devices can no longer be an afterthought or ignored. Security assumptions that sufficed when embedded systems were uncommon novelties no longer hold water.

Instead, a new way of thinking about embedded systems development must be adopted by every developer and manufacturer. The central tenets of this concept must include the following:

• Incorporate security into every design, every product, every component—from the ground up. Thinking “security first” when designing and developing embedded systems ensures vulnerabilities are identified and addressed before these devices reach the field.  
• Keep it simple. IoT devices and embedded systems generally, necessarily have only a limited number of features and functions. The software that runs them should be simple as well. The more complex the software; the more security vulnerabilities it will have.
• Protect data at rest and in motion. This means using strong encryption of data stored on a device and transmitted or received by the device. It also means verifying the data as it comes in or goes out. Data that doesn’t make sense or has unexpected values may be a sign that the device has been compromised.
• Design for patching. It’s unrealistic to assume embedded software will never need to be updated. Security patching aside, software updates may be needed to fix bugs, implement new features, or optimize device performance. Updating embedded software on dozens or hundreds of devices at once should be easy, quick, and painless.
• Customize software for the device. It’s tempting to use the same code base across multiple similar product lines, then simply enabling and disabling features as needed for each product. From a security standpoint, the downside is that a vulnerability identified in one product can automatically become a vulnerability in all products. Keeping separate code bases for each product may be cumbersome, but can also isolate security vulnerabilities to a specific product.
• Follow security standards. Several security standards for embedded systems have been published. Choose one appropriate for your industry or product type and adopt it. Make sure everyone on the development and testing team is trained on it.
• Consider both hardware and software attacks. For devices, embedded software represents only part of the vulnerability story. Hardware attacks, such as side-channel attacks, memory attacks, and data bus attacks must be considered and addressed as well.

And finally…

• Think like a hacker. Every designer, engineer, developer, and tester should ask, “Given the design of the device, how could it be exploited to…?” and follow up with as many malevolent scenarios as possible, such as “take control of and destroy machinery” or “spy on people” or “access a company’s network.
  1. Test the device to identify vulnerabilities
  2. Evaluate them on the basis of risk
  3. Address them accordingly

Bottom Line

Embedded systems can be the “silent killer” of businesses and other organizations. Buying decisions must consider security as well as the traditional factors of price, features, and support. Developers of all kinds—“lone wolf” developers, in-house developers, and third-party development shops such as AndPlus need to recognize the importance of security and how to incorporate good security practices into their designs.

At AndPlus, we get it.

We understand device security and how to design for it. We actively incorporate security in every project we work on, whether embedded software or any other kind. Designing for security is not always easy or inexpensive, but the cost pales in comparison with giving security short shrift or ignoring it altogether. We always keep security mindful when designing and developing any kind of software.