Cybersecurity has long been a critical focus for large enterprises. Now IoT device design engineers must take a page from the enterprise security playbook.
Alan Grau, Sectigo, VP of IoT
Though Internet of Things device manufacturers are heavily investing in the development of new solutions, these organizations often lack the security expertise and the technical resources to ensure that high levels of security are built into their products. Many of these connected devices employ new protocols, platforms and middleware solutions that have not been thoroughly vetted for security issues. The result, not surprisingly, is a slew of devices that are easily compromised by hackers.
A host of new IoT cybersecurity standards and legislation have been proposed or enacted in recent years that require OEMs to build security into their devices. Standards from NIST, IETF, and GSMA, provide the foundation for many of these regulations and other related standards, resulting in similar security fundamentals across industries, so it is not surprising to find common requirements across these IoT standards:
• Secure boot using a hardware root of trust
• Secure software update capability
• Ensure each device has a strong unique ID
• Monitor network activity for unauthorized use
• Disable all unnecessary ports and services
What do these guidelines mean for engineers working on a IoT devices?
The use of multiple layers of protection, including firewalls, authentication, security protocols and intrusion detection/intrusion prevention, is a long-established driving principle for enterprise security. In contrast, most IoT devices, especially sensors and low-cost devices, lack basic firewalls or security protocols, and often rely on little more than simple password authentication.
For decades, device manufacturers assumed these devices were not attractive targets to hackers or vulnerable to attacks. That is no longer true. Many attacks are automated with hacking bots scanning ranges of IP addresses looking for vulnerable targets. Furthermore, these edge devices, if compromised, can become an entry point into larger systems and networks. Attacks against all types of embedded devices are on the rise and greater security measures are now needed.
For over 25 years, cybersecurity has been a critical focus for large enterprises. Now device design engineers need to take a page from the enterprise security playbook.
Before diving into the problem of how to secure embedded and IoT devices, it is important to consider the origin of security vulnerabilities. Broadly speaking, most vulnerabilities in embedded devices can be divided into one of three categories: implementation vulnerabilities, deployment or use vulnerabilities, and design vulnerabilities.
Implementation vulnerabilities arise when coding errors result in a weakness that can be exploited during a cyberattack. The infamous, and seemingly immortal, buffer overflow attacks are the classic example of implementation vulnerabilities. Other examples include improperly seeding random number generators, which can result in the generation of security keys that are easy to guess. Adherence to software development processes such as the OWASP Secure Software Development Lifecycle or Microsoft’s Security Development Lifecycle, and thorough security testing processes, help to address implementation vulnerabilities.
Deployment vulnerabilities relate to issues that are introduced by the user during the operation or installation of the device. These would include issues such as not changing default passwords, using weak passwords, not enabling security features, etc. While this is, at least on the surface, a user issue, a security-oriented design that eliminates the passwords and user controls that allow weak security options can help prevent deployment vulnerabilities.
Design vulnerabilities, the focus of this article, are weaknesses that result from a failure to include proper security measures when developing the device. Examples of design vulnerabilities that have resulted in security breaches include use of hard-coded passwords, control interfaces with no user authentication, and use of communication protocols that send passwords and other sensitive information in the clear. Other less-glaring examples include devices without secure boot or that allow unauthenticated remote firmware updates.
IoT devices comprise of a wildly diverse range of device types–from small to large, from simple to complex. Many of these are embedded devices and are quite different from standard PCs or other consumer devices. They are fixed-function devices specifically designed to perform a specialized task that uses a specialized operating system such as VxWorks, FreeRTOS or Integrity, or a stripped-down version of Linux. Installing new software on the system in the field either requires a specialized upgrade process or is simply not possible. In most cases, these devices are optimized to minimize processing cycles and memory usage and do not have the extra processing resources required to support traditional security mechanisms.
As a result, standard PC security solutions will not solve the challenges of embedded device security. In fact, given the specialized nature of embedded systems, Windows-based PC security solutions will not even run on most embedded devices.
So, the challenges for IoT security are basically these:
1. Critical functionality: IoT devices often control critical systems and manage sensitive data. Factory control systems, transportation systems, the electric grid and medical systems are all controlled by IoT and embedded devices.
2. Replication: Once designed and built, IoT devices are mass produced resulting in thousands to millions of identical devices. Once a vulnerability is discovered, a successful attack against one of these devices can be replicated across all the devices.
3. Security assumptions: Many IoT device engineers have long assumed their products are not targets for hackers and have not considered security a critical priority.
4. Not easily patched: Most embedded devices are not easily upgraded. Once they are deployed, they will only run the software that was originally installed at the factory including any vulnerabilities.
5. Long lifecycle: The life cycle for embedded devices may be as long as 10, 15 or even 20 years. Building a device that will stand up to the ever evolving and increasing security requirements of the next two decades is a tremendous challenge.
6. Deployed outside of the enterprise security perimeter: Many IoT devices may be deployed in the home, a remote location, or other environments lacking the protections found in a corporate environment.
7. Device health: There is typically no way for the end user to easily monitor the device’s security health or to make changes.
The level of security required for a IoT device varies depending upon the function of the device. Rather than asking if the device is secure, OEMs should ask whether the device is secure enough. We are no longer talking about protecting a device from just malformed IP packets or DoS packet floods. Hackers know how to research their targets. They often have detailed operating information on the device they are targeting and have sophisticated toolkits and skills that can be used to develop fine-tuned attacks.
Have you considered how to protect your connected devices from attack from a group with detailed knowledge of the inner workings of your product? Hacking is not just the domain of bored teenagers, hacking drones, or even the small groups of motivated hackers. When the stakes are high enough, cyberattacks are multi-phased, multi-year efforts carried out by large, well-funded teams of hackers.
A security solution for IoT devices must protect firmware from tampering, secure the data stored by the device, secure communication, and protect the device from cyber-attacks. This can only be achieved by building in security from the earliest stages of design.
Unfortunately, there is no one one-size-fits-all security solution for connected devices. Engineers must take into consideration the cost of a security failure (economic, environmental, social, etc.), the risk of attack, available attack vectors, and the cost of implementing a security solution.
Features that should be considered include those pertaining to the supply chain. A diverse supply chain adds to the complexity of developing secure devices. The recent SolarWinds hack, while not an IoT attack, shows that securing the supply chain is a critical requirement. In addition to ensuring proper security measures are built into the device, the OEM must impose secure development processes and monitoring of suppliers to prevent the introduction of vulnerabilities in firmware components.
In any event, including the latest security protocols and technologies in IoT devices is essential. Security features must be considered at the beginning of the design process to ensure the device will stand up to the numerous advanced cyber threats it will likely face.
You may also like:
Filed Under: TECHNOLOGIES + PRODUCTS, Microcontroller Tips, Manufacturing, TIPS SITES (EE World)