Co-authored by Bastian Bergmann, CEO of WATTx and Martin Unger, CTO of WATTx.

Building IoT ventures from scratch by prototyping hardware devices and their backend systems as well as working for a large company that tries to sell IoT devices itself, we learned a lot about the pitfalls and problems concerning security in the IoT.

Nearly every connected device out there proved to be vulnerable to attacks. Researchers showed that it’s possible to remotely take control over autonomous vehicles, implanted medical devices were manipulated, voting machines compromised and of course all sorts of other “smart” devices, like door locks, light bulbs, thermostats and the like. In Austria a hotel got threatened by hackers that their guests will be locked out of their rooms, if the hotel doesn’t pay ransom in bitcoins.

The consequences are rather easy to see. Unauthorized people being able to control critical devices and infrastructures is a nightmare. Clearly, some attacks may even cost lives—thinking of disabled brakes in a car or manipulated airplane software.

But apart from the consequences of being able to control these devices and their behavior, there is an even bigger threat originating from those devices: they are door openers to attack other systems connected to the same network, that maybe are even more crucial. Just imagine a large company’s file or mail server getting hacked because it had an insecure IP camera in its network. Hackers get access to very sensitive information using a 50$ device as attack medium. Or think of the DDOS attacks on the DNS system using manipulated IoT devices end of last year, rendering the services of Netflix, Yahoo and others unavailable for a significant time span.

Reasons why the IoT is so prone to attacks

The attractiveness to attack IoT devices rose significantly because the adoption rate for those devices increased a lot over the last years and they are just really easy to crack.

Another factor consists in the fact that most of the systems run on a uniform software stack, so at the moment an attacker knows how to take over a specific model or operating platform, he is often able to gain access to a lot more of the devices having similar characteristics.

The possible profit of attacking those devices further rose from the fact that those devices are used in and for more and more critical applications as well as are often connected to networks that comprise crucial systems, that can be infiltrated this way.

So the effort to profit ratio changed a lot in favor of the attackers during the last years and made attacking them a good bargain.

But why are those devices so easy to attack?

Increased Attack surface

Most of IoT devices offer a lot of capabilities having own storage and processing power as well as a significant software stack—often a full blown operating system plus appliances. Increasing the amount of software and capabilities in a system leads to a bigger attack surface and thus allows for more possibilities to attack. In case of retrofitted devices, software might come online, that was never meant to be.

This is especially true for interconnected, heterogeneous environments where vulnerabilities in one device can lead to attacks against others. Rising complexity of interconnections and access possibilities make it even harder to monitor, secure and control the environment.

A straightforward example: attacking a medical device by breaking into the storage room of a hospital and then connecting to it’s serial interface to flash its firmware was possible before, but now the hacker may sit on the sofa on the other side of the world and attack a medical device by using regular communication networks and his laptop. After compromising this device, he can then check the rest of the network for other promising targets.

Providers have no incentive to build secure systems

Building hardware is a complicated, long lasting process and margins on chipsets are low. Additionally, technological evolution in the field of IoT is very fast, especially concerning wireless communication standards. Thus hardware manufacturers rather invest in new chipsets supporting new features and standards than in fixing old ones.

IoT devices themselves are often built by hardware and software development providers that also have no incentive in building secure systems because their customers take purchase decisions by features and pricing, not security or quality of engineering. Thus outdated software, firmware and hardware, known to have security flaws are often used to operate the devices, because fixing bugs or adapting own software to fixed third party libraries means significant effort. And sometimes it’s even impossible because drivers are often only available as binaries.

Up to date compilers could help out with fixing some of the worst security flaws in software when the final appliances get built, but to make things worse development environments are also often totally outdated.

Additionally, the software appliances developed on top of the operating platform are often built in a way that necessary functionality is provided, but already simplest precautions are left unconsidered, and the software regularly contains major design as well as implementation flaws.

Even the operators of those devices sometimes have no real incentive to fix issues, because appliances are often only seen as a medium to sell other services.

Missing expertise at the operator’s side

The companies trying to sell and operate networks of own IoT devices often don’t consider hard- or software development as their core competencies and thus lack expert knowledge in how to build secure devices and services.

Taking a look at the ecosystem of IoT devices makes this obvious. Lock, heater, freezer and car manufacturers are now building IT products—it is hard to impossible for them to hire the necessary talent for building own products or even to coordinate service partners efficiently.

Why is it so hard to fix that?

In the past, we were looking at servers and client computers that we had to secure. After failing miserably with that in the 90’s we got better in keeping our systems secure. Not because we fixed the development process of software and thus avoided bugs—no—we became very good in fixing problems by rolling out automatic updates and fixing critical bugs fast, without user interaction. The same applies to Smartphones. We have billions of them out there, but strangely we had no global security issues with them so far. This is because manufacturers provide software updates to fix security issues relatively fast, as soon as a flaw becomes known.

But with the IoT things are different.

No possibility to fix problems deploying updates

There is often no possibility to fix security issues with software updates because most IoT devices have limited storage, networking bandwidth or the architecture simply does not foresee that use case. Sometimes there is a possibility to install updates, but the process to do so is very cumbersome and risky. The fact that the product lifetime of some IoT devices is very long renders this problem even worse. Thus it might happen that a vulnerable freezer stays online for 25 years without being fixed.

Autonomous operation

