Open IoT definition — thoughts and suggestions

Recently I wrote an article arguing that we need a voluntary seal for IoT security. This article changed a lot during writing, because Bruce Schneier vocalized the need for IoT legislation in the US. He argues that the ones who will suffer from IoT insecurity are other people than the buyer or seller, and therefore there is a market failure, an “externality” in economic lingo. There is no incentive to pay for or invest in security in these devices. This is the same problem that we face in environmental issues, and the basics of environmental economics is to “internalize externalities”. When governments try to do something about this, regulations or tax is used, with varied results.

While IoT security unarguably is a market failure for the time being, but I see the risk that regulation will become costly overhead without benefits. IT is both over and under-regulated at the same time. Legislations like the EU Cookie Law or US copyright laws have caused new issues and one might argue that they have been totally inefficient.

I see three important reasons why IoT might self-regulate in the near future: Ransomware, the new Data Protection Regulation GDPR and an IoT security seal. Such an initiative will be discussed next weekend in London.

I cannot attend iot.london, but I would like to weigh in to the discussions.

Who am I? My whole life I’ve been interested in societal vulnerability and I am head of Security, Privacy and Test in an IoT company in Sweden. I have a background in environmental sciences, IT security, and I have a bachelor in journalism. User security and usable security are passions of mine.

In the article above (and also in this video) I suggest a voluntary seal/mark/certification for IoT security, based on similar principles as KRAV, the Swedish seal for organic food. Most probably there are other organic seals with the same, or similar, criteria and structure.

The issue of IoT security is on the agenda. The public wants to buy secure products. But they can’t, because they can’t tell the difference between Internet of Things and Internet of Shit.

Here is my list of what an IoT security seal will have to focus on. The issues I think can be sorted into five categories: user communication, transparency, data ownership, operational security and technical security.

Customer awareness

A good content must be clad in good communication. The logo must be appealing (yes, it is important). It’s about recognition and customer awareness. I write this as the first point on my list, because I see it as one of the most important things, that may be overlooked.

Anti-corruption and anti-colluding

A well-known security seal will raise the credibility of any brand that carries it, and thus also the customer’s willingness to pay. There will be a strong incentive for some organizations to get the seal without doing the investment in good processes and security systems. There may also be incentives for the issuer of seals to look the other way, for a small fee.

This issue can be addressed with strong opsec, transparency and procedures. We can take inspiration from the way ICANN handles the signing of the DNS root servers.

Organization

Organic seal KRAV is a collaboration between the industry and non-governmental organizations. I think such a collaboration would be appropriate also for an IoT seal.

Security vs Privacy

In a european context, security and privacy are most of the time. However, it’s not always the same thing. Google is a pioneer in security, but harvests data about you and me as their business model.

The Open IoT statemenent from 2012 is mainly handling privacy and data ownership, and I am happy to say that more or less all of it now is part of European GDPR law. Including criteria about privacy in the IoT security seal might be redundant. However, we still don’t know if the law is going to be used the way it is intended.

Actual content

Thus far, I’ve only been writing about organizational “intangible” stuff. Structure is very important as a foundation for all security, or quality work. But what about the actual content?

I propose a reasonably low entry level. I consider the following bullet points a baseline. Anyone with an interest, time and the right checklists can do this.

• The product cannot be trivially hacked (OWASP checklist)
• Update management
• A commitment to handle Vulnerability Disclosure (ISO 29147)
• Life Cycle Management
• Commitment to the meaning of the GDPR

So what do you think? This is hardly an end point for me. I hope for an open discussion and if you think I’m wrong about something, I want you to formulate your best arguments.