In addition they need to consider early on what regulations the devices will have to comply with so those requirements can be baked in and not added later when they would be less effective, according to advice delivered at the Security of Things Forum 2015.
Josh Corman, CTO for Sonatype and co-founder of I Am The Cavalry, an industry group urging cyber safety in cars, urged IoT vendors to follow the cavalry’s five-point plan for auto safety.
It encourages: safety from the design phase; encouraging third-party researchers to test systems without threat of legal action; installing data-gathering devices like airplane black boxes to assist forensics; readily downloadable software updates; and segmenting and isolating critical systems from, say, entertainment systems.
While the Five Star Automotive Safety Framework is tailored to motor vehicles, there are lessons there for any networked thing, he says.
An important principle is to think about what happens if the security of a device is breached. “All systems fail,” Corman says, “we just want to be prepared for when they do.”
As sensors – a common category of IoT devices – become embedded in larger systems, such as cars, liability of the manufacturers looms larger, says Andrea Matwyshyn, a professor of law at Northeastern University. If software in IoT devices in cars is exploited to create catastrophic accidents, the liability disclaimers that software developers have been asserting for years may lose their bite, she says.
At the same time, liability laws for physical devices have been carefully thought out over years of case law. Shifting software liability into the realm of physical objects needs to be done conscientiously because it could disrupt the legal balance.
She cited an Oklahoma case where a jury found reckless disregard against Toyota for its electronic acceleration system that jammed and resulted in a fatal accident. As more and more software and computers are added to cars, this type of case and hence potential liability for the quality of the software will become more common. “Software is written by humans,” she says. “Mistakes will happen.”
Architecture considerations should also come into play in designing IoT devices. Makers of IoT devices should think about how their products might be networked and make their communications channels conform to standards friendly to hub-and-spoke networking, says David Miller, CSO of Covisint. That way when a problem arises with a device – or with software or communications channels associated with multiple identical devices – it can be dealt with centrally, making remediation simpler. “It’s easier to fix problems in one place,” he says.
It also limits what other devices each type of device can communicate with, limiting the movement of attackers in a network should they compromise a single device, he says. Connectedness of IoT devices creates risk. “Hackers love connections,” he says. “If I can compromise one thing, I can get the rest.”
Raytheon will commercialize technology for the hardening of IoT devices by tying its software to hardware, says Michael Daly, CTO of Raytheon Cyber. The company has experience in this area due to its military contracts for network-centric warfare gear, such as sensors in tanks and on soldiers. They need to gather data around them but also receive analysis of that data to make it useful. All that must be done securely and with equipment that can’t be turned against the side that deploys it should it be captured, he says.
He recommended that IoT startups walk through the code of whatever open source software they incorporate in their products to make it more secure before they use it.
Chris Rezendes, president of INEX Advisors, a technology intelligence and advisory firm, says startups he’s worked with are shifting their attitudes about securing IoT devices by addressing it early. That’s a change. “Small companies use IoT as an entry point and money is a big problem,” he says, and that used to affect how they treated security. “Trying to get the product to market was more important than having it secure.”
The problem of securing IoT devices was pointed up by a demonstration given by Stacy Cannady, a member of the Trusted Computing Group who works for Cisco. TCG works on hardware security embedded in chips. The problem was that for the sake of expediency, security was less than optimal.
The demo showed how to use the secure chips to connect a Raspberry Pi camera to a server via a Cisco router, all using a TCG Trusted Platform Module, which can tell when files on devices have been altered, signaling the devices are no longer secure.
But the demo relied on allowing the device a one-time free pass to declare its safe state to the router. “Is that a secure way to do it” Cannady says. “No, but it’s pretty darned fast.”
Meanwhile, UL – formerly Underwriters Labs – which sets safety standards for electronic devices, says it is about to step in with safety standards for IoT devices. These could include, for example, standards for augmented-reality glasses that deliver radiation (light) to the retina and could therefore pose a danger to the eye, says Anura Fernando, UL’s principal engineer for medical software and system interoperability.
He says security weaknesses in wearables that are network connected could lead to breaches and elevation of privileges that lead to sensitive data. He echoed the advice that defense in depth is planned from the design phase for these devices.
He says UL is coming up with standards for the design phase to include redundancy and diversity so that if one system fails, a backup that fails differently is in place to take over.
Fernando says the types of regulations devices are subject to can be influenced by the claims made by the companies that make them. A weight-loss product might be regulated by the Food and Drug Administration if it made claims to treat obesity – a medical condition, but not if it claimed to manage weight.
Developers of IoT devices should think about the “problem state” of the device – what happens if someone tries to exploit it – as soon as possible during the design phase. If the device transmits data, developers should consider how it might encrypt that data it to reduce dangers.