Why slap-dash application development is threatening the IoT

It's impossible to know how your latest IoT-enabled device is going to be used by the purchaser, so make sure that security is designed into your products from the beginning, says Paddy Srinivasan

Paddy Srinivasan, vice president and head of products, Xively Internet of Things at LogMeIn
Paddy Srinivasan, vice president and head of products, Xively Internet of Things at LogMeIn

We've all seen the eye-watering statistics on the future potential of the Internet of Things. Cisco Systems estimates 25 billion devices will be connected to the internet by the end of this year, while IDC believes $7.3 trillion in revenue will be generated by IoT components by 2017.

For entrepreneurs or big businesses looking for a slice of the pie, those figures are enough to propel them into creating a seemingly ‘new' product, service or feature.

The IoT is still young, but there is already growing concern that slap-dash application development and design are too often the rule rather the exception. Just because you can make a historically ‘dumb' device like a home appliance, ‘smart' doesn't mean you should.

Many IoT security failures can often be traced back to poor decisions about the type of ‘smart' features to implement, and their scope.

The consumerisation of IT means that technologies designed and marketed to consumers often find their way into workplaces. It is therefore impossible to know how your technology will be applied once it has been marketed and sold. In an age where the media and the general public take no prisoners when data has been compromised, it's not acceptable to introduce security risks at any given stage of the product development process.

Before beginning any app development, designers must weigh up the pros of ‘connected' features against the cons of the security holes they open up. IoT applications must be designed to assess the security and privacy implications of connected features like messaging and social media integration upfront. An email proxy requires clear and concise directions on secure configuring, with strong administrator credentials, shielding it from low-level attacks and port scans.

These basic protections will then influence other design decisions. A rigorous assessment of the security implications of smart features will increase the cost of development – however, it's better to discover flaws at this stage rather than deployment.

Another common mistake at the development phase is the dangerous ‘security through obscurity' approach, i.e. the assumption that hackers won't be interested enough.

Products must be designed with the assumption that they will be purchased, dissected and studied. Security shortcuts such as embedded private keys or weak authentication might save time and speed up deployment, but there is a fine line between a global IT ecosystem and a global botnet network.

Connected device makers should also ensure any software updates or modification should require administrators to authenticate to the device first and require the use of signed executable files to verify the integrity of the software that is being installed. Devices must be able to register activity which could indicate an attack. Robust logging features are a must if administrators are required to recover compromised systems.

In today's IoT world, it's not enough to require end-users to use their initiative and set long passwords. There's a ‘set and forget' mentality among users which is not sufficient for ensuring around-the-clock security.

IoT device makes should make a requirement for regular password updates and supporting updatable firmware by way of authenticated, signed software updates are steps towards a more resilient IoT deployment.

Finally, you can't underestimate the importance of screening supply-chain partners closely, to make sure contracts and service provider agreements protect you. Low-cost and powerful embedded device platforms with ready-made APIs and open source software libraries that can be quickly integrated can accelerate development, but they also bring security risks which can be hard to pre-empt.

In order to mitigate this risk, companies must manage partners using ‘least privilege' principles to keep them from gaining access to things they don't need.

Building an IoT product is not as simple as it might seem and unfortunately, quicker does not mean safer.

As we've seen, the security and privacy issues raised by connected products are often subtle and complex.  Any business looking to design and deploy applications must wrap a robust security policy around every decision, ideally with a dedicated member of the team who can set detailed deliverables.

Smaller companies might want to consider IoT platforms-as-a-service which can address many of the security and data integrity issues that riddle poorly designed IoT products – tools which let you streamline secure communications based on industry-standard encryption protocols and extend fine-grained user provisioning to IoT products. This will also improve time to market, whilst also avoiding a rude awakening in the future.

Paddy Srinivasan, vice president and head of products, Xively Internet of Things at LogMeIn