It is newly minted conventional wisdom that not a single information security conference goes by without a presentation about the abysmal state of Internet of Things security. While this is a boon for researchers looking to make a name for themselves, this sorry state of affairs is definitely not beneficial for anyone who owns a connected device.
IoT device owners aren’t the only ones fed up, though. Right behind them is Eldridge Alexander, manager of Duo Labs at
Duo Security. Even better, he has a plan, and the experience to lend it some credibility.
Before assuming his current role at Duo Security, Alexander held various IT posts at Google and Cloudflare. For him, the through-line that ties together his past and present IT work is the security gains that accrue from aligning all of a network’s security controls with the principle of zero-trust.
“I’ve basically been living and breathing zero-trust for the last several years,” Alexander told LinuxInsider.
Simply put, “zero-trust” is the idea that to the furthest extent possible, devices should not be trusted to be secure, and they should be treated as such. There are many ways zero-trust can manifest, as it is not so much a singular technique as a guiding principle, but the idea is to leave yourself as invulnerable to the compromise of any one device as possible.
A recurring theme among his past few employers, this understandably has left its mark on Alexander, to the point where it positively permeates his plan for IoT security on home networks. His zeal for zero-trust comes to home networks at just the right time.
Although consumer IoT adoption
has been accelerating, zero-trust has yet to factor into most consumer networking tech, Alexander observed, and we’re getting to the point where we can’t afford for it not to.
“Investigating not really new threats but increased amount of threats in IoT and home networks, I’ve been really interested in seeing how we could apply some of these very enterprise-focused principles and philosophies to home networks,” he noted.
In Alexander’s home IoT security schema, which he unveiled at Chicago’s THOTCON hacking conference this spring, zero-trust chiefly takes the form of network segmentation, a practice which enterprise networks long have relied on.
In particular, he advocates for router manufacturers to provide a way for home users to create two separate SSIDs (one for each segment) either automatically or with a simple user-driven GUI, akin to the one already included for basic network provisioning (think your 192.168.1.1 Web GUI).
One would be the exclusive host for desktop and mobile end-user devices, while the other would contain only the home’s IoT devices, and never the twain shall meet.
Critically, Alexander’s solution largely bypasses the IoT manufacturers themselves, which is by design. It’s not because IoT manufacturers should be exempted from improving their development practices — on the contrary, they should be expected to do their part. It’s because they haven’t proven able to move fast enough to meet consumer security needs.
“My thoughts and talk here is kind of in response to our current state of the world, and my expectations of any hope for the IoT manufacturers is long term, whereas for router manufacturers and home network equipment it is more short term,” he said.
Router manufacturers have been much more responsive to consumer security needs, in Alexander’s view. However, anyone who has ever tried updating router firmware can point to the minimal attention these incremental patches often receive from developers as a counterclaim.
Aside from that issue, router manufacturers typically integrate new features like updated 802.11 and WPA specifications fairly quickly, if for no other reason than to give consumers the latest and greatest tech.
“I think a lot of [router] companies are going to be open to implementing good, secure things, because they know as well as the security community does … that these IoT devices aren’t going to get better, and these are going to be threats to our networks,” Alexander said.
So how would home routers actually implement network segmentation in practice? According to Alexander’s vision, unless confident consumers wanted to strike out on their own and tackle advanced configuration options, their router simply would establish two SSIDs on router setup. In describing this scenario, he dubbed the SSIDs “Eldridge” and “Eldridge IoT,” along the lines of the more traditional “Home” and “Home-Guest” convention.
The two SSIDs are just the initial and most visible (to the consumer) part of the structure. The real power comes from the deployment of VLANs respective to each SSID. The one containing the IoT devices, “Eldridge IoT” in this case, would not allow devices on it to send any packets to the primary VLAN (on “Eldridge”).
Meanwhile, the primary VLAN either would be allowed to communicate with the IoT VLAN directly or, preferably, would relay commands through an IoT configuration and management service on the router itself. This latter management service also could take care of basic IoT device setup to obviate as much direct user intervention as possible.
The router “would also spin up an app service such as Mozilla Web Things or Home Assistant, or something custom by the vendor, and it would make that be the proxy gateway,” Alexander said. “You would rarely need to actually talk from the primary Eldridge VLAN over into the Eldridge IoT VLAN. You would actually just talk to the Web interface that would then communicate over to the IoT VLAN on your behalf.”
By creating a distinct VLAN exclusively for IoT devices, this configuration would insulate home user laptops, smartphones, and other sensitive devices on the primary VLAN from compromise of one of their IoT devices. This is because any rogue IoT device would be blocked from sending any packets to the primary VLAN at the data link layer of the OSI pyramid, which it should have no easy way to circumvent.
It would be in router manufacturers’ interests to enable this functionality, said Alexander, since it would offer them a signature feature. If bundled in a home router, it would provide consumers with a security feature that a growing number of them actually would benefit from, all while asking very little of them in the way of technical expertise. It ostensibly would be turned on along with the router.
“I think that’s a valuable incentive to the router manufacturers for distinguishing themselves in a crowded marketplace,” Alexander said. “Between Linksys and Belkin and some of the other manufacturers, there’s not a whole lot of [distinction] between pricing, so offering home assistant and security is a great [distinction] that they could potentially use.”
IoT Security Standards?
There is some promise in these proposed security controls, but it’s doubtful that router manufacturers actually would equip consumer routers to deliver them, said Shawn Davis, director of forensics at
Edelson and adjunct industry professor at the Illinois Institute of Technology.
Specifically, VLAN tagging is not supported in almost any home router devices on the market, he told LinuxInsider, and segmenting IoT from the primary network would be impossible without it.
“Most router manufacturers at the consumer level don’t support reading VLAN tags, and most IoT devices don’t support VLAN tagging, unfortunately,” Davis said.
“They both could easily bake in that functionality at the software level. Then, if all IoT manufacturers could agree to tag all IoT devices with a particular VLAN ID, and all consumer routers could agree to route that particular tag straight to the Internet, that could be an easy way for consumers to have all of their IoT devices automatically isolated from their personal devices,” he explained.
VLAN tagging is not restricted by any hardware limitations, as Davis pointed out, but is merely a matter of enabling the software to handle it. Just because the manufacturers can switch on VLAN tagging in software, that doesn’t mean it will be an easy matter to convince them to do so.
It’s unlikely that router manufacturers will be willing to do so for their home router lines and, unsurprisingly, it has to do with money, he said.
“A lot of the major companies produce consumer as well as corporate routers,” Davis noted. “I think they could easily include VLAN functionality in consumer routers but often don’t in order to justify the cost increase for feature-rich business level hardware.”
Most router manufacturers see advanced functionality like VLAN tagging as meriting enterprise pricing due to the careful development that it requires to meet businesses’ stricter operational requirements. On top of that, considering the low average technical literacy of home users, router manufacturers have reason to think that power user features in home routers simply wouldn’t be used, or would be misconfigured.
“Aside from the pricing tier differences,” Davis said, “they also might be thinking, ‘Well, if we bake in VLANs and other enterprise-based features, most consumers might not even know how to configure them, so why even bother?'”
Beyond cajoling router makers to enable VLAN tagging and any other enterprise-grade features needed to realize Alexander’s setup, success also would hinge on each manufacturer’s implementation of the features, both in form and function, Davis emphasized.
“I think each manufacturer would have different flows in their GUIs for setting up isolated VLANs, which wouldn’t be the easiest for consumers to follow when switching across different brands,” he said. “I think if IoT security was more standards-based or automatic by default between devices and routers, overall security in consumer devices would greatly improve.”
Securing both of these concessions from router manufacturers would likely come down to ratifying standards across the industry, whether formally or informally, as Davis sees it.
“The different standards boards could potentially get together and try to pitch an IoT security standard to the router and IoT device manufacturers, and try to get them to include it in their products,” he said. “Aside from a new standard, there could potentially be a consortium where a few of the major manufacturers include advanced IoT device isolation in the hopes that others would follow suit.”
Alexander’s THOTCON presentation touched on the 5G connectivity that
many predict IoT will integrate, but in exploring the viability of alternatives to his setup, Davis quickly gravitated toward Alexander’s proposal.
Connecting to IoT devices via 5G certainly would keep them away from home users’ laptop- and smartphone-bearing networks, Davis acknowledged, but it would present other challenges. As anyone who has ever browsed
Shodan can tell you, always-on devices with seldom-changed default credentials connected directly to the public Internet have their downsides.
“Having your IoT devices isolated with your home-based devices is great, but there is still the possibly of the IoT devices being compromised,” Davis said. “If they are publicly accessible and have default credentials, they could then be used in DDoS attacks.”
Enabling IoT for direct 5G Internet connections doesn’t necessarily improve the security of end-user devices, Davis cautioned. IoT owners will still need to send commands to their IoT devices from their laptops or smartphones, and all 5G does is change the protocol that is employed for doing so.
“IoT devices using cellular 4G or 5G connections are another method of isolation,” he said, “but keep in mind, then the devices are relying even more on ZigBee, Z-Wave or Bluetooth Low Energy to communicate with other IoT devices in a home, which can lead to other security issues within those wireless protocols.”
Indeed, Bluetooth Low Energy
has its share of flaws, and at the end of the day protocols don’t impact security as much as the security of the devices that speak it.
Regardless of how the information security community chooses to proceed, it is constructive to look to other points in the connectivity pipeline between IoT devices and user access to them for areas where attack surfaces can be reduced. Especially when weighed against the ease of inclusion for the necessary software, router manufacturers undoubtedly can do more to protect users in cases where IoT largely hasn’t so far.
“I think a lot of the security burden is falling on the consumer who simply wants to plug in their device and not have to configure any particular security features,” Davis said. “I think the IoT device manufacturers and the consumer router and access point manufacturers can do a lot more to try to automatically secure devices and help consumers secure their networks.”