Get started Bring yourself up to speed with our introductory content.

IoT architected for security

It seems like every week there’s another doom and gloom story about how IoT security is irretrievably broken. In general, the stories involve a number of players:

  1. Manufacturers who appear to have more interest in shipping devices than developing the functioning basics of security architecture.
  2. IP developers — often silicon vendors — who provided an application stack example to the product manufacturer, which was often used with minimal changes and little or no security testing.
  3. Hapless customers who provided power and connectivity to a device, trusting the manufacturer would have embedded the appropriate security and performed the appropriate testing to know that the device could be trusted to perform only the task it was designed to do.
  4. Multiple victims, across well-known industries with services relied upon by millions, hit with distributed denial-of-service (DDoS) traffic generated by these devices.
  5. Security professionals wringing their hands about the insolubility of the problem.
  6. Critics who essentially fear every connected product and call for the government to mandate standards in an area where no one approach can possibly fit all devices.

However despondent for those familiar to security architecture, this state of affairs is fairly predictable in all reality — and easily explained by the motivations of each party. Additionally, one cannot simply expect these concerns to evolve without the landscape and related revenue flow also changing. We can examine the primary motivations of each party, though, to better understand their perceptions.

1. The manufacturer

A successful manufacturer is one that knows their customer, and so produces quality products with features that their customers appreciate. The customers then purchase and recommend these products, driving volume sales and manufacturer success.

The biggest issue here is that the technologies required to build an IoT product are generally vastly different to those they have mastered to build great non-connected products. Even the best embedded software team tends to have little experience with scalable cloud back ends and cryptographic stacks.

Usually, a manufacturer will look towards the supplier of the wireless silicon they are integrating in their connected product for assistance with the required software.

Unsurprisingly, manufacturers worry about development costs, which have to be amortized across every product sold. If the product never hits sufficient volumes to recoup these costs, the product will never make money, so development budgets for the new breed of connected devices are often small.

Finally, typical product cycles for a manufacturer are in the one to five year range; a product team will ship a product then usually a slightly different team will reassemble to make the next product. It can be very hard in most product companies, even with the best will, to ensure a product that was made many years ago receives appropriate ongoing effort to ensure security (see comments about costs). Team members leave. Source code and tribal knowledge gets lost.

2. The IP developer

The first thing to note about connectivity software is that a lot of it comes from the vendor of the wireless silicon. Over the past five years, silicon suppliers have had to augment their offering with a fully featured software stack to support that silicon — moving beyond hardware drivers to network and security stacks and even embedded operating systems. Once one vendor started offering a full stack, the others had to follow suit as their customers started making silicon choices based on how comprehensive the free software stack provided was.

The problem with a silicon vendor being a software supplier is that software is essentially a marketing expense, and it is provided to make a customer pick their silicon versus the competitors’. Once silicon is designed into a product, there is little incentive for the vendor to provide robust support and maintenance of the stack. They get the design win, and after that point it’s very hard for a customer to move to a competitor’s chip, even more so when their application code is delicately intertwined with the vendor’s stack.

Given a typical five-year silicon production lifespan, especially for chips that get designed into high-volume consumer applications, there is even more concern about what support is provided once the part is no longer in production.

 3. The customer

In the end, customers just want a product to work, and work well. Though savvy customers may be able to make judgments based on subtle security characteristics, most essentially trust the manufacturer’s brand to guarantee a certain level of design and quality.

This brings up an important point: should customers trust a brand to be an expert in an area where they have no prior experience?

For example, I may have complete trust in a premium washing machine maker in being able to make a reliable, long-lived, high-performing washing machine. After all, the company has done this for decades — but should I also place my trust in them making all the right security decisions in their connected products, particularly if they have no track record in this area?

An interesting analog is looking at the mobile phone ecosystem. I don’t necessarily trust every app vendor to be making the best security decisions, but I do trust the OS vendor ensures that my phone is secure and that the OS also prevents malicious apps that could cause series harm to either myself or my data.

4. The victims of attacks

As IoT-originated attacks become both more common and more dangerous — and I don’t believe that hackers have yet learned how to use these new tools to their most devastating effect — it will become clear that everyone is a potential victim.

The world has become reliant on a functioning internet, and maintaining that requires participation in cybersecurity from all parties involved.

5. Security professionals

The internet security field, in general, is quite large. There is robust demand for security, particularly in ecommerce, for decades now — not counting the already large antivirus industry.

Many security practitioners have approached IoT as an offshoot of an existing specialist area (for example, phone app security) and have only been adding embedded expertise recently, which means they often lack the necessary holistic view of the problem and instead see it as a collection of discrete ones.

Because security professionals often are only called in after a negative security experience, they are very negative about IoT security. Either they are buying flawed products and finding problems with them, or they’re investigating a DDoS attack spawned by IoT devices, or they are brought in by a manufacturer who is inevitably cash- or time-strapped to test an “almost finished” product before shipment and find it far from secure.

In any case, they get to impart bad news. Rarely are they consulted early in a design process on best approaches, or given free rein to fix problems in a product before shipment.

So how can IoT security be fixed?

The biggest thing that needs to change is that both customers and manufacturers need to place value in security and secure products.

When a customer values security, they will insist the products they buy are secure. When a manufacturer values security — and worries about how bad security may reflect on their brand — they will accept that building secure products will add some cost.

Essentially, once security is valued, then secure products will be built.

But, how will this happen?

A key difference in IoT security is that it cannot be focused on a single part of the product. Security must be architected across the entire product and services. Unlike traditional products, this requires integration between the players along the value chain. This is very different from a traditional supply chain where each supplier is focused on optimizing only on their part of the deliverable.

It is still hard for customers and manufacturers to significantly affect the quality of the software stacks from the IP/silicon providers — the whole problem with software-as-marketing is that the software only needs to be better than the nearest competitor to have the desired effect of impacting a purchasing decision.

Also, most silicon companies are not structured to be able to deliver software, or software maintenance, as a core product offering. Software maintenance is not built into their cost equation and the last thing you want is for maintenance to be an afterthought.

Obviously, given that this is a blog from a platform vendor, the conclusion I’m reaching — hopefully with the reader understanding why the conclusion is being reached — is that the solution to these issues is the use of a secure platform.

The main thing a platform provides is clear alignment. A platform vendor that creates software and services covering a device’s full lifecycle — and is paid for keeping these devices online securely — has a clear incentive to provide this ongoing support.

A platform vendor that does not charge large non-recurring engineering fees for development wants to get products to market as soon as practical, as they don’t receive any significant income until that point. This incentivizes a secure platform architecture and support structure that assures fast time to market and easy adoption.

Because true platforms (i.e., those which are identical across customers and products) are shared between customers, the amount of effort and hence expense that can go into its design, construction and maintenance is orders of magnitude more than even a high-volume product could justify on its own. However, the cost to an individual customer is much less than any in-house development simply because this cost is spread.

This communal sharing of technology investment also means that no customer, no matter how small, is ever left out of a security update.

When a weakness is found in the platform (realistically, every system will have weaknesses) whether or not they are ever exploited, it can be fixed for everyone simultaneously. This is an important point, because it means that all the platform vendor’s efforts are going into making every customer’s product better.

In conclusion: if you’re making a connected product, it’s your responsibility — both as a brand and a contributor to the internet — to highly value security and create secure products. This will either lead you to spend a lot of money and time building your own unique connectivity infrastructure (secure design and exhaustively tested implementations don’t come cheap, and neither does ongoing maintenance) or to build with a secure platform purpose-built for IoT.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.