Buy vs. Build: the great Security Framework Debate | Automation.com

Buy vs. Build: the great Security Framework Debate

Buy vs. Build: the great Security Framework Debate

Security solutions for embedded devices are where RTOSes were in the 1980s.  A few commercial solutions have started to appear on the market and customers are left with the choice of rolling their own solution or adopting a commercial solution. 

Early on, many companies created their own RTOS.  Over time, this gradually changed with commercial RTOSes becoming an increasingly larger percentage of the market.  Eventually, quality open-source solutions became available, providing yet another option for developers.

The reasons for choosing a commercial RTOS over a roll-your-own solution are clear.  With a commercial solution each customer benefits from the economies of scale and the broad commercial deployment of the product.  These result in a product with more capabilities, fewer defects, better documentation and better portability. 

It took at least a decade for the benefits of commercial RTOSes to be widely accepted and for roll-your own solutions to become a rarity. 

Today, many companies are faced with the same decision and making the same choice. They are rolling their own security solution rather than selecting a commercial solution.  In doing so, they are creating a future with multiple, incompatible solutions, large internal support burdens and no economies of scale.  

Companies don’t have to go down this road.  Commercial solutions, such as Icon Labs’ Floodgate Security framework, provide OEMs with the core capabilities required for securing there devices. A well designed framework provides OEMs with the flexibility needed to customize the solution to the specific requirements of their device, while ensuring critical security capabilities are included.

Device Security Requirements

We can no longer rely on the secure perimeter model for protecting IoT devices. Rather, security must be built into the device itself.  Security requirements for IoT devices must take into consideration the cost of a security failure (economic, environmental, social, etc.), the likelihood of attack, possible attack vectors, and the cost of implementing a security solution.

If your device is on a publicly accessible network, being attack is a virtual certainty.   Studies utilizing ICS system honeypots have shown that Internet connected ICS devices are attacked within 24 hours of first being attached to the network.  In our discussion with customers, we commonly hear reports of newly provisioned IoT gateways being probed within 45 minutes of being connected to the Internet.

Security capabilities that need to be considered are:

·         Secure boot & secure firmware updates

·         Secure communication

·         Data at rest protection

·         Embedded firewall & intrusion detection

·         Key and certificate management

·         Authentication

·         Integration with security management systems

o   Security policy management

o   Security event reporting

A security framework, such as the Floodgate Security Framework, provides an integrated suite of security building blocks.

Secure Communication

When most engineers think of security, they typically think of secure communication protocols such as SSL/TLS, SSH, and IPSec. In recent years, many embedded devices have added support for secure communication.  While these protocols provide a first level of defense against cyber-attacks, they leave a number of attack vectors unprotected.

Security protocols are designed to protect against packet sniffing, man-in-the-middle attacks, replay attacks and unauthorized attempts to communicate with the device.  This provides a good starting point for building secure devices. 

Small IoT edge devices are adopting wireless protocols such as ZigBee, Bluetooth Low Energy (BLE) and other wireless and mesh networking protocols. These protocols have some built in security. However, it is relatively weak and exploits have been published.  Small IoT devices typically run on very low cost, lower power processors that don’t support the TLS or IPSec.  For these small edge devices, DTLS, which is TLS over UDP, can be used for secure communication. 

Secure Boot and Secure Firmware Updates

Secure boot and secure firmware update capabilities are used to ensure that an IoT device is running authorized code from the device manufacturer.  This prevents the installation of malware or code that has been modified by hackers.

Secure boot ensures that hackers are unable to install malicious code on an IoT device

Secure boot begins with a first stage bootloader that is programmed into a protected or non-writable storage location on the device. This first stage boot loader validates the authenticity of the second stage boot loader.  The second stage boot loader, which can be more complex and which can be stored in reprogrammable flash memory, then repeats this process to verify that the operating system and applications are valid. 

Secure boot relies on signed code images to enable validation of the image during the secure boot process.  The code images are signed by the device OEM using the OEM’s private key.  The OEM’s corresponding public key is used by the device to validate the signature for the firmware image. 

Secure firmware update, like secure boot, validates that new code images have been signed by the OEM during the upgrade process.  If downloaded images are not valid, they are discarded and the upgrade is not performed.  Only valid images are accepted and saved to the device. 

Data at Rest (DAR) Protection

IoT devices, unlike enterprise servers, are not locked away deep in a data center. Many are located “in the field” with the risk of theft or physical attack.  Any sensitive data stored on these devices should be encrypted to ensure it is protected from attempts to read from the device, either by copying the data from the device, or by physically removing the flash drive and reading data directly from the flash drive.

Data at Rest (DAR) protection encrypts data stored on the device, providing protection against these attacks.  Many IoT devices don’t have the computing power to support full disk encryption, but sensitive data such as credit card numbers or patient information should always be encrypted.  Care must be taken to store the encryption key in protected memory on the device or in a secure location such as a USB drive or network server.

The DAR solution should ensure that unencrypted data is never stored on the hard drive.  Protected data should be encrypted before it is written to a file. Encrypted files should be encrypted in memory and remain in RAM, never written back to the file system without being encrypted to ensures data cannot be leaked due to a power failure.

Intrusion Detection

Many embedded devices lack basic security features, making them easy targets for hackers.  As a result, hackers have specifically target embedded devices.  Devices such as point of sale systems, HVAC systems and medical devices have been exploited.

Most cyber-attacks occur in phases, beginning with hackers probing a network looking for, finding and exploiting a vulnerable device. Once this initial beachhead is established, hackers use the exploited device to probe deeper into network.  The cycle then repeats with hackers gradually expanding their reach within the network.  Stopping these attacks begins with detecting that they are happening.  Intrusion Detection Systems and Intrusion Detection Software (IDS) are commonplace in enterprise networks and PCs. IDS, as the name implies, detects when a system is under attack or being probed.  These solutions can take many forms and detect many different types of attacks, but regardless of form, are in the main, largely absent for embedded devices.

Adding IDS capabilities to embedded devices is critical to provide early warning of a cyber-attack. The ability to detect and report potentially malicious activity enables system administrators to take action to block attacks, quarantine compromised systems, and protect their networks. If embedded devices can support basic IDS they will no longer be such easy targets for hackers.

Foundational security capabilities

Secure communication protocols, data at rest protection, secure boot and secure firmware updates all rely on encryption and certificate based authentication.  A security framework must provide support for the cryptographic algorithms used by these features.  It must also provide the ability to securely store the encryption keys and certificates used to encrypt data, authenticate firmware and to support machine to machine authentication. Secure key and certificate storage is a critical requirement. If a hacker can discover the encryption keys, they can completely bypass an otherwise robust security solution.   

Hardware Security Module support

Many new IoT platforms include a hardware security module that provides secure key storage, protected memory regions and crypto acceleration.  A security framework must be designed to allow easy integration with these hardware-based security features.

Summary      

Securing IoT devices is a complex task.  OEMs can reduce development cost and time to market by utilizing a security framework that provides key security features.  The cost, time and complexity of developing a solution from scratch, or of integrating disparate open source solutions, far outweighs the cost of using a commercial solution.

Using a commercial security framework can help make your things secure and help create the Internet of SecureThings.

Alan Grau is the President and cofounder of Icon Labs, a leading provider of security solutions for embedded devices.  You can reach him at [email protected]

MORE ARTICLES

VIEW ALL

RELATED