Even if updates are possible, regular inspection by users is not wanted and/or foreseen. Thus unnecessary, outdated or misbehaving devices often go unnoticed. Normally the devices are set up once and then expected to operate autonomously, but nearly none of them support automated updates. To make things worse, the devices are always online and often left with default passwords and configuration.

Missing liability for damages incurred by software flaws

Software licenses normally exclude all liability for damages. Thus there is no incentive for operators of IoT devices to fix flaws in their products or make sure to instruct their hardware and software service providers carefully to build secure and safe products. Instead, they are externalizing the costs for damages.

How to fix the IoT

Weak security of IoT devices creates externalities by incurring damages on others due to missing investments in proper engineering. Examples for those externalities are third party services being rendered unavailable by poorly engineered IoT devices in DDOS attacks or unsafe autonomous vehicles running over pedestrians.

A comparable situation can be found with air pollution. A company that doesn’t use filters to clean their exhaust fumes creates externalities because the costs of pollution are imposed on others, like in cities where smog is incurring serious health issues on people.

At some point, governments step in to avoid these externalities, and they issue regulations for filtering exhaust gases. Another approach to internalize externalities that tries to adapt costs for the companies to the externalities they impose on others is CO2 certificates. Every company has to buy as many certificates as it needs to cover its emissions.

The massively growing severity of externalities in the age of IoT is why we plead for a paradigm shift from security as a means to protect safety to safety itself as a means to protect others from harm.

Thus we think a similar approach in terms of regulations is needed concerning IoT as it was done to prevent, e.g., air or water pollution. Regulations covering basic safety requirements for IoT devices have to be installed.

There are already regulations that affect some IoT devices like mandatory FCC or CE certifications mainly focussing on electromagnetic interference. But there are, e.g., no regulations concerning the safe behavior of devices in interconnected environments.

Regulations have a very bad reputation, and yes, sometimes they tend to be inflexible, costly and only covering the very basics. But this could be changed.

Or as it security veteran Bruce Schneier puts it: “...we need to rebuild confidence in our collective governance institutions. Law and policy may not seem as cool as the digital tech, but they’re also places of critical innovation.”

Incentives for proper engineering and operation

No matter how the parties involved in the manufacturing process as well as operating IoT devices have to be incentivized efficiently to build and sell safe products and the end customers to properly install these devices.

A crucial step in this direction is to be able to hold the parties liable for damages incurred by devices that do not fulfill legal requirements. Since it’s neither possible nor economically desirable to build totally safe devices proper insurance should be made mandatory. This way insurance premiums can then be used as additional flexible possibility to incentivize proper engineering or installation.

For this purpose, an efficient way to assess device safety is needed. Extended CE or FCC certifications can serve as one part of the equation, while trustworthy, efficient and timely software safety assessments may serve as the other part that was hard to achieve until today.

So far, software certification providers give an incentive to develop software that meets minimum requirements, but companies that build even safer products are not rewarded. Additionally, for-profit organizations often don’t disclose their testing procedures, what renders them untrustworthy in the eyes of many experts. Apart from that, their independence is often questionable.

But one major problem that remains completely unsolved is that it simply takes them too long to issue assessments. Software has to be tested continuously, because it changes frequently, e.g., when updates are installed, and old tests thus become outdated and meaningless.

This is where new players like the Cyber Independent Testing Laboratory (CITL) come into play. Their automated assessments are based on algorithms analyzing binaries and score their safety between 1 and 100. This way insurances could adapt their premium dependent on the score tested software got and thus writing poorly engineered software gets penalized.

Mandatory update functionality

Apart from incentives to build safe products from the start, software driven products have to have the possibility to be updated frequently.

We learned that the hard way with our current operating systems during the last decades.

Even if manufacturers are incentivized sufficiently to invest in proper engineering, it is neither technically nor economically possible to assess all possible threats and problems a non-trivial IoT device may face during its lifetime. Thus the possibility to react and roll-out updates are critical to preserving device safety and should be mandatory for all IoT products.

Reducing Complexity

Some use cases for IoT devices (e.g., getting toaster online) will be rendered too costly by regulations and insurance premiums. And this is maybe a good idea because we really have to reduce the complexity of the systems we build.

This can be done by either not interconnecting them because the added value is too small compared to the possible damages that might result from the increasing complexity, or by just locking those devices in. That means putting them in secured sub-networks whose border-devices make sure their network participants cannot affect third parties outside those borders. Such a border device could consist of a security-hardened router.

Combining common network security mechanisms and separation of devices in different virtual networks allowing for different trust levels might be an interesting approach within LANs behind such routers (e.g. Trusted Virtual Domains). While in trust level 0 all devices can interconnect, trust level 2 only allows devices assessed as very secure to communicate, e.g., the HVAC system and its control unit.

The router between LAN and the Internet could thus evolve into a safeguard to the outside world in this scenario, letting the toaster only communicate with predefined counterparts, preventing it from incurring harm on others even if it is manipulated.

Conclusion

If we don’t change our approach how we build and operate IoT devices we are heading for serious trouble. Normally governments and humans, in general, are only taking action after a lot of people were harmed and public opinion demands for consequences.

We have to anticipate this development and reduce the damages done during the process. Taking care of things now will also help us to get things right. Otherwise, we will have to fix things fast, and rushing is normally not the best element in taking legislative action.