Can the IoT save itself from the imminent doomsday scenario painted by the Security industry?
A lot has been said abut Information Security and I will omit elaborating here what every Security book starts out with in great length. Instead let me jump right to the heart of the matter namely that Security has always been treated like an unwanted love-child in boardrooms. As an employee, surviving in InfoSec always required some masochistic tendencies, subjecting yourself to constantly justifying your own existence within the wider world of Software Engineering and accepting that your allocated budget was always too tight for you to do the right thing. So many of us meddled through within our own organization, cash-strapped and without a voice.
Like some hyperactive version of the Greek goddess Cassandra most of us in our junior years were still busy warning everyone, about an imminent inside or outside threat, or time-bombs ticking away in the bug ridden infrastructure. But as you got older you have decided it’s healthier to lie low. Too many times have you been meeting with those that pay your salary and instead praise you ended up defending your position and being usually asked a variety of these of these 2 same questions:
Everything works what are we paying you for?
Nothing works right now! What are we paying you for?
how could you ever win?
Or at least this has been the situation for many until recently. I don’t know exactly when but at some point things took a different turn and the situation improved. Was it the horror stories about hackers communicating with your sleeping toddlers, or a hacked car or maybe it was the many data breaches that caused losses of privacy on an unprecedented scale. I’d like to think it was the summer of Snowden which caused media to go haywire and put our industry in the spotlight illustrating what happens if security & privacy issues get neglected.
Spies always spied. Hacks and website defacements always happened. The only thing that changed was the frequency and increasing severity of the damage. Somehow the IoT amplified the issue and changed our sensitivity to these news.
Investment in IoT Security is now “through the roof”  my company which deals a lot with upcoming technologies and standardization gets asked by a different VC every other day if I know of any projects that are worth spending money on. Also snake-oil products are rampant and it’s a bit like a Wild-West mood out there with sometimes those that shout loudest getting the biggest attention.
Apart from these growing pains, the IoT has created a big opportunity to rethink security not just for IoT’s sake but for the industry as a whole. It is not IoT that is over-hyped (and as some claim “not ready for prime time”), but our basic approach to how we develop, deploy and bundle software requires a rethink with a better focus on Security.
IoT Security is not new and really often just “regular” security wearing a new dress. Because of IoT, Security has become very loud, popping up with a vengeance forcing us to deal with technical and cultural debt from long ago. Debt that we failed to address since the early days when we connected the first computers together.
The challenge to solve this is not so much on an engineering level but more like a battle in the boardroom of how to educate clients about the benefits of security while remaining competitive.
When I say “not so much on an engineering level” I’m not talking about past or future technical bugs like heartbleed or even unknown 0days exploits. But on the engineering level it is straight-forward. We know what to do: Ask any developer who about their opinions of how to test better or ask a tester on how to develop better and you get some new ideas to improve quality. Go do that now, because these are your low-hanging fruit of how to increase your product quality.
Now IoT is bringing 2 “old” camps together under a new (annoying) name. They have traditionally been viewed as isolated professions: embedded developers (stand-alone devices often not connected) and connected / web platform developers. It’s extremely interesting seeing these 2 camps discussing (or being forced to discuss) solutions that affect both camps (embedded guys are forced to understand HTTP/CoAP) and webdev guys are forced to look into things like with low-power or memory constrained devices and standards.
The old joke:
“the 2 most scary things in engineering are a 1) software developer with a soldering iron and 2) a hardware developer with a software patch.“
is no longer true.
One of the most sought after skills being able to work close to the metal while also understanding RESTful API’s and micro-services. Add some knowledge about data-science, decentralization and security to the mix you have a very highly paid individual indeed. Also there are many hackerspaces now popping up all over the globe, which like some kind of an engineering grassroots movement brings together different angles of thoughts and and lets us network and discuss new ideas in person.
So we successfully made these 2 camps work together. Did we forget something? Yes namely that security remains as hard as ever. Neither the embedded guys nor the web guys will be able to confidently implement the solution and you really need a security professional. Yes, and chances are that most of your developers need to go back to school and re-learn the basics, so don’t look to them for help. Also you need to hire specialists, or give those that you have more voice.
It is probably stating the obvious: Those guys that do implement security should really have their main career focus in the security field. Even your developers might be able to meddle through that doesn’t mean the product is safe. Hell even you give it to your experts it still might not be bullet-proof. To stress my case please consider a straight forward looking documentation of how to implement 802.15.4 Security. It comes with several warnings for implementers and is non-trivial , not even considering handling backward compatibility over different versions of the draft as you do in most cases.
As an industry we have to make a stronger case for security to our customers and take responsibility for our products again. The web has done a “great job” with handing out half-tested freebies asking the community to beta-test their code – only we forget that we paid with our private data so it wasn’t really free and this data without care (it was the company that got something for free not the consumer). In the end I like this old saying: “Nothing is as expensive as free”.
But while taking responsibility we have to also educate users that there will always be bugs. And yes in IoT it might get very ugly for us as an industry if people die. But bugs will not go away, no matter how well we test or how complex we make our processes.
Issues both old and new will continue to creep up. It is not new and has been this way ever since magician and inventor Nevil Maskelyne disrupted John Ambrose Fleming’s public demonstration of a supposedly secure wireless telegraphy technology by sending insulting Morse code messages through the auditorium’s projector.
Security has a long way to go in both camps unfortunately, not just IoT. It’s only since the rise of IoT that we are forced to look at the topic closer. You can consider it as a very long running kind of a technical debt we are finally asked to pay off.
Jacob Katz has summed it up perfectly in a discussion on the LinkedIn IoT Security group and proposed a solution that would force the vendors to claim more responsibility by creating a classification scheme for devices.
Standardizing IoT device safety classification and certification
Unlike web sites and back office systems where the impact of an attack is usually limited to the individuals or corporate that are directly or indirectly involved with the hacked computing resource, most often with reversible results, when it comes to IoT the impact may have immediate, severe and irreversible repercussions on the physical safety and lives of multiple individuals, whether involved with the resource being hacked or not. For example – hijacking multiple connected vehicles using them as weapon in an urban environment will cause the loss of life and destruction of property on a very large scale. It’s not the same as a breach of privacy or a stolen identity where the individual being impacted can eventually recover. I would like to play devil’s advocate for a moment, for argument sake, and present an extreme point of view: The payment industry considers card PIN codes so critical that it is willing to invest millions of dollars in FIPS 140-2 Level 3/4 HSMs alongside expensive compliance and certifications programs. Shouldn’t we treat IoT devices, that can potentially be harmful to people and communities, with the same level of rigor if not more? This means that every IoT device should be formally classified by its potential impact on public safety and require licensing and compliance with certain levels of protection (e.g. class ‘x’ devices must include a FIPS 140-2 level 3 hardware on board, with prescribed key management methodology and compliance program) before they can be commercialized. For some IoT startups/vendors it means going out of business, prohibitively increasing the price of some devices, and it’s going to slow down progress, but it would save public resources dealing with the repercussions of inadequately protected IoT. Is anyone here familiar with a formal safety classification method/program for IoT devices? I’d be happy to hear your opinions on the subject.
So can the industry sort out these issues on their own? Or do we need governments to step in and regulate the safety of our devices and force companies to improve their processes? I’d love to hear your thoughts on the subject.
Valbonne Consulting provides Research & Consulting for emerging technologies in Internet/Web of Things (WoT/IoT/M2M) and Emerging-Tech. We specialise in decentralisation, security and privacy. We work across a variety of traditional industry verticals (Telecommunications, Automotive, Energy, ...). We support Open Source and technologies built on open standards.