The Regulation of Things

As has been very widely reported we witnessed an extremely large distributed denial of service (DDoS) attack last week against Dyn. The level of coverage extended far beyond the technology press, going as far as segments on media outlets such as the BBC and CNN. We can expect many more such attacks, and related broad coverage, in the future.

The incident analysis provided by Dyn highlights how much of an afterthought security is to many device manufactures. A large part of this is cultural. It is often stated that developers in the embedded systems space never really thought about security, and to a certain extent this is true, but that is far from the only cause. Overall the software industry is lax on security, and relies heavily on end user licensing agreements and similar devices to abdicate responsibility and mitigate the risk of litigation against companies selling software.

When we were reviewing the call for papers for ThingMonk, RedMonks Internet of Things conference, earlier this year security emerged as a topic people clearly wanted to talk about. The talks that we ultimately selected, from Alasdair Allan and Terence Eden, highlighted some of the incredibly lax approaches that companies and developers are taking towards security in the IoT space (both talks are linked at the end of this article).

Politics & Regulations

Big bang events, such as last week’s DDoS attack, which loom large in the public consciousness are often the starting point for popular awareness and political change. As awareness grows on a political level we begin to see legislation being drafted and regulatory frameworks proposed.

In and of itself this is a good thing, it is precisely what we elect politicians to do. The problems begin to arise when legislation or regulations are either poorly drafted, or drafted without the necessary understanding of the underlying technology and culture, from what is possible, to what is feasible and finally what is realistic. The regulations surrounding finance are a prime example of this – well intentioned, but in many cases the implications were not fully thought through. In a similar vein the implications of the EU GDPR framework are very significant, but are currently being treated as an afterthought by many technologists.

While it may be realistic for companies to be held responsible for ensuring connected devices they own are secure and updated, it is far from reasonable to put the onus on consumers for updating their devices. Essentially such updates are firmware changes, which we know are updates that are going to be completed far less frequently.

Now consumers have a growing understanding of the reasons why to do software upgrades, but in most cases it is in reaction to a prompt. People are, rightly in my opinion, hesitant to accept automatic updates. However automatic updates may be the only way to address the security problems which are being created with the Internet of Things.

This leads us to our two big question – who is responsible for ensuring that devices are secure and what is the security baseline that needs to be set worldwide? Companies who produce devices will lobby extremely hard to ensure they are not responsible for the devices, but given current behaviour we have to ask ourselves is this a realistic position to hold in the long run?

Developers, Architects & Responsibilities

There is an onus on developers and product managers to rethink their approaches and bake security thinking directly into everything they are doing. An awful lot of this work is very basic housekeeping which development teams should be doing by default – things such as minimising image footprint, disabling telnet (how anyone can even contemplate shipping a device with telnet open is beyond me) and all other unnecessary software on a device, proper password and certificate management, using well established building blocks such as SSL, SSH and so forth.

There are obvious counter arguments that people will make around the processing power of the devices and so forth. Realistically though if a device is powerful enough to be used in a DDoS attack, it is powerful enough to be secured properly.

The next layer is understanding the providence of the code running on the device, and components that are being pulled in. More importantly understanding and recording this across the lifetime of a product to allow security researchers to quickly reproduce problems will also be extremely important.

Finally providing opensource tools and frameworks to ensure a base level of security is something that can be easily done. There is a lot of low hanging fruit to start with. Projects such as the Linux Foundations Core Infrastructure Initiative are already leading the way in related areas, we need to see similar initiatives emerging focused on code and practical tools. The Eclipse Foundation are also bringing practical IoT security themes directly into their conferences. There may also be some interesting outputs on the horizon from the IoT Security Foundation, but thus far these have been white-papers rather than tools.

The time to act is now. As an industry we all need to show the necessary leadership to get our own house in order. When the politicians and regulators come knocking, and they will come knocking, the technology industry need to be able to show that we are already starting to address the problems, explain what is possible and work with legislators and regulators to put sensible rules in place. The current status quo is in no longer acceptable.

ThingMonk Talks

Disclaimers: The Linux Foundation and The Eclipse Foundation are current RedMonk clients.