Getting connected and staying secure
When it comes to protecting IoT devices OEMs can no longer rely on obscurity or a secure perimeter model. As Icon Labs explain, security must begin at home with a device capable of defending itself against network attacks.
A message often lost in the noise that has been created around IoT security is that there are solutions, even for the smallest of IoT devices. Network security is like an arms race. Security vendors continue developing better security solutions while black hats continue discovering and exploiting new vulnerabilities. However, the vast majority of security vulnerabilities in IoT devices are the result of manufacturers failing to include even basic security in their products. The various IoT vulnerabilities can be seen in the table below.
IoT - vulnerable from the start?
Before delving into the problem of how to secure IoT devices, it is important to consider the origin of security vulnerabilities, especially as related to embedded devices. Broadly speaking, embedded device vulnerabilities can be divided into one of three categories - implementation vulnerabilities, design vulnerabilities and deployment/use vulnerabilities.
Deployment or use vulnerabilities relate to issues that are introduced by the user during the operation or installation of the device. This would include issues such as not changing default passwords, using weak passwords, not enabling security features etc. While this is a critical topic, we will not address it in this article.
Implementation vulnerabilities occur when coding errors result in a weakness exploited during a cyber attack. The infamous, and seemingly immortal, buffer overflow attacks are the classic example of implementation vulnerabilities. Other examples include improperly seeded random number generators resulting in generation of security keys that are easy to guess. Adherence to software development processes such as the OWASP Secure Software Development Lifecycle or Microsoft’s Security Development Lifecycle and thorough testing processes help address implementation vulnerabilities.
Design vulnerabilities are weaknesses resulting from a failure to include proper security measures when developing a device. Examples of design vulnerabilities resulting in security breaches include use of hard coded passwords, control interfaces with no user authentication, and use of communication protocols that send passwords and other sensitive information in the clear. Less obvious examples include devices without secure boot or that allow unauthenticated remote firmware updates.
Security capabilities
Adding a few basic security capabilities can make IoT devices dramatically more secure and greatly reduce the risk of falling victim to a cyber attack. These capabilities are:
- Secure boot
- Firewall
- Secure remote firmware update
- Secure communication
- Data protection
- User authentication
Secure boot: secure boot utilises cryptographic code signing techniques to ensure the device only executes code that was produced by the device OEM or other trusted party. In a device with secure boot capability, the bootloader computes a cryptographically secure hash on the firmware image prior to loading the image. This hash value is compared with a stored hash value to ensure the image is authentic. Public key signing of the stored hash value prevents malicious third parties from spoofing the software load, ensuring only software from the OEM is allowed to execute.
Firewall: an embedded firewall adds a critical layer of protection for IoT devices blocking attacks. A firewall at the perimeter is not enough because most attacks originate from within the perimeter. The firewall should reject any packet not conforming to rules based on IP address, port or protocol. It should also be capable of logging any event, including events that violate its rules.
Secure firmware update: secure firmware updates ensure that device firmware can be updated, but only with firmware from the device OEM or other trusted party. Like secure boot, cryptographically secure hash validation is used to verify the firmware before it is stored on the device. In addition, machine-to-machine (M2M) authentication methods can be used by the IoT device to authenticate the upgrade server before downloading the new firmware image, adding an additional layer of protection.
Secure communication: utilisation of security protocols such as TLS, DTLS and IPSec adds authentication and data-in-motion protection to IoT devices. Elimination of sending data in the clear makes it much more difficult for hackers to eavesdrop on communications and discover passwords, device configuration or other sensitive information. IoT devices, by definition, will support remote communication with other devices. The communication mechanisms will vary by device, but may include wireless protocols ranging from BLE and ZigBee to WiFi, cellular data and Ethernet.
Regardless of the transport mechanism and communication protocol, it is important to ensure that all communication is secured. TLS or IPSec should be used whenever possible. Application data encryption should be considered for wireless protocols such as ZigBee or BLE that have encryption built into the protocol, but have known vulnerabilities. Whenever possible, older, insecure protocols such as Modbus/TCP should be replaced with newer, secure protocols or encapsulated within secure protocols such as TLS.
Data protection: security protocols provide protection for data while it is being transmitted across networks, but do not protect the data while it is stored on the device. Large data breaches have resulted from data recovered from stolen or discarded equipment. Encryption of all sensitive data stored on the device provides protection should the device be discarded, stolen or accessed by an unauthorised party. Engineers should consider encrypting any sensitive data stored on the device.
User authentication: passwords are still the default solution for user authentication on many devices. If strong passwords are enforced by the device, this is still a reasonable choice. Depending upon the nature of the device and the interfaces available, two-factor, biometric or token-based authentication may be a better choice. No matter the mechanism used, it is critical that users be authenticated before they are allowed to access and control the device. Weak or non-existent user authentication has resulted in several high profile device vulnerabilities including FDA reporting medical devices with hard coded passwords. A strong user authentication method is a clear requirement for device security.
Summary
Security is a requirement for all IoT devices, no matter how small or seemingly insignificant. By adding a few basic capabilities, the security of any device can be significantly increased. Solutions, including Icon Labs Floodgate Security Framework, exist and are tailored for use in very resource limited IoT devices. These solutions are effective in blocking cyber attacks. Strong passwords, basic authentication and ensuring the device is running authentic code go a long way to protect IoT devices from cyber threats.
Icon Labs can offer a scalable product line of security solutions addressing all of the issues for systems ranging from low energy 8-bit processors to gateway and high end endpoint devices.