Embedded devices, including factory control systems, smart-grid control devices, medical instruments, and consumer electronic devices, are the fastest growing segment on the Internet. One report predicts that the number of embedded devices on the Internet will be five times the number of PCs by 2015. Over half of new embedded designs include networking.
The result is a vast array of devices performing critical functions that are at risk of cyber-attack. One does not have to look far to find examples of successful attacks against embedded devices.
Endpoint security requirements
Endpoint security is in contrast to network security, where you assume the device is safe if it is on a network that is secure (i.e., behind a corporate firewall). Unfortunately, a dedicated hacker can penetrate most corporate firewalls, or the attack could originate from inside the corporate network. Endpoint devices need their own wall of defense.
The requirements for endpoint security in embedded devices are the same as for PCs on a corporate network. If the network supports a network security manager and/or a Security Information and Event Manager (SIEM), then the endpoint security solution should support integration with these management systems. While the requirements for embedded devices are the same as for PCs, the solution must be different. Endpoint security solutions for Windows or Linux PCs won't work in embedded and RTOS-based systems. RTOS and embedded Linux systems typically require a custom solution.
Why embedded devices lack comprehensive endpoint security
Historically, embedded device engineers and developers did not believe they needed comprehensive endpoint security. This philosophy is generally based on one or more of the following assumptions:
- Embedded devices are not vulnerable to the common Internet-based threats such as viruses and DoS (denial of service) attacks.
- The designs are special purpose and only process packets they are expecting. Since the device is not listening for packets on general-purpose ports like a PC, they are safe from attack.
- No one is developing attacks specifically for embedded devices.
- Attacks built for one embedded device will not scale to another device or class of devices.
- It doesn't matter if an embedded device is attacked. It will just reboot and begin processing again.
- The device is secured by encrypting communication and ensuring remote log-ins are secure. That is all that is needed.
- The device will only be used on a private network so there is no need to worry about it being attacked.
Each of these assumptions is based on faulty or outdated thinking.
Not vulnerable
While embedded devices are generally not vulnerable to Windows viruses, there are a growing number of other Internet-based attacks to which they are vulnerable. DoS attacks are on the rise, and many of these attacks are general attacks and against IP addresses. They do not necessarily target a specific enterprise, domain, or operating system. New attacks are constantly being launched, and some specifically target embedded systems.
Many embedded devices now have a web server. These embedded web servers are often susceptible to general attacks against web services.
Attacks will not scale to another device
The embedded systems space has a large percentage of designs based on a few leading RTOSes or Linux. As a result, the argument that an embedded device is secure from Internet-based attacks because it uses an obscure, difficult to understand (and therefore difficult to attack) RTOS is no longer valid.
Attacks built for Linux based systems in the enterprise area are likely to be effective against Linux-based embedded systems. Attacks that are constructed against an RTOS are also likely to be successful against many different designs built using that RTOS. Attacks against web services can be used on any embedded device with a web server.
A special-purpose design
Embedded designs are becoming increasingly complex and the argument for security by simplicity is frequently no longer valid. There are often services provided by the OS that developers' are not aware of. Many systems are designed by large teams where no one person has a complete view of everything happening on the system. Future releases of the design may include additional features not envisioned by the original team and some embedded designs, such as a cell phone or set top box, are now a platform on which applications developed by third parties can run. In these cases the engineer has little or no control over the possible uses of the device.
Attacks are not on embedded devices
Many attacks are now script-based and will attack IP addresses indiscriminately. These will attack embedded systems just as happily as they will a PC or enterprise. Attacks have been launched that specifically targeted embedded devices.
My system will just reboot
While this may be true in some instances, embedded devices now handle critical tasks in all fields. Even if this statement is true today, it is short sighted. Many embedded designs are reused as the basis of future systems with greater capabilities.
I encrypt communication and use logins
While these steps are critical, they do not protect against attacks on the OS or those directed against the embedded CPU. This is the equivalent of having a secure phone line into your house and a lock on the front door, but leaving the windows and the back door wide open.
Fig. 1: Attacks can come from anywhere.
My device is on a private network
Many attacks originate from within a network. This can be the result of the network being compromised by a laptop with a Trojan or other infection and you have to consider an inside attack by someone who is authorized to access the network. If the device is not connected to the Internet today, it may be next month, or next year. It is difficult to predict how a device will be deployed in the future or how network configurations will change.
There are examples of hackers successfully breaching SCADA systems, pacemakers, insulin pumps, train control systems, the emergency broadcast system of several television stations, and a host of other examples. The evidence is clear: Embedded devices need a much higher level of security than has traditionally been provided.
Implementing endpoint security
There are three key elements that an endpoint security solution must provide: protection, situational awareness, and management systems integration. Products are available that provide a solution designed specifically for RTOS-based systems. Icon Labs Floodgate Defender is an example of such a product.
Fig 2: Floodgate Defender provides protection from cyber-attacks along with situational awareness and integration with security management and SIEM systems.
A solution such as this incorporates protection of the device itself along with management and situational awareness. The security agent provides integration with security management and Security Information and Event Manager systems. Situational awareness is key, as it allows for visibility of device attributes and status. This visibility has long been a cornerstone of endpoint security in desktop systems, but has been sorely lacking in embedded devices.
Learn more about Icon Labs