A couple of spirited panels on IoT security capped off the MIT Enterprise Forum’s Connected Things event on March 13. What set these and other discussions throughout the day apart from a lot of events I go to is that they went beyond treating IoT security as a monolithic thing. They also exposed some of the genuine tradeoffs involved in securing devices, especially outside of managed industrial IoT environments.
I’ve attended this event before and it’s different in that the organizers manage to keep topics pretty tightly focused on what the master of ceremonies called “the serious internet-of-things.” He may have been half-joking but, as Harel Kodesh, the VP of Predix and CTO of GE Digital, noted in his keynote, industrial IoT really is different from smart home, wearables and other consumer tech. There’s much larger data volume, multilayer security, customer-focused storage and proactive compute at the edge. “With respect to security specifically, you might have six or seven different layers between the sensor and the back end. The security architecture is such that every layer assumes every other layer is breached,” Kodesh said.
At Connected Things 2016 last year, MIT’s Sanjay Sarma was downright pessimistic about IoT security: “We have a disaster on our hands. We’ll see a couple power plants go down. Security cannot be an afterthought. I’m terrified of this.”
However, this year, the moderator of the smart city security panel, Andy Chatha, observed, “How do you protect your plants against cyberattacks? Don’t connect them to the internet.”
Chris Walcutt of Black and Veatch added that it’s really about having a consistent programmatic approach. You have to start by characterizing what you’re going to connect to the network. Is it critical? Because this drives what you ask for. How much are you going to spend to protect an asset? He also noted that “a lot of the physical security practices for alarming and alerting are established in other areas. But you also can’t overwhelm people with the amount of data or alerts.”
Who does a security vulnerability affect?
We tend to think of a security breach as most affecting the owner of the device that’s been hacked. But that won’t always be the case.
For example, something like Target’s 2013 data breach was certainly inconvenient to millions of customers, but it was arguably even more harmful to the company itself; other types of attacks might provide a path through a firewall to a vendor’s back-end systems. On the other hand, in many cases, exposing a video feed or sensor data to an intruder often won’t cause the owner of that sensor any direct harm. However, the Mirai botnet’s DDoS attack caused significant disruption to the internet as a whole, the “ecosystem” as one panelist characterized it.
Moving forward with security
This idea that security breaches can be (and have been) harmful to a broader ecosystem is steering discussions into a few separate but related streams.
The first is to think about security systematically in those situations (typically industrial and other commercial uses) where devices are managed and the manufacturer presumably has a formal responsibility for ongoing updates and patches and maintains some sort of control. Brandon Freeman of Leidos said that there are two questions that he always asks suppliers, “What’s your lifecycle update process? When have you pen [penetration] tested the device?”
The second is to acknowledge that low-cost, whether consumer or industrial, endpoint devices are going to be problematic to secure. I made this point recently and it was echoed by a number of speakers throughout the day; it’s just not viable economically to expect updates of essentially disposable devices. (Which is especially problematic when you have devices that have essentially consumer-grade security but are likely to be long-lived, such as light switches.)
However, the economics of security aside, the back and forth during the last panel highlighted that, using current approaches, there’s just an unresolvable conflict between simplicity and security. As United Technologies’ Isaac Chute put it, “Should we be doing some things differently? It comes down to having a different trust model. Things are too complex for the average person.”
What does that look like? No one’s sure. There was perhaps some agreement on what are not good practices. Tatu Ylonen, the founder of SSH Communications Security, highlighted how “one root cause for some of the worst problems are default passwords.” He added that he “personally thinks this is a product liability.” While doing things like using serial numbers or some other unique identifier as a password was raised as one option, there was also a consensus that configuring devices is probably too complicated as it is. Andy Ellis of Akamai asked, “Should we be using passwords at all in things like lightbulbs?”
The day didn’t end with definitive solutions for all this. However, I did have a few takeaways:
- In industrial settings, apply many of the security practices that you should already be following. Talk with your vendors about their security processes, both with respect to securing their software supply chains and managing product security over a lifecycle.
- Know what assets you are connecting and how — and the impact of a security breach.
- Be realistic about maintaining security when connecting endpoint devices directly to the internet and consider alternative architectural approaches that use gateways or isolate by other means.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.