IoT Working Group Crafts Framework For Security, Privacy

An industry working group that includes members from Microsoft, Symantec, Target, and home security system vendor ADT today issued draft recommendations for locking down the privacy and security of home automation and consumer health and fitness wearable devices with security practices such as unique passwords, end-to-end encryption of sensitive and personal information, and a coordinated patching and update mechanism, as well as other measures.

The Online Trust Alliance (OTA) Internet of Things Working Group hopes that IoT manufacturers, developers, and retailers will adopt the proposed guidelines, and is asking for industry input.

But the catch is that the embedded firmware in many IoT devices is not necessarily patchable, nor does the consumer device manufacturer necessarily have control or say over the security of the firmware it embeds in its products.

And as demonstrated in the recent hacking of the Jeep Cherokee where researchers were able to control the vehicle's steering, braking, and other features, the supply chain can be the weakest link. In the Fiat Chrysler case, it was a vulnerable communications port that was left wide open in the Harman uConnect infotainment system installed in the vehicles: cellular provider Sprint subsequently shut down the 6667 port, which the researchers used to access the Jeep's controls.

"It is a supply chain issue. If you look at the device, you are getting off-the-shelf firmware. How can you update it? Can you?" says Craig Spiezle, executive director and president of  OTA, says of home automation and consumer wearable devices. "Embedded firmware is a concern--we highlighted this [in the framework]. We're aren't quite sure how best to do this: if that firmware can't be upgraded without a service technician coming out [to do it, for example] … How is that handled over time?"

The framework calls for IoT makers to have the ability to fix bugs quickly and reliably via remote updates or other notifications to consumers -- or even device replacement, if needed. And that item comes with this caveat: "It is recognized that some embedded devices' current design may not have this capability and it is recommended such update/upgradability capabilities be clarified to the consumer in advance of purchase."

Time is another factor with IoT devices. Networked thermostats, garage-door openers, and other in-home devices change hands when the house does, but the former residents could still have access. And what happens after a warranty expires on smart device and there's a breach, Spiezle says.

"We talk about not just security, privacy, and disclosure of the data that's collected, but also the lifecycle issues. How do they support [these devices] over time and beyond the warranty," he says.

The working group plans to finalize a formal IoT framework -- which includes some 22 minimum requirements plus a dozen optional additional measures -- and program around mid-November, after gathering input from Congress, the White House, Federal Trade Commission, and other entities.

Brian Knopf, an IoT security expert, says when he worked at Belkin, dealing with vulnerabilities in OEM'ed chipsets and firmware for its products was a big challenge. "We were not able to get access to their [the OEM's] code" if there was a bug discovery in the Belkin device, he says. "We were under NDA" due to their supplier relationship, he says.

That was problematic because an SDK from the chipset manufacturer often gets shipped with manufacturer backdoors and command-line interfaces, for instance, left there purposely, according to Knopf, a speaker last week at the first-ever IoT Village at DEF CON 23, and the former principal security advisor and researcher at Wink Inc.

But IoT vendors can avoid these issues at the get-go, says Nicholas Percoco, vice president of global services at Rapid7. "One approach they can take is get a bunch of OEM components, slap them together and sell it," he says.

A better approach would be to spell out the vulnerability issue with a firmware supplier in advance, Percoco says. "How do we get updates, what SLA [service level agreements] are for getting updates."

But the reality is that consumer IoT devices such as baby monitors come with very old versions of the Linux kernel and Open SSL, for example, Percoco says. "Is that poor systems development or being negligent? How hard is it to get the latest version of OpenSSL?"

Building Security Into IoT

IoT security isn't all about patching, however. The IoT software and firmware suppliers can take a page from the book of other applications, namely Windows-based ones, for example, and incorporate attack mitigation techniques such as Address Space Layout Randomization (ASLR), says Jacob Holcomb, senior security analyst with Independent Security Evaluators and one of the organizers of the DEF CON IoT Village.

Holcomb suggests adding ASLR or other protections such as inserting so-called canary values, which would protect the firmware form overflow attacks. "The overflow would terminate before it was exploited," he says.