For device integrity, data protection, and device management, do-it-yourself (DIY) security won't cut it – even if you're a seasoned engineer. Recent IoT device exploits have made that point painfully clear.
More than 5 billion Bluetooth devices were recently discovered to be vulnerable to the BlueBorne malware attack. All hackers need is for the Bluetooth device to be turned on. Hackers can then inject malicious code and, in some cases, can intercept network traffic to and from a Windows PC and modify it at will.
This is not an isolated event. A quick search will turn up dozens of attacks.
As manufacturers leave IoT devices susceptible with default passwords and unnecessary open ports, these can be used as means to attack the entire IoT stack. This is why IoT security attacks are so serious: Perpetrators not only can steal data and shut down services but also inflict damage on equipment and users anywhere in the device-to-cloud stream.
Yes, designers can download some open-source transport and encryption code, and wire it into the application. But that inevitably results in gaps that hackers can find.
While commercial security platforms available today don't completely remove security risk, they certainly reduce it. For optimal security, these solutions must seamlessly integrate into a platform rather than get bolted on as a design is shipping out the door.
IoT Security Versus Traditional Security
There are some key differences between IoT security and more traditional security measures. Traditional security assumes that IT has control over access to devices and data on isolated networks, both of which exist within defined physical environments.
The solutions for protecting these devices and data require considerable compute power on the endpoint, such as antivirus software, firewalls, and intrusion detection/prevention systems (IDS/IPS). If security updates are needed, it's easy to download and install the latest patch on the device.
IoT security, on the other hand, is more like the Wild West. Devices typically live on relatively open networks, often in physically unprotected areas. Compute power is more limited—particularly for battery-powered devices—as is the ability to issue software updates. And the endpoints of IoT systems may have little or no headroom for security software.
IoT security must therefore authenticate edge devices before they communicate, and protect data from the end device all the way to the cloud. And that means security must be baked in before a device ships, and not bolted on once the device is in the field.
Drawbacks of In-House, DIY Security
For a better sense of the enormity of an IoT security undertaking, consider the typical system architecture:
- Device Side: Consists of an IoT device, application program, data, and connectivity to a network switch/gateway
- Network Switch/Gateway: Consists of a network switch/gateway, routing software and other applications, as well as communications to the device side and cloud
- Cloud: Consists of server infrastructure, stored data, native applications, perhaps access to hardware security modules (HSMs), and southbound communications mechanisms to either the network switch/gateway or device
To develop an IoT security solution in-house that addresses each of these areas, design teams must make trade-offs between scope, time, and cost. Components for building such solutions are often borrowed from both internal development and the open-source community, such as SSL/TLS, OpenSSH, OpenVAS, AES, TrueCrypt, and others.
Unfortunately, in many cases these components were developed years before the IoT even existed. They often don't consider that the IoT extends beyond firewalls, and in many cases beyond all walls, as IoT devices hang from utility poles and other structures out in the wild. This creates many unforeseen opportunities for attack (Figure 1).
Cobbling together security solutions for an IoT system that consists of multiple devices, appliances, services, and software packages is not the best choice. For one thing, it can result in a sprawling portfolio of security solutions that lack integration. Each point solution must be individually managed, which increases the burden of engineering support.
Point solutions also have difficultly sharing data with one another, leading to a fragmented view of security and limitations on threat detection. And the added complexity can create friction as new apps and services must be made compatible with an array of specialized technologies, each with its own APIs, policies, and requirements.
The impact on agility and time-to-market can be significant with the wrong security choice. The challenge of creating tightly integrated IoT security solutions is typically measured in work-years, not work-hours.
An Integrated Approach to Security
The Centri IoT Advanced Security (AS) platform is aimed at designers looking to integrate security right from the get-go (Figure 2). The platform allows developers to integrate standards-based encryption and advanced ciphers into their IoT solutions stacks, enabling secure communications from chip to cloud, protections for data-at-rest, and management consoles for data forensics.
Key components of the IoTAS platform include:
- Secure Communications Endpoint: Allows developers to incorporate device-side security in their IoT application using the lightweight Secure Communications library or Proxy client within the device's software stack. It's used in conjunction with the Secure Communications Service to secure data moving to/from the cloud.
- Data Protection Tool: The lightweight Data Protection library can be called from an IoT application using an API to encrypt data before it enters a device or on-premises storage.
- Secure Communications Service: This tool runs on existing application servers to provide security for cloud infrastructure.
In particular, the CENTRI Secure Communications library and Secure Communications Service help facilitate immediate, encrypted single-stage handshakes between IoT devices and cloud infrastructure. This reduces the complexity of complex certificate management schemes and eliminates the need to employ third-party certificate authority (CA) solutions. The system also employs a vault-less key management technology that embeds encrypted key information within data. HSMs or third-party key storage mechanisms therefore are not needed.
Smart caching and data compression techniques help reduce the overhead of security to as little as 1 percent CPU utilization, making the platform suitable for resource-constrained IoT devices. Each component of CENTRI IoTAS is device- and OS-agnostic, allowing experienced developers to integrate these technologies into application code in a single day.
Security: Baking in Versus Bolting On
Where many third-party commercial security solutions provide greater protection than DIY alternatives, they also can add significant cost and management overhead when implemented at later stages of design. A better option is to install the security solution at the endpoint and in the cloud as early as possible. This both reduces risk of device attacks and data breaches, and speeds time to market.
About the Author
Richard Nass’ key responsibilities include setting the direction for all aspects of OpenSystems Media’s Embedded and IoT product portfolios, including websites, E-newsletters, print and digital magazines, and various other digital and print activities, including the recently launched IoT Design website. He was instrumental in developing the company’s online educational portal, Embedded University. Previously, Nass was the Brand Director for UBM’s award-winning Design News property. Prior to that, he led the content team for UBM Canon’s Medical Devices Group, as well all custom properties and events in the U.S., Europe, and Asia. Nass has been in the engineering OEM industry for more than 25 years. In prior stints, he led the Content Team at EE Times, handling the Embedded and Custom groups, and the TechOnline DesignLine network of design engineering websites. Nass holds a BSEE degree from the New Jersey Institute of TechnologyFollow on Twitter More Content by Rich Nass