Dealing with top-security threats for connected devices

Article By : Eystein Stenberg

Some of the security basics that will protect your devices from most attacks include healthy network segmentation, disabling remote-access services, never sharing keys between devices, and having a quick and secure way to patch software vulnerabilities.

One of the biggest concerns regarding embedded devices gaining connection to the Internet, referred to broadly as the Internet of Things (IoT), is maintaining the security and integrity of the device. According to the SANS Institute's survey: "Securing the Internet of Things" from 2014, respondents saw the following as the greatest threats to connecting devices to the Internet:

• Difficulty patching software on the devices leaving them vulnerable.
• Devices used as infection vectors to spread in the enterprise.
• Denial of service attacks causing damage or loss of life.

A real-world scenario was the infamous Jeep Cherokee hack in July 2015, which was demonstrated by security researchers/white hat hackers Charlie Miller and Chris Valasek. The story exposed the physical safety risk of connecting devices to the Internet with the remote exploit providing them full control of the car. Fiat Chrysler Automobile, the manufacturer, had no way to provide an over-the-air software update to fix this remotely, and thus 1.4M vehicles were recalled. ABI Research estimates that about one third of all current recalls for the automotive industry are problems that could be fixed with the capability of over-the-air software updates, at a savings that would have equaled about $6 billion USD in 2015.

A method that Mr. Miller and Mr. Valasek used to gain control was the delivery of an unauthorized update to the CAN (Controller Area Network) bus. The CAN bus connects around 70 ECU's (Electronic Control Units), including engine control, transmission, airbags, and braking.

The V850 chip was designed to only read from the CAN bus in order to isolate components. But the head unit can update the firmware of the V850, and they found the firmware update authenticity did not have the proper checks in place. Thus, the malicious firmware update gave them full control through the V850 chip to various other system components.

The specific lesson learned from this episode was that the remotely accessible service — the head unit (infotainment system) — was vulnerable and not updated. The firmware update for the V850 did not have the proper checks for authenticity, and the only way to fix the vulnerabilities was through a very manual update, thereby driving up Fiat Chrysler Automobile's costs. Some security design techniques to minimize the risk of a breach such as this are the principle of least privilege, separation of privilege, and Kerckhoff's principle.

The principle of least privilege promotes minimal user profile privileges in computer systems and — in this specific context — devices and components. Each system component or process should have the least authority necessary to perform its duties; for example, by asking simple questions like: "Does this component need to run as root?"

Separation of privilege considers whether components can be better isolated; for example, do they require access to the network as well as access to sensitive data? The purpose is to limit the impact of a successful attack, which inevitably will happen, by avoiding a "domino effect" of compromised components. Following the separation of privilege principle at a higher level also implies ensuring that keys are not shared between devices, and that healthy network segmentation is in place between customer, internal, and public networks.

In cryptography, Kerckhoff's principle states that a cryptosystem should be secure, even if everything about the system — except the key — is public knowledge. One must only assume keys are secret, not designs or algorithms. We encourage all teams building connected devices to rely only on industry-standard communication/crypto protocols.

Timely security patching is another requirement as statistics show. A publication of Kenna Security states that, if security patching is performed within 5-10 days of a vulnerability becoming public, there is less than 10% probability an exploit will exist for it. By comparison, when leaving a vulnerability unpatched for 60 days, there is nearly a 90% probability it will be exploited. Unfortunately, the average remediation time is 110 days, thereby leaving a large time window for automated attacks to succeed.

Patching connected devices is much more difficult than server infrastructure. Physical access is either not an option or is very expensive; thus, failure management is absolutely required. Unreliable power and unreliable network connectivity are other issues, as well as public or insecure networks. Can someone inject arbitrary code during the update process? Are there clear checks in place to verify the authenticity of the update?

There are different strategies to reduce the chances of your connected devices 'bricking' during the update process. Signing and verification of the updates (e.g., image artifacts) for authenticity can help prevent a malicious update. Rollback support will also ensure your device falls back to its last working version if the update should be interrupted by device power loss or installation errors. Another approach is phased rollouts, with the ability for granular management for the population of the device.

In conclusion, some of the security basics that will protect your devices from most attacks include healthy network segmentation, disabling remote-access services, never sharing keys between devices, and having a quick and secure way to patch software vulnerabilities through automation. Many of the embedded engineers to whom we have spoken perform manual 1:1 software updates to devices, thereby creating a bottleneck with regard to securing their fleet of devices. The Center of Internet Security states that 80%-90% of security breaches can be prevented; if you follow these security best practices, you will be in a better protected position.

About the author
Eystein Stenberg is the Product Manager at Mender.io, a provider of an open source product to deliver over-the-air software updates to connected Linux devices. Eystein has over 7 years of experience in the front lines of some of the largest production environments in various roles, and he has in-depth knowledge of the challenges in system security in a real-world context. Eystein holds a Master's degree in cryptography, and his writing credits include Distributing a Private Key Generator in Ad Hoc Networks.