A Closer Look at the FTC’s IoT Security Recommendations

We asked a security expert to evaluate the Federal Trade Commission's security guidance for consumer-facing IoT products.
Published: February 11, 2015

Last month, the Federal Trade Commission issued two reports about data security, consumer privacy and the Internet of Things. The main report summarized recommendations resulting from an FTC workshop conducted in 2013, while the second report, titled “Careful Connections: Building Security in the Internet of Things,” is meant to serve as a guidebook for companies developing consumer-facing IoT products.

Don Schleede, information security officer at Digi International, a Minnesota-based manufacturer of embedded systems, as well as routers, gateways and other communications devices for machine-to-machine (M2M) systems, manages Digi’s Device Cloud, a cloud-based device-management solution that provides Digi’s customers with secure, remote access to Digi devices. We asked Schleede to parse the specific guidance that the FTC provided, and to share his views on the approaches to IoT data security that makers of consumer goods—from cars to smart thermostats—have taken thus far.

Don Schleede

The FTC report says that manufacturers of IoT products ought to follow best practices developed by digital security experts throughout the decades, calling out three in particular: the use of encryption, a technique called “salting” and another known as rate limiting. Whether you’re a manufacturer, a reseller or an end user of IoT devices, for commercial or consumer applications, it’s helpful to understand these fundamental IoT security strategies.

Encryption
On encryption, the report’s recommendation is quite simple, urging companies to select strong encryption over weak methods, such as the Wired Equivalent Privacy (WEP) protocol for wireless networks. “WEP has been broken for years,” Schleede says, adding that makers of Internet-connected products ought to use the Advanced Encryption Standard (AES), which the U.S. National Institute of Standards and Technology (NIST) established. “I’d like to have seen NIST standards recommended here,” he said of the report.

Salting
The report reads: “Add ‘salt’ – random data – to hashed data to make it harder for attackers to compromise.” Schleede was somewhat surprised to see the report jump from such a basic mention of “strong encryption,” without specifying standards, to recommending the specific use of salting—the practice of generating random data and adding it to a password, which authorized parties then process using a cryptographic hash function that keeps the original password intact. Hackers cannot easily access a salted password, because they would need both the password and the randomly generated salt data.

Schleede says more general advice would be to use any proper hashing technique to protect passwords, and to ensure that the hardware has the ability to generate random data in order to hash passwords—and to also ensure the information is, indeed, random. Sony made a fundamental error, Schleede explains, when it implemented a password hashing system in its PlayStation consoles, but, in fact, “used a fixed number… not an actual random number.” The system was compromised once hackers discovered that vulnerability.

Rate Limiting
The FTC report reads: “Consider using rate limiting – a system for controlling the traffic sent or received by a network – to reduce the risk of automated attacks. Some scammers try to break into networks by using software that enters possible passwords over and over again until they hit pay dirt.” Rate limiting protects against brute force attacks, and Schleede calls it a great security tool. “There are so many spots where [rate limiting] applies, even beyond user login,” he states. He notes that Digi generally implements rate limiting in the device cloud, rather than at the device level, but that there are some types of hardware functions that should be protected at the device level. For instance, he says, “You want your [Internet-connected] fridge to not be able to be wirelessly set beyond a certain range of temperatures.”

Beyond Best Practices
The FTC report also calls on manufacturers of IoT products to guard against two specific attacks that can be perpetrated through websites: “cross-site scripting (XSS) attacks, where malicious scripts are injected into otherwise trusted websites, and cross-site request forgery (CSRF) attacks, where unauthorized commands are sent from a user the website trusts.”

While Schleede agrees that these are important attacks to defend against, he suggests that companies making IoT products look to the Open Web Application Security Project (OWASP), a nonprofit, vendor-neutral organization focused on educating end users about Web application security, and its Top 10 list of critical Web application security flaws.

Testing device security to root out security weaknesses is another important step in making products secure, and the FTC report specifically highlights a testing technique called fuzzing.

“Fuzzing takes every possible data field that a user can input information into, and it throws garbage in [those fields],” Schleede explains. “If the device is not properly programmed, the device may crash or reboot on its own. In terms of security, this is probably the best way to find [software] vulnerabilities inside a product.” Fuzzing can result in the device no longer responding to commands correctly, or it can corrupt its memory and force it to expose sensitive information, such as user IDs or passwords. “A perfect case of this was the Heartbleed vulnerability that was found on many websites, as well as integrated Web servers in IoT products, late last year. Although it didn’t cause the websites to crash, Heartbleed did force affected devices to dump out memory from the server that should have never been exposed, like user IDs, passwords and sensitive information that the site was collecting. The vulnerability was found using these fuzzing technique and software from a company called
Codenomicon
.”

If the product in question is a fitness band, the dangers of a security weakness are somewhat limited. However, Schleede notes, if the product is an infusion pump or other medical device, the consequences of poor security can be deadly. The good news, he says, is that the U.S. Food and Drug Administration (FDA) has taken a proactive stance by issuing guidance to medical device manufacturers, which requests that the companies submit documentation to the FDA about risks associated with network-connected devices, as well as plans and controls for mitigating those risks.

“I think the FDA is taking a great stance [on security],” Schleede says. “There are known devices out there that have security problems, and companies are starting to fix them.”

Better-Trained Engineers
A major threat that looms around IoT products, Schleede says, and which could be as pervasive as any single vulnerability, is the poor state of security skills among software engineers. “I’m finding that standard [software security] engineering training is really poor in the industry,” he states. “If engineers don’t have good training, they make poor design decisions.”

Plus, even engineers who are properly trained are under tremendous pressure to rush to market with IoT products related to smart homes or health applications, because the competition for consumer attention and dollars is growing more intense each day. “If engineers understood the real risks [of releasing insecure products],” Schleede says, “they could empower themselves and their managers to build better security features” and thus ensure that the products are secure before being released.