I had the great honor to be on a panel discussing IoT Security at the DAC back in June. The panel was part of the Embedded Techcon event that took place essentially as a little embedded corner inside the DAC – it was held in a couple of conference rooms next to the regular DAC sessions, and attendees were also mostly attending the DAC in general. Not a bad idea for meshing embedded and hardware design. The panel was a great one, and David Kleidermacher from Blackberry gave me a great take-away: unless security is allowed to gate releases of products, it is hard to think you take security seriously.
On the panel, we had David Kleidermacher who is now the chief (product) security officer at Blackberry – even if most of us in the industry remember him as a Green Hills guy. Also, Skip Ashton, VP of Software Engineering at Silicon Laboratories, Gary Davis, Chief Consumer Security Evangelist at Intel Security, Eran Briman, VP of Marketing at CEVA, and I. A good mix of security people, hardware designers, and embedded software. Patrick Mannion from ClariTek did an excellent job of moderating the panel and getting interesting discussions going. There was always a risk that this would be one of those boring panels where everyone just agrees – after all, how could you not agree to the idea that security is needed for IoT – but Patrick kept it interesting by looking at various aspects and angles. Good job!
The “IoT” that we discussed was depicted from the consumer electronics perspective: cloud-mobile phone-smart devices. Which is actually structurally almost identical to the industrial perspective that I tend to have, with cloud-gateway-sensor nodes. The main difference I guess is in the fact that the mobile phone is much harder to lock down than a well-managed gateway – hopefully, an industrial admin will be less prone to installing random apps with possible back doors on their gateways.
So what was discussed?
Security versus time-to-market and ease of use – it is clear that in most cases, time-to-market, cool features, and ease of installation and use beats security concerns in the product design and marketing process. There is simply no attempt made to think things through properly and design a solid system. The market right now rewards cool features over solid security, that’s the way things unfortunately are. As long as consumers don’t have security as an important buying criterion, and there are no real legal or monetary penalties for companies that suffer security breaches or provide the products that inadvertently compromised their customer’s security, there just isn’t the incentive to really make security a core company value. Some kind of regulation or legal regime is needed here to force security into being something that hurts the bottom line if not done correctly.
Not to say that there aren’t companies that do value building solid and secure products. Blackberry is one such company, and David Kleidermacher made the very good point that an indicator for just how serious it is, is that the security team in the company has the right to stop a release if they find a security flaw. That is really the best indicator that I have ever heard of for when a company takes security in its products seriously. As a product manager, I can definitely see the depth and importance of this seemingly simple statement. Today, in most cases you have checklists for new products that include things like “open source licenses correctly listed” and “no blocking bugs left in the product” and “price list set and ready to sell from”. Adding “no known security issues” or “correctly used secure development process” to that list is a statement from the organization to all its members that security is important. This is a simple but profound concept.
Different levels of criticality. Intuitively, a remote-controlled light bulb is a less critical piece of kit compared to a smart door lock that can unlock your front door. The problem today, however, is that a network (the wireless network inside a home, for example) is only as secure as the weakest entry point. Thus, a hack on that silly cheap light bulb might not just be a nuisance, but it could also compromise the entire network to which they are connected and allow hackers a way in to attack really valuable things on the network, computers and more important home automation systems. It would be nice if it was possible to cordon off unimportant functions from important functions – like the thinking behind MILS operating systems. It would be nice to have similar layers in a home network, or simply separate networks for different functions. A bit harder to set up, but maybe that is what’s needed?
Another thought is that Internet-connected things cannot be allowed to be too cheap… they need some basic level of soundness and some basic level of installation complexity in order to stop stupid mistakes. So maybe a basic safety regulation is needed that all products must pass, like CE marks?
We touched communications security several times, and the panel agreed that you should rely on existing proven protocols. The computer science and computer security community know how to do secure connections, and there is little point in investing new protocols or communications methods. Home-made crypto is never good. That said, the compute power needed to run Internet-style protocols might be a bit much for a small microcontroller.
There was also a discussion around security standards. While it is hard to tell that whether security standards like the Common Criteria actually improve overall security, at least they provide a basis for asking for secure systems from providers. They can be useful to drive the discussion and direction of products, even if they do not help you actually build better products per se. Dave was particularly strong in promoting the idea of standards, and I am willing to believe that he is right. The contents of such IoT security standards will be interesting to work out, though.
I also brought up my favorite topic of evil testing – one important part of security is to make sure someone evaluates products with the intention to find the flaws and potential security issues in them. Not just for their happy-case functionality. The kind of security team that Dave heads up at Blackberry sounds like it is in the right general direction; we need people tasked to break things. And who get rewarded and appreciated for doing so.