Six Mistakes to Avoid When Writing Code for the Internet of Things

The coming wave of "Internet of Things" (IoT) products - i.e., the integration of operating systems and Internet connectivity into hardware products like appliances, electronics, sensors, robotics, cars, etc. - promises to be one of the biggest booms in software development in recent memory. While mobile apps are expected to generate $77 billion in revenue by 2017, IoT expectations are considerably higher - Gartner estimates $309 billion annually by 2020, and Cisco has a much more dramatic projection of a $19 trillion market by 2020.

But a key problem we're already seeing with IoT products is that security is clearly an afterthought. At the upcoming Black Hat conference, which kicks of August 2nd in Las Vegas, hackers will be unveiling a number of serious flaws in IoT products, including cars, home automation, thermostats, home alarms, etc. Companies like Intel, Google, Samsung, Microsoft, General Electric, Cisco, AT&T and IBM, which are already taking an active role in Internet of Things development, will soon be placing a greater emphasis on risk-mitigation with these products - and developers who can deliver on security, in addition to performance and UX, are likely to be a step ahead of the competition.

So what are some steps developers should take today to improve their coding for IoT products? Here are the top six security issues to address:

1. Attack Surface - Many IoT developers today don't do a good enough job of limiting the surface area of the devices they create. Allowing access to I/O interfaces or APIs that do not need to be on the network exposes them to remote code execution attacks, which could result in a total takeover of the device. Remote code execution occurs when an attacker can inject data into an accessible I/O interface or API on a device and send maliciously crafted data that, due to a vulnerability in the code processing the data, causes the device to begin executing the supplied data as if it was code. A good example of the potential harm with remote code execution is Barnaby Jack's famous hack of a wireless insulin pump. It's also been a problem for home surveillance cameras and baby monitors. To fix this problem, developers should create separate administrative and user interfaces and keep functionality at different security levels independent. Also, use device firewalls to restrict outside access only to those ports that are absolutely necessary.
2. Code Injection Attacks - Just as with traditional web applications, IoT applications are vulnerable to injection attacks (SQL injection, blind SQL injection, format string attack and buffer overflow) which can corrupt processes or steal data unless the proper measures are taken to secure them ahead of time. One example is a video conferencing product developer which was previously reported as susceptible to arbitrary code injection, according to US CERT. In order to prevent injection threats, developers should follow relevant software security requirements, avoid dangerous APIs, reduce the exposed interfaces, use managed languages, static code analysis and hardware processing of I/O using fixed functions.
3. Sensitive Information Disclosure - Another risk that carries over to IoT products is sensitive information disclosure. In the case of IoT, this could be manifested in terms of weak encryption, insecure data handling and storage, cleartext or hardcoded passwords, "garrulous" error messages, etc. Given the diverse range of IoT products, the risks could vary from compromising the WiFi credentials of smart lightbulbs, as was recently demonstrated, to accessing critical health information in medical devices. By following relevant software security requirements and using scanning tools post-development to check for flaws, developers should be able to eliminate these threats. Be especially cognizant of the value of "phone home" telemetry data and the increased value that data can have when aggregated.
4. Using Fixed or Predictable Codes - Any device that can be remote-controlled by the user or a technician should not use fixed codes or predictable rolling codes as these will make it vulnerable to unauthorized access and manipulation threats. The same principle applies to implementing backdoors and sharing passwords, keys and certificates across devices. At this year's Black Hat, a security researcher will show how nearly all home alarm systems with RF remotes can be disabled using a replay attack. Developers should ensure that administrators have the ability to remove or replace any such values that are in place for initial access.
5. Secure Updates and Configuration - Another significant security challenge for IoT products is that most of them do not implement secure methods to update the software and/or firmware. This issue ranges from devices that cannot be updated at all, can only be updated via a local connection (USB or serial) and those that communicate in the clear or accept unsigned updates. This prevents security fixes and updates from getting to devices and could allow attackers to replace the operating system or application code on your IoT device. One real-world example is Google's Nest thermostat, which researchers revealed to be vulnerable to booting unsigned code, allowing them to backdoor the device. Unfortunately, this is not an easy problem for the developer to address alone. Updates need to be downloaded using a secure communications protocol, they must be validated, and for rollouts of large numbers of devices, automation has to be in place to manage the entire process. Developers need to work with hardware designers to ensure that the boot and update process is secure from start to finish. Configuration of devices similarly needs to be locked down and securely transmitted when updates are made to devices.
6. Support for IPv6 - Since the world is transitioning to IPv6, it's important for IoT developers to make these devices compatible with the new address scheme. Doing so will ensure that a company won't have to face increased costs later on when it comes to managing and growing their networked devices on limited and costly IPv4 addresses. Additionally, developers should also implement IPSec to better ensure authentication and confidentiality of data.