Bench Talk

(Source: Nikolay N. Antonov - stock.adobe.com)

While embedded systems tend to lack the processing horsepower of servers or even modern personal computers, the sheer number of devices is making them an increasingly valuable target for bad actors looking to run illegal botnets and cryptocurrency mining operations. One of the first major security-related wake-up calls for embedded system designers was the 2016 Nest thermostat botnet attacks. Given the consumer-facing nature of the particular Internet of Things (IoT) coupled with an increased sensitivity regarding privacy and security; the Nest botnet caused a huge amount of discussion. Those discussions tended to center on how companies should build security into their low-cost IoT products and how consumers can safely operate the devices in their homes and businesses.

With the growing threat of cyberattacks, it is essential that developers keep security considerations in mind throughout the design process. By following some practical tips and recommendations, developers can guard against a wide range of attack scenarios. Read on for an outline of security measures developers can use in their embedded designs.

While there are numerous chip architectures, operating systems, and communications protocols; many IoT devices tend to be built around Arm^®-based architectures, and if they run an OS it tends to be a Linux distribution. This commonality is good in many ways; lower costs and faster development times; it also comes with quite a few negatives. Attack vectors tend to become “one-size-fit-all”, especially for devices running a Linux-based OS. To mitigate the threats associated with widespread devices that share a common architecture, developers should implement the following “quick win” security design principles:

• Do NOT hardcode passwords into the firmware. Also, do not use a common default password for all devices. Require the user to create a custom username and password during device initialization.
• Do NOT enable insecure protocols such as HTTP, FTP, or Telnet by default. Data going off the device via wired or wireless protocols must be strongly encrypted. Avoid “homebrewed” encryption solutions.
• Ship the device with the most restrictive configuration possible and let the end-user make a proactive decision to reduce security-related settings.
• All mechanisms used to access the devices should require authentication and authorization controls. Two-factor authentication (2FA) should be used if practical.
• All user-facing inputs should be filtered to avoid injection-type attacks.
• Implement a secure device management interface for the end-user that will allow them to manage their assets, update devices, monitor devices, and securely decommission the devices that have reached their end-of-life (EOL).
• Over-The-Air (OTA) update mechanisms must be validated on-device. The update files must be sent encrypted en route to the device. Lastly, ensure there are anti-rollback features to prevent a device from being reverted to a previous, insecure firmware.
• If third-party software libraries are used in the design of your device, they must be continually monitored to ensure that third-party updates are integrated and that they do not become deprecated. Abandoned software projects can become nasty vulnerabilities for your device. Change the third-party software default passwords before committing them to your project.
• Limit what sensitive data should be stored on the device. Store such information in a secure enclave only.
• Remember that with the IoT that embedded systems are only one part of a larger ecosystem. Ensure that security is built into the cloud, desktop, and mobile applications as well. Ecosystem security is only as strong as the weakest link.
• Consider establishing a bug bounty program to encourage end-users and security researchers to submit flaws in a secure, responsible manner.

Physical access to a device tends to be the game-over situation for devices. That doesn’t mean that there aren’t things that can be done to make it harder physically exploit these types of devices. Entire books have been written on making circuit boards and associated enclosures tamper-resistant but for a few “quick wins” consider the following physical design rules-of-thumb to harden your device:

• Pins for debugging ports such as JTAG and UARTs are very useful when developing and testing a device. They are also tempting targets for those seeking to reverse engineer a device with ill-intent. Obfuscating these pins and/or removing header pins for production units is recommended. Note that this will come at the expense of making it more difficult to troubleshoot once fielded. Designers must consider a balance between security and maintainability.
• The use of adhesives, ultrasonic welding, and/or specialty security screws can make it more difficult to open a device.
• Applying a non-conductive epoxy over sensitive components can obfuscate their identity and purpose.
• You might be tempted to use older components that might have vulnerabilities. Be aware of the counterfeit components as well. If a deal seems too good to be true, it probably is. Balancing security and time-to-market considerations is not a decision to be taken lightly.
• Multilayer boards can be used to route traces in a way that makes it harder to discern how the board functions.

Some of the following recommendations might be a bit much for consumer-grade IoT devices. However, as we will elaborate on later, industrial control systems and defense systems would likely benefit from these more robust physical security measures:

• Build security features into the board itself, such as microswitches, mercury switches, or magnetic switches that can detect if a board is being unintentionally handled or opened. Nichrome wire or fiber optics can also be used. If the wire or fiber is negatively impacted by someone trying to tamper with a device, then there will be a detectable change in the current flow of the wire or the behavior of photons through the fiber.
• Side Channel or glitching attacks, while perhaps not common, provide a unique advantage to adversaries in that they use the laws of physics against a device and thus are very difficult to prevent though can be detected. By attacking the timing or restricting the flow of electrons to a CPU, it’s possible to get a device to act in unintended ways that negate security features. Voltage and current sensors can be implemented onboard circuit boards to detect if glitching may be occurring, though there is potential for false positives.
• Significant adversaries can employ x-ray machinery to peer into microchips and discover the topography of the transistors to determine function and more. Sensors that detect x-rays can be added to detect tampering, though can do nothing to prevent an adversary from extracting useful information.

It should be noted that there is quite a dichotomy between the paradigms of security and openness. Security values obfuscation. Open hardware values understanding. Regardless, keep in mind the old adage that locks only keep honest people honest, and so too with security-at-large. For more information on how to build secure IoT devices, visit the Open Web Application Security Project (OWASP) IoT Project.

Even if a manufacturer could implement all the best secure design principles in their product, they would be mostly for naught if the end-user does not operate their device in a secure manner.

• Change the default router name, router password, network name (SSID), and network encryption key. Be sure to use strong password principles and do not use the same password for both networks.
• Segment your home network into two “virtual” networks so that IoT devices cannot be “seen” by the desktop computers, Network Attached Storage (NAS) devices, etc. To do this quickly and easily, use the guest network feature for your IoT network.
• Most IoT devices rely on a smartphone app to control the device. Keep the app up to date and use 2FA for login if available.
• Disable any features of your IoT devices that you do not intend to use.
• Update the firmware of both your router and IoT devices on a regular basis.
• When an IoT device reaches the end of life and no longer receives updates consider replacing it with a newer model.

Consumer-facing IoT products may be plentiful, but their industrial counterparts, collectively referred to as Industrial Control Systems (ICS) manage numerous extremely important and potentially dangerous processes. Everything from energy production to factories uses embedded digital technology (referred to as Operational Technology or OT; in contrast to office-centric Information Technology or IT) to control the facilities and associated machinery responsible for performing the various processes. The ICS environment is sufficiently different from a strict IT environment that special considerations for hardening OT devices and ICS networks are warranted. The most fundamental principle is that ICS should not have a connection to the internet. While this seems like a no-brainer, it is surprising how often this fundamental rule is violated. For more information on how to secure ICS networks and devices, there are two security frameworks you should review: MITRE ATT&CK for ICS and the MITRE ATT&CK for Enterprise.

The nature of where ICS systems are typically found (e.g., areas that are environmentally, chemically, or otherwise hazardous) means ICS has been designed to prioritize the availability of the systems over confidentiality. From a positive perspective, this typically means there are redundant systems and those systems are designed to fail safely. However, ICS systems can be left in operations for several decades and may not always be kept up-to-date. In addition, many of the protocols are older and were built with efficiency, not security in mind. Bottom line, security in the ICS or IIoT space is uniquely challenging and best practices may be difficult to implement. However, embedded developers for such machinery should be cognizant of the need to modernize their design practices and incorporate security into future designs and not treat it as a bolt-on afterthought.