Embedded control systems manage our cars, automate our factories, and maintain the power grid. Yet many developers don’t include a firewall to protect against cyber-attacks, believing their devices are somehow immune and don’t need one. Everyone knows their personal computer needs a firewall, but many Web-connected devices have little or no protection.

While password authentication and encryption afford some defense, both allow attacks to proceed. An efficient firewall designed for the Internet of Things (IoT) stops an attack before it can begin. Embedded engineers should employ a multi-layered security strategy that combines a firewall, authentication, and encryption protocols.

Download this article in .PDF format
This file type includes high resolution graphics and schematics.

Password authentication and encryption from security protocols such as SSH and SSL have long been the staple of embedded security. Authentication and encryption provide secure access and communication, but they are not enough. Systems may be deployed with weak or default passwords, passwords can be stolen, and encryption algorithms can be broken. Moreover, these methods do not block a hacker’s access attempts, allowing brute force attacks that may eventually discover vulnerability.

The Embedded Firewall

A firewall provides the missing layer of security for embedded devices, blocking attacks that authentication and encryption can’t. The firewall must be efficient, consuming minimal system resources and scaling to a wide range of devices, from small 8-bit systems running a minimal or no operating system to a sophisticated multi-core system running a commercial real-time operating system (RTOS). Desktop firewalls don’t meet the needs of embedded devices. Windows and Linux-based firewalls, while effective, are large and aren’t easily portable to small embedded devices. They also include filtering that isn’t relevant for embedded devices.

Most recent embedded systems include a network interface. Some provide password protection or encrypted protocols such as SSH or SSL, but they aren’t enough. If they were, we wouldn’t be reading about security breaches in the popular media. Older systems are even more vulnerable. Their original designers often assumed they were part of a closed “safe” network and omitted security, but many are now connected to a more open network with no protection at all.

These devices need a resource-friendly security solution specifically designed to provide sensible defensive capabilities against a variety of Internet-based attacks. Embedded firewalls provide an ideal solution. The firewall is integrated directly into the communication stack at the link layer of the supported protocol and configured with a set of rules specifying what communication is allowed.

For TCP/IP, those rules can be set to block packets by IP address, port, protocol, and other criteria. The embedded firewall provides a basic but critical level of security by controlling what packets or messages are processed. Because each packet or message received is filtered before passing from the protocol stack to the application, many attacks are blocked before a connection is even established and they can even begin. The result is an effective layer of protection with minimal impact on system resources.

Well-defined communication requirements allow the creation of restrictive firewall policies. The firewall enforces its policies by filtering packets as they are received, comparing each packet to the policies for that device, and blocking all packets that don’t match the communication policy criteria.

By only allowing packets that meet communication policies, cyber-attacks are blocked. Hackers attempting to access the device are blocked because their IP addresses are unauthorized. Denial of service (DoS) attacks and many other cyber-attacks are also blocked because they use ports or protocols disallowed by the firewall or because they originate from an IP address not allowed by the policies. When combined with password authentication, the embedded firewall creates an effective, resource-friendly defense against cyber-attacks. Many attacks are blocked before the hacker can even attempt to log in or access the system.

Filtering Engine

The firewall filters packets as they are received, blocking unwanted packets, unfriendly login attempts, and DoS attacks before authentication is allowed to begin. The filtering engine implements one or more methods to enforce firewall policies and block Internet-based attacks:

• Rules-based filtering: Each packet is compared to a set of static rules determining if the packet is blocked or allowed (Fig. 1). All decisions are made based on the information in the packet. Rules-based filtering enforces policies by blocking unused protocols, closing unused ports, and enforcing IP address whitelists and blacklists. Some devices only require rules-based filtering. Others need more advanced filtering.

1. By enforcing firewall policies, packets from non-trusted senders are dropped, blocking cyber-attacks.

• Stateful packet inspection (SPI): Information regarding the state of each connection is maintained and used to make filtering decisions. SPI guards against packets received with invalid TCP state information, a common Web-based attack. SPI can also be used to create a “lockdown mode” where all connections must originate from the embedded device.

