Addressing security issues at the design stage

There are some common sticking points during the manufacture of IoT devices. These include:

Mobile apps: By far the most common source of compromise is the mobile app that a customer uses to interact with IoT devices. Decompiling the app is usually trivially easy and allows the hacker to understand exactly how a device interacts with the mobile app and then interacts with online services.

The most common flaws are failing to implement SSL or implementing it badly which can allow the attacker to intercept customer data; using static credentials in the mobile app (putting a password to an API or any other resource in the mobile app is asking for trouble); insecure storage of data in the mobile app (it is possible to store data safely on a mobile device, it’s just that many mobile app developers don’t). Developing mobile apps securely is not difficult, developers just need to follow good secure coding standards.

If the development process is outsourced, the contract with the development house needs to ensure that the code that is written complies with good security standards.

API/web services: Most mobile apps interact with a web service to send data to servers. It should not be forgotten that the API is being published to the public internet, even though it is only intended to interface with a mobile app. Anyone that can reverse engineer the mobile app can work out how to interact with the web service.

Critical issues with web services include failing to enforce strong session management - one user can see another users data; not implementing encryption properly; and injection attacks. Anyone can extract all the customer data that the web service has access to, or worse.

Web apps: Many IoT device manufacturers allow their customers to view their data through a web browser as well as via a mobile app. The flaws in web apps are well-known, but it would be a bad day for any IoT vendor if the website leaked their customer data. The guidance from mobile apps and API security applies here too.

Radio frequency: An IoT device needs to communicate the data it gathers. It will likely do this over some form of radio frequency. Those commonly used include WiFi, Bluetooth, Zigbee and Z-Wave among many. If RF communications are implemented insecurely, it is very likely that customer data could be leaked, or customers could be exposed to worse attacks. There are other consequences of using some RF protocols, including exposing customers to tracking and location of their homes. WiFi / 802.11 WiFi access points and communications can be made secure. However, wireless clients (phones, tablets, laptops etc) are vulnerable to ‘evil twin’ attacks. WiFi devices are also vulnerable to tracking by third parties using databases such as those at www.wigle.net. Manufacturers need to think carefully about whether they are exposing customers to tracking when implementing WiFi. Bluetooth works very differently to WiFi, but it is still possible to make errors during implementation. Using a PIN during device pairing is essential, though unique per-device PINs are very important. Setting a default PIN of 0000 or 1234 is asking for trouble. Bluetooth devices are trackable, though it is much harder as war-drive databases such as those used with WiFi are not available to the same extent. Zigbee and Z-Wave both have protocols that can be implemented securely. However, all too often they are not.

Hardware: Security will rarely be the primary driver behind hardware choice, but there are a number of important considerations to make. Microcontrollers with embedded flash memory make recovering firmware harder, but offer limited capacity compared to microprocessors with external flash and RAM. Debug ports such as serial consoles and JTAG are rarely used in production devices, but frequently left in place. Consider physically removing them from devices, blowing fuses to prevent their use, and disabling them within software. Ball Grid Array (BGA) packages, combined with careful PCB design, can make tapping into signals much more difficult. Consider using a secure authentication device such as a SAM module, Atmel CryptoAuthentiction device, or Maxim DeepCover device. These devices store keys securely in an authentication scheme. Many embedded systems lack a good source of entropy, especially at start-up. Consider this when generating keys.

Firmware: Encrypt and sign firmware – if an attacker can simply download and unpack firmware to reverse engineer it, a useful layer of security has been missed. Firmware protects must be protected against malicious updates. Disabled unused functionality – frequently the route into embedded devices is via functionality that a user will never use, such as a serial port, JTAG, telnet or hidden debug functionality. Remove everything that will not be used from production devices. The device has already been captured – a frequently repeated maxim in information security is, ‘once the attacker has physical access, it’s game over’. The device has been given to the attacker, so it needs to be hardened against physical attacks.

Infrastructure: There is plenty of advice online about securing servers and other environments. At the very least this should cover updates - timely application of software updates, particularly those relating to security; passwords - blank, default, common, simple and re-used passwords are a very common route used to exploit systems; least privilege - users and services should have the least privilege required to successfully carry out their purpose. For example, developers might need local admin rights on systems when developing, however, day-to-day tasks should be carried out with normal user rights. Similarly, a database connector should not have high privilege rights to the database, just the minimum it needs to carry out the queries that it needs.

Updates, re-changing things and maintaining security: No doubt this is followed during IoT device development. However, landscapes change. New vulnerabilities are regularly exposed in protocols, frameworks and hardware. Manufacturers need to keep abreast of this and ensure they can update IoT devices in the field.

An IoT device will rely on numerous logical and physical components. Any one of these could have a serious vulnerability uncovered in future, through no fault of the manufacturer. How is it fixed? A hugely costly product recall or an easy over-the-air update? Despite best efforts, mistakes may have been made during implementation. Can it be quickly and easily fixed, without exposing customers? Over the air updates are a common route to fix these issues. However, this should be no excuse for a ‘we can fix it later’ attitude from developers. Failing to properly secure the OTA update process is also a great way to let the hacker into IoT devices. Mobile apps will no doubt get updated as will other code over time to add new functionality. Care should be taken that security flaws are not inadvertently introduced in the rush to make the IoT device more functional.

If a bug or vulnerability is found in the device, there needs to be an easy mechanism to update the firmware. Assuming that everything will be right first time is naive and vain, but a mistake that many have made.

Unless the mechanism to update the firmware is automatic, many devices will never be updated. This is especially true on devices that are fit-and-forget, such as lightbulbs, thermostats and burglar alarms.

Passwords: Marketing people hate this point, as they look for ease of customer use. However, it’s a very common source of compromise. Customers will see security as the manufacturer’s problem, not theirs. They will set the bare minimum of complexity with passwords, probably re-using passwords they have used elsewhere. When their data is breached on the manufacturer’s system, whose fault will it be? ‘The user set a weak password’, isn’t a strong defence to the media when investigating a data breach. Customers should be forced to set strong passwords.

They must be given guidance about strong passwords and be pointed towards free password management apps and tools. Biometrics do not solve the password issue. If a password is stolen, the customer simply comes up with a new one. Biometrics and passwords work brilliantly together for really strong authentication. Putting a PIN in front of a mobile application as an extra layer of defence could also be considered. Two factor authentication (such as sending an SMS with a one-time code) also significantly increases security.

Customer data: Storage of customer data should be carefully considered. Database encryption is a really good idea, but remember that the data is often only encrypted when at rest. It is likely to be unencrypted when accessed. Encryption key storage is also critical. Consider who has access to customer data. Is it hosted in the Cloud? What if a DBAs had their desktop/laptop compromised through a malware attack? The Cloud service configuration should be carefully checked. Customer data is a manufacturer’s crown jewels – most start-up companies do not survive a customer data breach. Surely such valuable data merits two factor authentication to access?