A Guide to Security Requirements for Specific Types of IoT Devices and Systems.

Simplifying Security for IoT Device Engineers and Manufacturers

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.

Protection type

Class 1 device

Class 2 device

Class  3/4 devices

Embedded Firewall

(Floodgate Firewall)

Resource dependent

Yes

Yes

Intrusion Detection

(Floodgate IDS)

Resource dependent

Resource dependent

Yes

Application data protection/encryption

(Floodgate Crypto/Auth)

Resource dependent

Yes

Yes

Security protocols

(Floodgate Agent)

No

Yes

Yes

Security event reporting

(Floodgate Agent)

Yes

Yes

Yes

Security Policy Management

(Floodgate Agent)

Resource dependent

Yes

Yes

Secure boot

(Floodgate Secure Boot)

No

Resource dependent

Yes

Secure firmware updates

(Floodgate Secure Boot)

No

Resource dependent

Yes

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 market place 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.  

 

 

About 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.

 

About Icon Laboratories, Inc.
Icon Labs, a 2014 Gartner “Cool Vendor” and 2015 Gartner “Select Vendor”, is a leading provider of security solutions for IoT and embedded devices, including the award-winning Floodgate Defender and Floodgate Security Framework. Founded in 1992, Icon Labs is headquartered in West Des Moines, Iowa. For more information, visit www.iconlabs.com.

 

Comments (0)

This post does not have any comments. Be the first to leave a comment below.


Post A Comment

You must be logged in before you can post a comment. Login now.

Featured Product

BDA-1 External DAC from Bryston - The Absolute Sound Golden Ear award winner

BDA-1 External DAC from Bryston - The Absolute Sound Golden Ear award winner

The Bryston BDA-1 is a state-of-the-art external Stereo DAC (digital to analog converter) using fully discrete Class-A proprietary Bryston analog circuits, two independent linear power supplies and dual Crystal CS-4398 DAC chips. The BDA-1 features an impressive array of inputs for USB, COAX, OPTICAL, AES-EBU and BNC equipped digital devices. For audio outputs, the BDA-1 offers both balanced XLR as well as unbalanced RCA stereo connectors on the rear panel.