IDC is predicting that 15 billion intelligent devices will be connected to the Internet by 2015. This explosion in connected embedded devices has spawned a new generation of hackers targeting mobile devices, automobiles, medical equipment, and other systems. Alan discusses what these latest security threats to embedded devices look like and what steps companies should take to protect their devices from attacks launched via the Internet.

ECD: What are some common threats and attacks against connected embedded devices?

GRAU: We are seeing a surge in attacks against embedded devices. Attacks range from simple automated probes to sophisticated attacks targeting specific features of the embedded devices.

IP and Web attacks that have long been used against enterprise networks and Web servers are now being used to attack embedded devices. Hackers have compromised medical devices, reprogrammed printers, and even hacked antitheft and vehicle control systems in cars. The list of possible attacks is limited only by the creativity of hackers.

A few other common threats are dictionary attacks, where hackers attempt to log in and gain control of the embedded device using weak or default passwords, and insider attacks, where disgruntled employees steal passwords and sell them to hackers.

ECD: What steps can designers take to protect their devices from these attacks?

GRAU: Security needs to be considered from the very beginning of the design phase. Engineers must assess the possible attack vectors available to hackers. Each interface provided by the device is a potential attack vector for hackers. Wi-Fi, Ethernet, Bluetooth, serial communication, and even debug ports have been targeted by hackers. Once the risks are determined, engineers can begin designing security measures for the identified risks.

Many embedded devices include security protocols such as Secure Shell (SSH) or Secure Socket Layer (SSL) to ensure secure communication with the device. While that is an important step, it is not sufficient. A firewall is the critical layer of security that is missing in most embedded devices. A firewall allows the creation of policies that define and enforce what communication is allowed with the device. The policies define, at a minimum, with whom the device communicates, which protocols are supported, and which ports are open. An embedded firewall is integrated into the communication stack and blocks packets at the lowest layers of the stack. By enforcing communication policies, many attacks are blocked before a connection is even established.

Consider a Supervisory Control and Data Acquisition (SCADA) controller that incorporates the Icon Labs Floodgate firewall and is configured with communication policies that define a set of trusted senders and block all ports and protocols not used by the device (see Figure 1). If hackers attack the device, they will be blocked because the communication is not originating from a trusted sender. Even if hackers steal passwords from an insider, they will not be able to log in to the device because they are not trusted senders. The firewall will block packets at the IP layer before a log-in is attempted.

ECD: How difficult is it to port security software to an embedded system? What are the impacts on performance and memory size?

GRAU: Most Embedded Systems require security software that is designed for use with the specific requirements of embedded systems in mind. Security systems for Linux or Windows are generally large, slow, and not easily ported. A product like Floodgate that is designed to be small, fast, and portable between Real-Time Operating Systems (RTOSs), on the other hand, can be easily ported between embedded systems. Floodgate has been ported to devices as small as 8-bit MCUs and can be configured to as little as 15 KB of RAM and 15 KB of ROM.

Performance is another reason to use security software designed for embedded systems. These solutions will be faster and use fewer memory resources than desktop solutions.

ECD: If embedded devices are to be deployed on a closed network, should designers consider security?

GRAU: Security needs to be designed into all embedded devices, regardless of how they will be deployed initially. Many devices originally designed for use on closed systems are later repurposed, and subsequently may be deployed on open networks. For example, many legacy SCADA systems were designed without security because they were built solely for use on closed networks. Today, many of these devices are connected to the Internet and have few, if any, security features to protect them from hackers. The result is scary; embedded devices are serving critical functions in our infrastructure and remain easy targets for hackers.

Stuxnet showed us that closed networks can still be compromised. Hackers can penetrate the network, or, as with Stuxnet, viruses, worms, and other attacks can be introduced through USB drives and other physical media. In addition, there is always the risk of insider attacks. Someone with authorized access to the network could launch an attack against devices on the network.

Enterprise networks are designed using multiple layers of security. Network firewalls protect against attacks from the Internet, security protocols protect communication, and endpoint firewalls and antivirus/antimalware software protect individual nodes on the network. Embedded devices need to follow a similar approach, adding a firewall to the device to provide an extra layer of protection, regardless of how the device will be deployed at the outset.

ECD: Are the built-in security provisions in OSs such as Android  adequate for embedded applications?

GRAU: As we all know, Android runs on the Linux OS. However, many people are surprised to learn that in various Android distributions, some Linux security features have been stripped out to reduce memory usage. For example, support for packet filtering using iptables is not included in many Android distributions, meaning that firewall support is not included. So Android may not be as secure as many people believe it to be.

Security is about risk management. Hackers will break into a device or network for many reasons. Some are politically or financially motivated. Others just want to prove they can do it. The number and sophistication of attacks continue to rise. Any device with a network interface, even a device on a private network, is a potential target for attack. If the device has a Wi-Fi interface or is connected to the Internet, it almost certainly will be attacked. Devices with a Web interface will likely be targeted by automated Web hacking tools. Reports estimate that between 20 to 30 percent of all Web traffic is from hackers or other malicious packets.

refer:

http://embedded-computing.com/articles/the-president-cofounder-icon-labs/