A Guide to Security Requirements for Specific Types of IoT Devices and Systems
By Dave West, Icon Labs
The idea of providing network security to legacy embedded systems and the latest IoT devices is quickly taking hold in the collective psyche of the marketplace. Unfortunately, there are very few well-tested and complete security solutions from software vendors. Most vendors offer a single component like secure boot or a simple encrypted connection without addressing many other common attack vectors. The lack of product depth among software vendors forces engineers to integrate a confusing array of components from many sources only to find they do not play well together or impose an unwieldy demand on scarce system resources.
Part of the challenge is recognizing every IoT device requires a different approach to security. How do you decide the correct level of security for your device? Fortunately, there is an easy solution. In this white paper, Icon Labs describes scalable software features across classes of devices making selection easier.
We see four device classes with common security concerns.
Class 1 includes very small ZigBee, Bluetooth, and near-field communication (NFC) IoT devices often using 8 and 16 bit MCUs. There are many examples in both the consumer and industrial markets including smart lighting, wearables, and thermostats. Examples in the wider marketplace include remote telemetry (often battery-powered), sensors, and other lower bandwidth sensors and devices.
Class 2 devices are best represented by small, low cost RTOS-based devices utilizing 32 bit MCU systems. These include medical devices, low-end network appliances, and telematics often paired with cellular or WiFi connectivity.
Class 3 devices are exemplified by larger and more expensive medical and industrial automation devices, robotics, and smart automobiles usually powered by 32 bit MPU with Ethernet or WiFi connectivity. As the feature sets and connectivity increase, so does the need to provide security to the varied interfaces.
Class 4 devices run single or multiple 32 or 64 bit processors and utilize embedded Linux, Android, or a full-featured RTOS supporting multiple networking protocols. Gateways, high-end medical devices, and military devices are common examples.
Figure 1
Obviously there is overlap among these, but this model allows some general assessment of security requirements.
Determining the details of security capabilities and features to be implemented for a given device depends upon the available memory, processing power of the core(s), interfaces, attack vectors, threat analysis, and ultimately, business trade-offs.
As we move upward through the classes, the sophistication of those features increases. The firewall capabilities implemented in a Class 1 device are usually a subset of the capabilities implemented in a Class 2 or 3 device.
Other capabilities to be considered include intrusion detection, security management, integration with hardware security features and secure key management/key storage. Figure 2 below illustrates commonly paired device classes and protection.
Figure 2
Class 1 devices are frequently and perhaps frustratingly marked “resource dependent”. Icon Labs’ solutions scale very well to the 8 and 16 bit MCU’s characterizing these devices, but cost limitations may be reflected in the available computing resources required to support security features. In some cases, the device will support some security features, but a trade-off will need to be made between the available security features.
Icon Labs’ Floodgate Firewall provides endpoint protection and includes policy-based filtering by port/protocol/network address. Policy violations are reported as intrusion detection events. It can also perform threshold filtering against Denial of Service attacks. For Class 1 devices, the firewall may be all the protection needed.
Floodgate IDS (intrusion detection) protects firmware and data files, detecting and reporting unauthorized changes to these files. It perform local and remote audits, and logs security events. FIDS is a likely component selection for Class 3-4 devices.
Floodgate Secure Boot establishes a Root of Trust from the hardware to low-level boot code, low-level boot code to operating system, operating system to application and application to execution. At each step in the chain, FSB will halt the sequence if an untrusted component attempts to load or execute. FSB is a likely to be selected in Class 3-4 devices and some Class 2 devices, but limited resources may prevent its use on Class 1 and some Class 2 hardware.
Floodgate Agent supports policy management and event reporting by passing event reports and logs to the management system and accepting policy updates from a management system. In this role, it can also perform complete command audit logging. FA passes policy management requests to the Firewall and provides situational awareness and device attestation capabilities. FA scales well with device classes 1-4.
The Floodgate Agent supports three different policy management systems including McAfee’s ePolicy Orchestrator. For those with simpler management requirements and smaller budgets, Icon Labs offers a cloud-based system, the Floodgate Security Manager. For the ultimate in lightweight management, a local web management interface can be used.
The need for security is clear. Today the marketplace and the government are beginning to demand security in IoT devices. There is a clear available solution that can be applied across the spectrum of devices with differing capabilities. It is advantageous for a company to have a consistent approach to security no matter the class of device. Using this class structure allows a view of security that is rational and easily implemented.
Icon Labs (iconlabs.com) is perhaps the only vendor offering a scalable product line of security solutions to address embedded systems ranging from low-energy 8 bit processors to gateway and high-end endpoint devices.
Author Bio: Dave West
David West is Icon Lab’s Director of Professional Services overseeing development and customization on strategic projects. Dave has 34 years background in securing real time operating systems and embedded development.
