The recent exposé of the nomx secure email box [1] got us all excited at IoTSF – mostly for the wrong reasons – but it also gave us the opportunity to reflect on a number of common security issues from an IoT perspective.

We’d start by congratulating BBC Click and their security researchers, Scott Helme and Professor Alan Woodward, for making their work accessible and simple to understand. We’ve a saying at IoTSF that we need to bring security out of the shadows and, whilst we do not expect everyone to become experts, we can certainly improve general awareness of the issues. We also agree with them that the Raspberry Pi is an amazing educational tool – many of our members use them and, whilst security is not the priority for the product, it is possible to add security mechanisms to improve it to a point which is suitable for a number of bespoke projects. Absolute security however, is another matter.

We asked one of our seasoned product experts, Richard Marshall, to take a look at the nomx discoveries and give an IoT perspective on how the public information relates to the work of the IoT Security Foundation. Here’s what he had to say.

In the course of the evaluation, a number of common failings have been clearly identified that are important factors for anyone designing an IoT product, in particular:

  • Without physical access, the MAC address can be a very useful indication to an attacker of the type of platform being targeted, especially where a product is based upon a widely available general purpose compute platform. This can help the adversary focus their attack on known platform vulnerabilities.
  • Having a removable, unencrypted file system makes it incredibly easy for an attacker to copy and reverse engineer the software, including searching for sources of entropy which could indicate encryption keys in the software. Had the nomx product used embedded FLASH, the attack would have been a little harder to orchestrate.
  • When choosing a hardware platform on which to base a product, consider it’s suitability from a security perspective in the context of its intended use. Does it have a unique identity and support secure storage of encryption keys for authentication of software and each devices’ identity.
  • Ensuring the version of the OS has the latest security patches and does not use an out of date or unsupported operating system is a basic recommendation.
  • Without a secure method to update software, it is not only possible to execute an unauthorised or potentially malicious software update, but it may also make it difficult to subsequently upgrade the software to close identified security vulnerabilities once compromised.
  • As noted in the Click programme – where passwords are used for authentication, avoid the use of default passwords and force users to set their own unique strong passwords. Avoid the use of password protection methods that are open to simple dictionary attacks.
  • In many cases it is good practice to start from a position that assumes the IoT product is connected to an insecure network, rather than assume a product will be installed on a secure one.
  • Where a web server is incorporated into the product, ensure that steps are taken to ensure no cross site scripting vulnerabilities are incorporated into it.
  • Leverage the ethical hacker community: Having a vulnerability policy in place gives security researchers a clear point of contact to report vulnerabilities and product vendors should have predetermined processes in place to promptly communicate with both researchers and end customers to manage the risk implications.
  • Product recalls are never welcome by the vendor or the customer, however consider the implications and the impact of having to recall products. Many IoT products by their very nature may be installed in inaccessible places, or be monitoring processes which require significant availability. A product recall driven by hardware insecurities could potentially have very significant ramifications for the product vendor’s business and customer relations. In this case the ramifications could be argued to be relatively minor, other product vendors may not be so fortunate if their products are found to have vulnerabilities which can only be rectified by a mass product recall.

As is well known in the security community, security is the sum of the parts. So had the nomx product incorporated all the features noted earlier, it would have been considerably more secure and better aligned to the claims for the product.

“Everything else is insecure”

On top of this, we were also intrigued by the marketing – it’s generally considered a faux pas to make intentions of providing absolute security and any such claims should be treated with a healthy scepticism. This is an elementary point for any security professional and where there’s a will there’s generally a way. Making exaggerated security claims throws down the gauntlet to researchers and hackers alike – purely from an intellectual perspective. For criminals, if the product security is protecting something of value or controlling a process of a critical nature (such as a production line, treatment plant, energy generation etc.), it usually comes down to time, money and effort. Security is relative and rarely needs to be absolute – simply fit for intended purpose. If absolute security is what you feel your product offers, then be prepared to be tested – and tested hard.

To conclude, this ethical attack highlights a number of important factors to consider for IoT product vendors, not least of which in the careful selection of appropriate computing platforms. For most, it will be a matter of ensuring the security capabilities are fit for purpose against the use case, and providing the mechanisms to maintain that objective over the product’s expected lifetime.

IoTSF is dedicated to driving both the quality and ubiquity of IoT security solutions. As a non-profit expert organisation, we provide freely downloadable best practice guides, an IoT Security Compliance Framework and training to protect against the kind of pitfalls examined here.

Further details can be found about the Best Practice Guidelines here [link]

Need IoT security training? We have a course coming up [link]

[1] https://scotthelme.co.uk/nomx-the-worlds-most-secure-communications-protocol/