Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.
June 29, 2020
As lightbulbs, door locks, garage doors and thermostats get connected and become part of the grander Internet of Things at increasing rates, securing those devices is gradually becoming a priority for the companies making those products and the service providers supporting them.
While a portion of security threats centers on consumer IoT devices, those threats also carry over to IoT components that help to underpin more critical infrastructure tied to telemedicine, telecom networks, streetlights, connected cars and other transportation systems.
To highlight the broad aspects of the issue, FCC Commissioner Jessica Rosenworcel urged the agency last week to apply its device authorization process to IoT security and stay a step ahead of the threat. In testimony for an FCC oversight hearing in the Senate Commerce Committee, she suggested that the FCC reconsider an authorization process for consumer electronics and see if it should also be used to "encourage device manufacturers to build security into new products" as more devices, such as streetlights, parking meters and pallets of equipment become part of the connected world.
To further that idea, she suggested the government expand the National Institutes of Standards and Technology with draft standards that include security recommendations for IoT devices covering areas such as device identification, device configuration, data protection and critical software updates. "In other words, it's a great place to start – and we should do it now," Rosenworcel said.
A big wakeup call on this general issue occurred in 2016 when the Mirai botnet took advantage of millions of insecure IoT devices, including cameras and routers, through commonly used username/password combinations.
That led to the signing of a 2018 cybersecurity law in California requiring manufacturers to equip connected devices with "reasonable" security features that help to prevent unauthorized access and modifications. To eliminate the pervasiveness of generic default passwords that are easy to guess, the bill also mandated that devices come with a unique password or that users must set a new password when the device is first connected.
The Mirai botnet and the subsequent California bill have also spurred the private sector to act and attempt to take on the issue before rules and regulations governing IoT security become overly fragmented.
Big names get behind the ioXT Alliance
One primary example is the Internet of Secure Things (ioXT) Alliance, a group that is developing global IoT security standards that aim to support massive scale. Several big name companies have joined the cause, including Amazon, Comcast, T-Mobile and Google.
ioXT, a group that has about 200 device manufacturers, retailers, network operators and service providers on board, is focused on setting security standards that are testable and scalable and can be harmonized across a wide range of IoT products, according to ioXT Alliance's chief technology officer, Brad Ree.
Though the initial target is to address security standards, including areas like upgradability, for consumer electronics, the initiative itself aims to cover everything from connected light bulbs, set-tops, smartphones and connected cars, he said.
In addition to working with multiple labs to help scale up testing while also addressing customization requirements for different types of IoT devices, the ioXT Alliance will also use a single stamp to identify devices that have passed muster.
Figure 1: The ioXT has created a mark that will identify IoT devices and other products that meet its security standards.
Ree said the initial program is underway with testing portals and a stable of testing labs, with plans to announce the first batch of certified devices sometime in the third quarter of 2020. The ioXT Alliance, he added, is also offering a path for self-testing.
ioXT's intention is to update requirements and procedures on a regular basis as new threats and mitigation measures are discovered. "Security is a process, not a product," Ree said.
Colorado-based CableLabs has also gotten in on the IoT security act with the ongoing development of a "Micronets" framework that rearchitects the home networks into smaller segments that can be managed individually and dynamically. If a device on the network is believed to have been hacked or compromised in some way, the system can isolate and contain the device to limit the damage until the problem can be remedied.
CableLabs said elements of the Micronets initiative are at different stages of adoption and standardization. With respect to providing a secure and easy way to onboard IoT devices, CableLabs said it has participated in and contributed to the WFA Easy Connect specification. A draft spec was published in March. CableLabs says it has also received interest from members and vendors on its SDN-based micro-segmentation, but it couldn't discuss what specific plans are being pursued by members.
The development of Micronets is a "reaction to where we're at today" and a way to solve a short-term security problem, Ree said.
While isolating the network is not a bad practice, Ree questions whether it's a scalable approach. "It puts friction in the way of these interconnections, which is why we really are driving for fixing the security issues upfront," he said.
Are specs and standards enough?
Some cybersecurity experts aren't confident that specifications and frameworks can get a firm handle on IoT security.
Terry Dunlap, chief security officer and co-founder of ReFirm Labs and a former offensive cyber operator for the National Security Agency (NSA), says standards efforts help companies and organizations "check the box" on IoT security, but that they are "meaningless" unless they are also held accountable if something goes awry.
"It's just a CYA tactic that is going to make sure these guys are not held liable if something goes wrong," he said.
Dunlap, whose job was once to target terrorist targets using embedded devices and to find vulnerabilities that could be weaponized, says many of the problems for IoT security can be traced to sloppy coding.
"The flaws we find in IoT devices reminds me of the days of Windows 95," he says, noting that Microsoft has learned from its mistakes and is actually a model citizen with respect to security now. "But with IoT, it's like the Wild West of the early 1990s. It's just sloppy code."
His admitted "radical" remedy is to have IoT developers and coders, particularly for those involved with critical infrastructure such as telecom, nuclear facilities and medical devices, to be licensed and verified on secure coding practices and that they are likewise held accountable if the devices they develop end up being compromised and result in something catastrophic.
Dunlap says he's not a fan of overbearing government intervention, but he believes that government does need to take a role with respect to IoT for critical infrastructure to show companies that this is being taken seriously.
That sort of activity is underway. Notably, the Cyberspace Solarium Commission policy initiative recently recommended Congress pass laws making IoT device manufacturers liable for delivering products with known vulnerabilities.
To highlight its belief that manufacturers need to take IoT security more seriously and elevate it to the level of diligence used for enterprise applications, Dunlap points to a recently issued report from the JSOF search lab on the "Ripple20" bug, which has the potential to compromise hundreds of millions of IoT devices, from printers to insulin pumps to power grids.
"Affected vendors range from one-person boutique shops to Fortune 500 multinational corporations, including HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, Baxter, as well as many other major international vendors suspected of being of vulnerable in medical, transportation, industrial control, enterprise, energy (oil/gas), telecom, retail and commerce, and other industries," the report explained.
The impact of Ripple20 "has the potential to be massive," Dunlap said.
The source of the vulnerabilities comes by way of a widely used low-level TCP/IP software library developed by Treck Inc. The developer has since issued a firmware update to fix the problem and protect devices. But the problem is that some of these vulnerable devices, including some that might be tied into critical infrastructure, can't be updated or aren't even connected at all.
"Most of these devices are sitting in dark closets and corners and haven't had human interaction for years," Dunlap said.
— Jeff Baumgartner, Senior Editor, Light Reading
Senior Editor, Light Reading
Baumgartner also served as Site Editor for Light Reading Cable from 2007-2013. In between his two stints at Light Reading, he led tech coverage for Multichannel News and was a regular contributor to Broadcasting + Cable. Baumgartner was named to the 2018 class of the Cable TV Pioneers.
You May Also Like
Rethinking AIOPs — It's All About the DataMar 12, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Fiddling with Fixed WirelessMar 21, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Cable and 5G: The Odd Couple?Apr 18, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Delivering the DAA DifferenceMay 16, 2024