What’s the Difference Between Device Hardening and Security Appliances?
Attacks on Internet of Things (IoT) systems continue to make headlines. All devices on publicly accessible networks are being targeted. While the use of IoT devices is increasing at an unprecedented rate, security for these vulnerable devices is painfully and unnecessarily lagging behind. After great financial expense from DDOS attacks and identify and data theft, awareness of the problem is finally growing. Studies utilizing ICS system honeypots have shown internet-connected ICS devices have been attacked within 24 hours of connection to the internet. In our discussions with customers, we commonly hear reports of newly provisioned IoT gateways being probed within 45 minutes.
Industry groups are developing standards, requiring certifications, and pushing legislations. Yet with the excitement to get new devices, software, and services into production, manufacturers continue to deliver products loaded with the security equivalent of a wing and a prayer.
Companies building IoT and other connected devices must ensure their devices are protected from these attacks. But where do they start? What steps can the device developers and manufacturers take to ensure their devices are protected?
Companies deploying IoT solutions and building IoT networks must make certain their networks are protected. Again, where do they start? What steps are needed and what solutions should they deploy? Can they rely on having strong security built into the devices they deploy? Or must they assume all endpoints have limited built-in security, and integrate them into a network relying upon using security appliances for protection?
Each approach has supporters, but there are tradeoffs between the “device-centric” and “appliance-centric” approaches to IoT cyber security.
Building Security into the Device
One approach to IoT security is to build protection directly into the device. This provides a critical security layer—the devices are no longer dependent on the corporate firewall as their sole protection. This is especially critical for mobile devices and IoT endpoints deployed in remote locations.
A security solution for IoT devices must provide protection against a wide range of cyber attacks. It must ensure the device firmware has not been tampered with, be able to secure the data stored by the device, secure in and outbound communications, and it must detect and report attempted cyber attacks. This can only be achieved by including security in the early stages of design.
While there is no one-size-fits-all security solution for embedded devices, solutions are available that provide a framework for OEMs. A security framework provides OEMs with the core capabilities required to protect their devices and the flexibility needed to customize the solution to the specific requirements of their device, while ensuring that critical security capabilities are included.
Security Framework for IoT Devices
Device Security Requirements
Before selecting an IoT security framework, it is important to step back and look at the requirements at both device and system levels. 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.
Security capabilities needing consideration are:
- Secure boot
- Secure firmware updates
- Secure communication
- Data at-rest protection
- Embedded firewall and intrusion detection
- Key and certificate management
- Authentication
- Integration with security management systems
- Security policy management
Security Event Reporting
A security framework, such as the Floodgate Security Framework, provides an integrated suite of security building blocks (below).
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, support for secure communication has been added to many embedded devices. While these protocols provide a first level of defense against protocol-based cyber attacks, they leave other 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 providing 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 not supporting TLS or IPSec. For 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 ensure an IoT device is running authorized code from the device manufacturer preventing the installation of malware or code 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 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 may be stored in reprogrammable flash memory, repeats the process, verifying 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 new code images that 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 such a device should be encrypted, ensuring 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.
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 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 ensuring 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 repeats with hackers gradually expanding their reach within the network. Stopping the attacks begins with early detection. 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 providing 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 easy targets for hackers.
PKI and Certificate-Based Authentication
A well-known and tested security solution has recently seen a dramatic rebirth in the IoT recently. PKI (Public Key Infrastructure) is a set of technologies and services for managing authentication of computer systems. PKI certificates are very useful in high-security situations. For example, suppose that you needed to securely transmit data between two networked devices. How do you really know you are transmitting the data to the intended device and not to an imposter? One way of ensuring the integrity of the transaction is to use digital certificates to prove the identities of both machines. Without getting into the details of the public/private key cryptography technology that makes this possible, an IIoT device can verify the certificate holder is the entity specified by the certificate. These services are enabled using public/private key cryptography providing the technical underpinnings of PKI. The result, which is what really matters, is a device can verify, with cryptographic certainty, the holder of the PKI certificate is really who it claims to be and not an imposter.
Cryptography and Secure Key Storage
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 providing secure key storage, protected memory regions, and cryptographic acceleration. A security framework must be designed to allow easy integration with hardware-based security features.
Likely candidates for hardware security module support include PUF (Physically Unclonable Functions), security coprocessors such as TPMs (Trusted Platform Modules), and Trusted Execution Environments such as ARM’s TrustZone.
PUF uses random patterns in the silicon to differentiate chips from each other and creates a unique random number. The generated random number is used to seed a strong device ID and cryptographic keys creating a hardware root of trust.
Security co-processors are physically separate chips offering true isolation of private keys. A TPM is an industry-standards-based securing chip that offers isolation and facilities for the secure generation of cryptographic keys, and limitation of their use, and true random-number generation. It also includes capabilities such as remote attestation and sealed storage. Its capabilities come at a price, usually moving deployment to higher-end IoT devices.
A hardware security module (HSM) is another physically separate chip and likely at a lower cost than a TPM. Like the TPM, it safeguards and manages digital keys for strong authentication and provides crypto processing. An HSM traditionally comes in the form of a plug-in card or an external device attaching to the protected device, making it somewhat less suited to an IoT device. Depending upon the perceived and likely threat vectors, an HSM may provide an effective solution.
Trust Zone is a single-chip solution segregating execution space into secure and insecure worlds. Insecure apps can’t access security-critical assets. Those same security critical assets are isolated from tampering.
IoT Security: The Security Appliance Approach
Security appliances also play a central role in protecting IoT networks from cyber attacks. IoT network architectures are diverse and include a range of devices and computing resources. Not surprisingly, there are equally diverse sets of security appliances for IoT networks. Most of these approaches fall into three main categories, protecting the network and cloud, IoT-specific intrusion detection, and protecting legacy devices.
Network and cloud protection
As with traditional IT networks, security appliances provide a critical layer of defense at the network perimeter and for the data center. The frequency and sophistication of cyber attacks targeting data centers and cloud-based computing resources continues to increase and many new IoT services and connections open up fresh attack vectors for hackers targeting these systems. Network security appliances must not only be deployed to protect these devices, but must also be constantly updated to secure new IoT protocols and services.
Intrusion Detection Systems (IDS) for IoT networks
The deployment of new protocols and services to meet IoT requirements results in new attack vectors hackers can exploit. Companies are developing new network IDS solutions to detect attacks against newer services and protocols.
In some cases, existing network IDS solutions can be enhanced to detect new attacks. These solutions work well for detecting attacks occurring at the network edge or data center, where existing network IDS solutions are deployed.
For mobile or remotely deployed IoT devices, however, these solutions add little value. New types of IDS solutions are required to detect attacks targeting remote IoT endpoints.
There are several challenges to detecting attacks targeting IoT endpoints in the field. The IDS appliance itself must be designed to operate in the same location as the IoT endpoints. In many cases, this requires physical hardening of the device, allowing operation in harsh environments.
The IDS appliance must detect new attacks, many of which are emerging or will emerge in the coming years. They must also support IoT new protocols. Any appliance designed today must be flexible enough to provide protection against new attacks as they emerge.
Finally, economic factors must be taken into considerations. The physical footprint of an IoT network may require deployment of a large number of IDS appliances. Unfortunately, the cost model of many solutions makes them prohibitive for this model.
Protecting legacy devices
Many legacy devices and systems are being connected to the IoT through gateways and proxy services, or using existing network connectivity. Most were manufactured with inadequate security.
Unfortunately, the upgrade process may be difficult, expensive, or impossible. Some devices cannot be upgraded without being returned to the factory. In some cases, the manufacturer may no longer support the device, or may be out of business. Replacing the devices is often simply too expensive to be an option and newer devices may not yet be available with improved security.
For devices and systems that cannot be easily or affordably replaced or upgraded, a “bump-in-the-wire” appliance solution can provide the required security. This type of solution can protect legacy devices that are otherwise vulnerable. The bump-in-the-wire appliance provides security by enforcing communication policies, ensuring only valid communication is allowed with the protected device.
The security appliance must provide the ability to configure communication policies, a set of rules specifying which packets are processed and which are blocked. Smart-grid devices may only need to communicate with a small number of other devices. This can be enforced using communications polices that restrict communication to only what is required. Communication policies define who the device is allowed to talk to, what protocols are allowed, and what ports are open. The policies are then encoded as firewall rules. Rules can be set up to block or allow packets by IP address, port, protocol, or other criteria. Some firewalls support advanced rules allowing additional fine-grained control over the filtering process. The security appliance then filters messages before the device processes the messages, allowing only communication with known, trusted devices.
In a system without a security appliance, a hacker may attempt to remotely access the device using default passwords, dictionary attacks, or stolen passwords. Such attacks are often automated, allowing a huge number of attempts to break the system’s password. The same system can be protected by a firewall configured with a whitelist of trusted hosts. The firewall’s filters will block attacks from the hacker before a login is even attempted because the IP or MAC address is not in the whitelist, thereby blocking the attack before it even really begins.
Rules-based filtering is used to enforce communication policies, blocking packets from non-trusted senders and isolating devices from attack.
Many attacks are blocked before a connection is even established because each packet received by the devices must pass through the firewall for filtering before being processed. This provides a simple, yet effective layer of protection currently missing from most legacy IoT devices.
Security Appliance Approach vs. Device Hardening
Two important tradeoffs in considering the hardware versus software approach to IoT security are economic consideration and the protections that can be built into low-cost sensors.
As IoT devices proliferate, the number of required security appliances could explode. The economics of adding security appliances to every IoT device are simply prohibitive.
While this can be addressed with software security built directly into the device itself, this is not without cost of its own. Security software requires additional memory and processing power, and imposes additional overhead on network resources which can dramatically impact battery life for lower power devices. As a result, you are limited in how much security can be added to low end devices such as sensors.
Summary
One of the unique challenges of the IoT is that the network perimeter is often blurry. Network security appliances can protect cloud-based computing resources and any IoT devices that happen to reside within the network perimeter, but do little to protect mobile devices or IoT endpoints located in the field. So while security appliances play a critical role in protecting the IoT, they do not provide the complete solution.
Ultimately, some combination of hardware and software will be required, but building software into IoT devices is a critical missing piece that must be addressed.