Download this article in .PDF format
This file type includes high resolution graphics and schematics.

• Threshold-based filtering: Statistics on received packets are maintained and threshold crossings are monitored to detect packet flood DoS attacks. Threshold-based filtering is complex and may require more system processing time and memory than some 8-bit MCUs can handle, but it provides a powerful tool for detecting packet flood DoS attacks.

Firewalls provide the framework to implement security on Internet-connected embedded devices (Fig. 2).

2. Callback routines isolate the filtering engine, making the firewall easier to integrate with the TCP/IP stack and to port between embedded operating systems. 

They depend on properly defined policies allowing required communication and blocking all other communication. Defining the embedded device’s communication requirements is the first step:

• With what other systems will the device communicate?

• What communication services are provided for these systems?

• Can the other devices be grouped into sets of users that require the same services?

Once the communication requirements are specified, they are coded as a set of rules. The rules specify the IP addresses, ports, and protocols used by the device to communicate with other network nodes.

The communication requirements are very well defined and restricted for some devices. Other devices require broader communication capabilities, resulting in broader but not necessarily less secure firewall rules.

Security In Action

Consider an embedded sensing and control device logging information and performing a control function. Such a device might be found on a factory floor or as part of the electrical grid. The device would provide communication protocols supporting three different user groups (administrative, control nodes, and data readers).

A Web interface lets administrative users view collected information and make configuration updates to the device. A machine-to-machine interface over UDP/IP enables other devices to collect data from the device and control output and switching levels (Table 1).

Other types of devices will have very different communication requirements and different policies. A printer would typically accept print jobs from any user while accepting firmware and configuration updates from only a small number of administrative users (Table 2).

The communication policies defined for the device need to be encoded as firewall rules. The policies define each user group in terms of the IP address for the group and define the protocols and ports allowable for each group. For the example Smart Grid control and reporting device above, the rule set would look like this:

RULE 1: Administrative users supporting HTTP over TCP  

IP = {201.87.53.20 – 201.87.53.30}, protocol/port = {6, 80}

RULE 2: Control users supporting a private port over UDP

IP = {201.87.54.0 – 201.87.54.255}, protocol/port = {17, 1170}

RULE 3: Data readers, supporting a private port over UDP

IP = {201.87.53.0 – 201.87.54.255}, protocol/port = {17, 1171}

The rule set for the printer would look like this:

RULE 1: Administrative users supporting HTTP and a private port for firmware upgrades over TCP

IP = {201.87.53.20 – 201.87.53.30}, protocol/port = {6, 80; 6, 1030}

RULE 2: Printer users. Allows any user to send print jobs over TCP to the printer IP = {ANY}, protocol/port = {6, 35; 6,170; 6,515}

All packets received by the device are passed to the firewall for filtering and compared to the firewall rules. Packets that don’t match the firewall rules are dropped. As a result, attempts to hack into the device are blocked before a connection is even established.

Solving The Security Problem

A firewall provides a simple and effective layer of security for embedded devices. When implementing a firewall, engineers must consider the services provided by the device to determine the appropriate type of filtering. Engineers must also choose between buying a commercial embedded firewall, porting an open source firewall, or building a firewall solution from scratch. Regardless of the approach selected, it is critical to include a firewall to protect the devices making up The Internet of Things.

The Icon Labs Floodgate firewall makes adding an embedded firewall to a wide variety of embedded devices easy and affordable. Floodgate is designed to meet the specific requirements of embedded applications. It provides static filtering, threshold-based filtering, and SPI to protect embedded devices from Internet-based threats. Floodgate also has a small footprint and low CPU processing requirements. And, it is easily integrated with any embedded IP stack.

Alan Grau is president and cofounder of Icon Labs. He also is the architect of Icon Labs’ award-winning Floodgate Firewall. He has 20 years of embedded software experience. Prior to founding Icon Labs he worked for AT&T Bell Labs and Motorola. He has an MS in computer science from Northwestern University.

Download this article in .PDF format
This file type includes high resolution graphics and schematics.