Search
Close this search box.

IoT Security and the Cost-to-Care Ratio

Share:

IoT Security and the Cost-to-Care Ratio

Here, we take a closer look at IoT security in terms of the “Care-to-Cost” ratio – e.g. are manufacturers and product developers prepared to pay more (at least 25% more) to increase security in their offerings and are consumers willing to shell out for enhanced security?

The further we travel into IoT territory, the more the potential for innovation becomes apparent. According to latest estimates, 25 to 50 billion devices will be connected through IoT by 20201,2.

This journey isn’t without its challenges – particularly in terms of security.  There can be no denying the need to tackle spiralling data and privacy concerns.  But – as always – the bottom line is cost and demand; the “Cost to Care” ratio, if you will.

This term came to prominence when Boston-based information services expert Jeff Schiller examined IoT security at a seminar last November.  But has the industry taken notice, can it educate end users about the IoT security landscape? Are consumers prepared to pay for their protection? Let’s examine some of the issues around IoT Security and the Cost to Care Ratio.

Security and Product Development

There are three primary factors:

Device security – the IoT device must be independently secure. Can a malicious party hack into it in order to access or alter recorded data? Can it be reprogrammed? Using a smart electricity meter as an example – monitoring the times of day a house isn’t consuming much electricity could indicate when a resident is away from home; is now a good time to break in? The reverse of this, altering the reported energy consumption, would allow the resident to steal from their supplier. Encrypting stored data, and robust firmware/software validation mechanisms are required to prevent device exploitation.

Then there’s transport: Whenever data is transmitted, securely is essential. Whether it’s ensuring that the user’s wireless network has appropriate mechanisms to avoid unauthorised access (e.g. WPA2), or encrypting transmitted data, transport cryptography and server certification are key technologies.

Often overlooked – and arguably the most critical issue – accumulated data.  How secure is the end server holding this data? Are account details, addresses and financial information stored in an encrypted form? Does the company have audit policies in place to ensure only required staff have access to this data and that they’re using appropriate security hygiene (no “password” passwords please!)? Is the network monitored, in order to identify unusual network traffic that could indicate malicious activity?

In the age of identity theft, a single server storing this information is a tempting target for an orchestrated attack.  Why would a hacker expend time trying to steal an individual’s data from their home, for limited rewards, when they can steal the information of half a million users from a single server without anyone realising?

There are three primary points of failure; it boils down to securing each of these in turn to create a robust end-to-end system for the user and  service providers.  Bear with me – that’s not as utopian as it sounds.

As the IoT and M2M landscape expands in size and complexity, developers will increasingly need to create products which are secure right out of the box. From the earliest planning, security must be a core deliverable for all aspects of the project.  Safeguards can no longer be considered an afterthought; adding security near the end of a development project rarely provides the robust protection industry and consumers require.

A good example would be storing a user’s password. If it’s encrypted as soon as it’s entered, the system will be intrinsically more secure.  A developer will have to make the effort to decrypt it only if and when required.  This may never even be the case on the local device, significantly minimising data exposure to attacks.  If encryption had not been mandated at the start, the developer would be making decisions on a case-by–case basis as to when it should be encrypted, rather than when it needs to be decrypted; there is simply more scope for points of failure to be introduced and exploited.

Standard Inclusions

Software and hardware solutions are available which should be standard inclusions in IoT systems.  Manufacturers such as Atmel have developed Trusted Platform Modules – hardware which verifies whether or not the software it’s running has been tampered with.

There are also several existing transport layer security products – however they must be used with due diligence to be effective.

Take Open SSL; a widely used, and broadly speaking secure, encrypted transport protocol.  But all too often a developer will integrate the most recent version of the software to their system, and never re-visit it. Later, when security flaws come to light, e.g. the Heartbleed vulnerability, the devices are not, or cannot, be updated in the field.  56% of all uses of SSL are at least 50 months old3; not only are those users still susceptible to the Heartbleed attack, they’re probably also exposed to all sorts of exploits which have subsequently been patched-out.  These updates should be automatically applied, rather than relying on how well-informed the user is.

Cost-to-Care Ratio

Jeff Schiller from the Boston Unix and Linux Users Group has stated that the “Price-to-Care Ratio” is about how price reflects the amount that people care about something, and, in turn, what they’re prepared to pay.

Security is a negative deliverable.  Users only see it as important once the system has already failed and their data misappropriated.  They need to be more security conscious, made aware of it as a key feature, and understand why it’s required.  IoT safeguards are eventually going to cost us all more.  Security adds cost, doesn’t have any apparent benefits and, if not done correctly, can even create a more convoluted user experience. It’s not generally seen as a feature that makes a product or service better.  Security takes longer to implement, costs more, and adds complexity.  This needs to be turned into a positive by manufacturers, justifying, in my view, the estimated 25% additional cost associated with the time and resource investment to provide improved data safeguards – enhanced security is worth paying for.

Data Acquisition, Retention and Corporate Responsibility

The Sony Pictures breach – and its on-going repercussions – is one of a number of recent high profile incidents bringing data retention into sharp focus.

It’s very difficult for the end user to influence corporate IoT security policies, network and information management.  It’s down to consumers only paying for services from companies which actively manage these issues.  Recently, this has been made more difficult by various corporations changing their terms of service to stop end users holding the company accountable by bringing class action law suits against them for security failures.  These kind of policies are not productive for the industry in the long term. They’re just wiping their hands of the responsibility – when, clearly, the buck should stop with them.

Education, Education, Education – Encryption, Encryption, Encryption

Some companies continue to make advances through the security wilderness. On the embedded front, UK semiconductor designer ARM has just acquired the Dutch firm Offspark, a leader in IoT communications security in order to strengthen its solutions to IoT data concerns.

Ultimately, the Cost to Care Ratio can only be resolved if manufacturers are prepared to dig deep to provide solutions. Corporations must accept their data responsibilities, including educating end users, who themselves need care enough to pay the premium necessary for IoT Security.

And that’s a pretty big ask.

FURTHER READING

1 Gartner: http://www.gartner.com/newsroom/id/2905717

2 Cisco: http://blogs.cisco.com/news/cisco-connections-counter/

3 Cisco: 2015 Annual Security Report, 12/01/15

The original article was published in Design Products and Applications, April 2015 and was written by Andrew Hogan from ByteSnap Design.

Share:

Related Posts