Security firm Sucuri warned back in June how compromised CCTV devices were used in multiple denial-of-service (DDoS) attacks every day. In the report, nearly 25,000 compromised devices from all over the world were used in various attacks on small businesses.
Many of the devices came from multiple vendors and had RCE vulnerabilities and were turned into botnets, but this was only a forecast of much more ominous things to come.
The Sucuri report was soon followed by numerous other reports to include the IoT-based DDoS attacks on Brian Krebs’ website and later the DNS provider Dyn attack that impacted multiple major websites.
In the wake of all the IoT security warnings, the Cloud Security Alliance (CSA) IoT Working Group issued a report titled “Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products.”
In this article, we highlight some key points from the CSA report. In particular, we have included guidelines on how to better secure communications, applications and APIs to enhance security of IoT products.
This is the fourth in a five part series that emphasizes IoT security and best practices many businesses can use to improve their security program as well.
Protecting data with secure communications
IoT developers must select secure communication protocols to include short range (e.g., devices with limited battery life) and also long range (such as internet connectivity).
One of the key considerations for any protocol is the pairing process of how devices connect to an existing network. Avoid the “just works” option that can be used for convenience but will add security concerns (e.g., rogue devices could join home or business networks).
A better example of a secure pairing process is Bluetooth-LE (“Low Energy” version 4 of specification) that also adds Elliptic Curve Diffie-Hellman (ECDH) for key exchange during pairing process and uses 128 bit symmetric key for confidentiality. Bluetooth has also added new privacy enhancements to support the rotation of MAC addresses instead of static MAC addresses.
Bluetooth version 4.2 was released on December 2, 2014 and version 5 was released on June 16th, 2016 with new products scheduled to ship in late 2016 or early 2017.
Other secure protocols include, but not limited to:
- Wave 1609 (used often in connected vehicle communications)
- ZWave (frame encryption keys and data origin authentication keys)
- ZigBee (provided network and MAC layer and support for Star, Tree and Mesh topologies)
- CDMA (cellular technology)
- LTE (an Authentication and Key Agreement (AKA) procedure used for authentication between an IoT device and core network)
Secure applications and services
Each integration point for an IoT device or connected infrastructure is a potential pathway that can be used by an attacker for unauthorized access to data or critical control systems. Smartphone or mobile apps are often used to configure and manage IoT devices.
Developers should use certificate pinning to prevent man-in-the-middle (MitM) attacks that could occur when devices communicate with untrusted networks.
Also, limit privileges afforded mobile apps. See the CSA Mobile Application Security Testing (MAST) and also NIST SP 800-163 Vetting the Security of Mobile Applications, for good guidance on mobile app security.
Protect logical interfaces/APIs
An application programming interface (API) can expose service providers to DoS attacks. APIs often allow IoT devices to directly connect to cloud IoT gateways, such as AWS IoT service. Microsoft also offers an Azure IoT Hub Resource Provider REST API and also messaging API for sending REST messages.
To fight such attacks that target APIs, consider these good CSA guidelines:
- Implement rate-limiting to guard against compromised IoT products
- Gateways: check for proper format of messages and verify allowed data types that can be passed (attackers can insert malicious code into API communications)
- Error handling: don’t provide detailed responses
- Guard against replay attacks
- Don’t reply on just API keys for security (e.g., implement more robust authorization and authentication controls and limit API key exposure)
- Encrypt API communications (use TLS, DTLS and cert pinning)
- Don’t ever store passwords in connection strings
- Consider other software agents used externally (e.g., used for monitoring) and ensure trusted connections
- Understand and secure what other devices IoT will connect to.
See OWASP’s REST Security Cheat Sheet for additional guidance on secure use of REST in IoT products.
Certificate pinning allows the developer to embed the certificate or public key in the application/firmware itself. This process will help protect IoT device communications and help prevent attacks where IoT could be configured to connect to a malicious server/proxy (e.g., Man-in-the-Middle attacks).
Secure update capability
The final control in this article is the need for secure update capability for IoT devices. Insufficient security of firmware allows a cyber criminal to modify firmware and upload malicious code to the IoT device or lead to the disablement of security controls or even exfiltration of data.
CSA adds the following recommendations:
- Automate the IoT product update process, as many users often fail to update devices in a timely manner
- Ensure authentication of update process end-to-end (e.g., secure storage for root of trust, used to validate signature applied to firmware with infrastructure)
- Ensure keys used to sign firmware are secure (e.g., via an HSM)
- Ensure update servers are security configured and hardened
- Use FIPS 140-2 approved crypto algorithms used for digital signatures
- Write-protect IoT product from unauthorized firmware
- Scrub software updates for vulnerabilities.
Consider the update framework (TUF) that helps IoT developers in securing new/existing software update systems, often found to be vulnerable to many known IoT attacks.
For more on IoT security, see the next part 5 (in our 5-part series), “Secure Authorization, Authentication and Access Control for IoT.”
You can also read more in our previous article titled “Hardware-based Security Controls for IoT” (part 3) where we focused on CSA best practices for hardware-based security to include specialized security chips, crypto modules, physical protections and supply chain security. See also “Secure Development and Integration” (part 1) and Framework and Platform IoT security (part 2).