Advice for IoT device manufacturers

Here’s some simple advice for IoT device manufacturers, app developers and anyone else in the IoT supply chain. Follow this simple advice and you’ll be in a much better place with IoT security. They are in a rough order of priority, most important first.

Mobile app

By far the most common source of compromise in our experience is the mobile app that your customer uses to interact with your IoT device.

Decompiling the app is usually trivially easy and allows the hacker to understand exactly how your device interacts with the mobile app and then interacts with your online services.

The most common flaws we find are:

• Failing to implement SSL or implementing it badly. This can allow the attacker to intercept your customer’s data.
• Using static credentials in the mobile app. Putting a password to your API or any other resource in the mobile app is asking for trouble
• Insecure storage of data in the mobile app. It is perfectly 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, you just need to ensure that your developers follow good secure coding standards. There are some excellent guidelines at OWASP.

If you outsource your development, ensure your contract with the development house includes that the code written for you complies with good security standards

API / web services

Most mobile apps interact with a web service to send data to your servers. Don’t forget that you are publishing your API to the public internet, even though you only intended it to interface with your mobile app. Anyone that can reverse engineer the mobile app can work out how to interact with your 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. Sounds familiar, doesn’t it!
• Injection attacks. Anyone can extract all the customer data that the web service has access to, or worse

Again, excellent resources are available online. OWASP publish a great guide on securing web services.

Web app

Many IoT device manufacturers allow their customers 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 web site leaked their customer data.

The guidance from mobile apps and API security applies here too. No surprise, OWASP have excellent guidance and a well known Top 10.

RF

Your IoT device needs to communicate the data it gathers. It will likely do this over some form of radio frequency. Those commonly used include Wi-Fi, Bluetooth, Zigbee and Z-Wave among many.

If you implement your RF communications insecurely, it is very likely that customer data could be leaked, or you could expose your customers to worse attacks. There are other consequences of using some RF protocols, including exposing your customers to tracking and location of their homes.

Wi-Fi / 802.11 Wi-Fi access points and communications can be made secure. However, wireless clients (phones, tablets, laptops etc) are vulnerable to ‘evil twin’ attacks. Wi-Fi devices are also vulnerable to tracking by third parties using databases such as those at www.wigle.net

You need to think carefully whether you are exposing your customers to tracking when implementing Wi-Fi

Bluetooth Bluetooth works very differently to Wi-Fi, but it is still possible to make a hash of your 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 Wi-Fi are not available to the same extent.

Zigbee & Z-Wave Both of these protocols can be implemented securely. However, they often are not. Follow the good practice published by the standards bodies for Zigbee and Z-Wave.

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.

BGA (ball grid array) 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 CryptoAuthentication 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 your firmware – if an attacker can simply download and unpack your firmware to reverse engineer it, you have missed a useful layer of security. Signing your firmware protects against malicious updates.

Disabled unused functionality – frequently our 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”. You’ve given your device to the attacker, so you need to harden it against physical attacks.

Infrastructure

There is plenty of advice online about securing your server and other environments. However, at the very least you 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: Changing things and maintaining security

No doubt you followed this and other guidance when developing your IoT device. But never forget that the landscape changes. New vulnerabilities are exposed in protocols, frameworks and hardware all the time. You need to keep abreast of this and ensure you can update your IoT devices in the field.

Your 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 yours. How do you fix it? A hugely costly product recall or an easy over-the-air update?

Despite your best efforts, mistakes may have been made in your implementation. Can you fix it quickly and easily, without exposing your 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 your developers.

Failing to properly secure the OTA update process is also a great way to let the hacker in to your customers IoT devices

You will also no doubt update your mobile apps and other code over time to add new functionality. Be careful that you don’t introduce new security flaws in the rush to make your IoT device more functional.

Update mechanism – if a bug or vulnerability is found in the device, you need to have an easy mechanism to update the firmware. Assuming you will get everything right first time is naive and vain, but a mistake that many have made.

Automated update mechanism – 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 your 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 your system, whose fault will it be? ‘The user set a weak password’ isn’t a strong defence to the media when investigating your data breach.

Force customers to set strong passwords. Give them guidance about strong passwords and point them towards free password management apps and tools.

Biometrics: Don’t be fooled in to thinking that biometrics solves the password issue. It doesn’t. If a password is stolen, the customer simply comes up with a new one. If their fingerprint is stolen… Biometrics AND passwords work brilliantly together for really strong authentication

You might also consider putting a PIN in front of your mobile application as an extra layer of defence. Two factor authentication (such as sending an SMS with a one-time code) also significantly increase security.

Customer data

Think really carefully about how you store your customer data. Do you have copies of it lying around for developers to use as ‘test’ data?

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 your customer data? Is it hosted in the ‘cloud’? What if one of your DBAs had their desktop/laptop compromised through a malware attack?

Check your cloud service configuration carefully. Your customer data is your crown jewels – most start-up companies do not survive a customer data breach. Surely such valuable data merits two factor authentication to access?