'Cause they need somewhere to load in those exploits!
A hypothetical device which is all read-only (except perhaps for a very carefully crafted, limited set of configurable parameters) might in some cases be more secure than the bulk of what's on the shelves today. After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only').
Some things to realize about read-only devices is that once they are cracked, they are cracked forever. The devs have dev time to secure the device, the hackers have infinite time to crack it. Once done, the game is up. All instances are now easily exploited.
The more popular the device, the more knowable upside to an exploit. If the device can be updated, then usually the exploitable timeframe is limited and its unknown if the attempt is even worthwhile.
> After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only').
Well basically because any device of consequence is trivially hacked by now. Think about game consoles or anything that would have DRM today.
Sure. But how the firmware process functions matters.
There's a world of difference between remotely initated OTA over the interent vs flashing it locally via a USB drive or microSD card. You know like PC motherboards keep working for decades now. They are effectively read-only under normal use and need to have a certain reboot sequence (BIOS/UEFI fw admin) to unlock flashing. Or maybe even load firmware from a preinstalled SD card which makes swapping easy.
Or if you really need to be fancy wity remote updates: at least require the push of a physical button to allow flashing remotely.
A really dumb camera that just has an interface that's polled for data by a remote host is more likely to be used in a secure way than a 'smart' camera that tries to remember state and talk to an external server itself.
So don't put them on the open Internet. It's much easier to do that than it is to secure a device that creates outbound connections to some untrusted external server (which manufacturers are). If it doesn't try to use UPnP or anything, it will not be in the open by default.
If your threat model for consumer IoT devices does not include manufacturers in 2025, you are completely confused about computer security. Having a standard to encourage devices to talk to manufacturers is completely backwards. We should have certifications that devices create no outbound TCP/UDP flows.
I do not know for sure whether these devices use UPnP or similar, but considering that they are not intended to be accessible from the Internet, probably not. The blame probably lies with (in this case) all the random government agencies deploying the devices in an insecure way. But assigning blame won’t fix the problem. Something needs to change, and it’s probably going to be the devices.
Consumer devices are different. On one hand, they’re less likely to be exposed to the public Internet… at least proportionally. I think. But on the other hand, consumers expect to be able to access their devices from anywhere, and right now in practice that means going through a manufacturer-controlled proxy server. I would love if someone would come up with a standardized mechanism to make home devices securely remotely accessible, without a manufacturer-controlled proxy, but just as easy to use as the status quo. Until that happens, don’t expect anything to change.
That's a valid answer for an audience familiar with computer networking concepts. It's a silly suggestion for consumer IoT customers, who do not understand those concepts. They don't know what is or is not 'on the open internet'; they buy a product at the store and plug it in.
> We should have certifications that devices create no outbound TCP/UDP flows.
This is the "bury your head in the sand" method of solving the problem. If you design your requirement so that zero consumer accessible devices are capable of meeting them, then what's the point? As long as people (1) want to watch their camera away from home, and (2) don't have the networking expertise to configure a remote access VPN tunnel, the devices are going to have to reach outbound to traverse home router firewalls.
IoT customers by default would not have devices exposed to the Internet. This has been the status quo for decades ever since wifi and NAT became popular. If they don't understand it, it will be secure by default.
It would be technically quite easy for either a dedicated home-access box or just the router-AP combo box to have some auto-config wireguard setup (e.g. scan a QR code or install an app that looks for the box on the local network or through bluetooth). This would be far more secure than the current setup, which is for devices to constantly connect to generally malicious C&C servers. If regulations pushed for actual security (no-cloud), this would be the obvious solution to guide to market toward. Then you only have to trust your gateway device, which also would have no reason to ever create outgoing Internet connections, though it would need outgoing/forwarded LAN connections.
With SLAAC to generate a random initial IPv6 address that it never rotates combined with UDP so there's no indication that you talked to anything if your wireguard keys are wrong, there's basically no way to find such a box if you didn't have the correct config.
> IoT customers by default would not have devices exposed to the Internet. This has been the status quo for decades ever since wifi and NAT became popular. If they don't understand it, it will be secure by default.
Because IoT devices have historically been known as secure? Definitely not. Devices that presume someone else has already configured a firewall correctly often presume wrong. Consumers are not networking professionals.
> It would be technically quite easy for either a dedicated home-access box or just the router-AP combo box to have some auto-config wireguard setup
Well yeah, if everything about home networks was different, then the situation would be different. The problem is, that isn't the reality in which IoT devices are manufactured.
> If regulations pushed for actual security (no-cloud), this would be the obvious solution to market.
If they pushed for this, the only solutions with the sticker would be ones that are commercial failures because they won't work out of the box with the router people actually have at their house. You may be 'right' but your labelling program will have failed. A labelling program has to be realistically achievable within the current reality to have any effect, otherwise it'll just be ignored by manufacturers.
Incremental improvements, such as this, are not bad, even if not perfect. People are going to buy doorbell cameras that connect outbound to the internet, because the technology works out of the box.
If only every human was an omniscient and perfectly rational actor with infinite time to become network security professionals and infinite budget to implement their perfect security boundary
Most software vulnerabilities aren't intentionally added backdoors, but flaws in the software that shipped on a device.
> After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only').
Quite a lot -- these are some of the easiest devices to hack. The only saving grace is that most of them are not connected to the internet so they are only vulnerable to local attacks. But garage doors, cordless phones, keyless entry, smart locks, smart home protocols, etc are notoriously vulnerable.
The reason you don't hear about new vulnerabilities each week is precisely because they're aren't updatable. The fact that they don't get updates with new vulnerabilities is not an advantage when they permanently have older vulnerabilities.
> Most software vulnerabilities aren't intentionally added backdoors, but flaws in the software that shipped on a device.
Disagree, it is extremely common for e.g. TVs and smart phones to ship with malware included. In fact it is almost impossible to buy some classes of devices that aren't intentionally compromised.
Having the thing never connect to the Internet at all and never receive updates is a far better security posture, and is the common recommendation among knowledgeable people for e.g. TVs.
In practice, your neighbors are almost certainly quite a bit less malicious than whatever a smart device might talk to on the Internet. Your neighbor isn't going to hack your cordless phone. Your TV manufacture is definitely going to drop malware onto it, disable functionality (i.e. damage it), etc.
Any sort of warranty or security representation is basically snake oil except in a very narrow set of circumstances and conditions, yet still not 100%. If Apple can't keep iPhones 100% locked down, with billions of security spend, no fucking way some government program is going to authentic security across a wide variety of devices or various hardware & software qualities.
One thing the government can or perhaps should mandate, and is easily verifiable, is kill switches - devices should be physically incapable of connecting to any wireless network when a kill switch is engaged. If the FTC or a trade regulator wants to regulate at another level, maybe they could also say certain classes of devices must continue to function when disconnection (I might want the Apple TV plugged in to the TV connected to the internet, but the TV itself totally disconnected.) Because some devices now will surreptitiously search for open WiFi networks and try to go online even if a user does not connect via WiFi, this seems reasonable.
If we go down the route of a government agency creating and mandating security,
#1 Government back doors will persist and perhaps even be required (relevant to the whole TikTok thing this week.)
#2 They will be unable to quickly respond to new threat surfaces while still representing that whatever is present is secure (it isn't.)
> Most software vulnerabilities aren't intentionally added backdoors
>it is extremely common for e.g. TVs and smart phones to ship with malware included
These aren't mutually exclusive. With that being said, I'm probably with you when it comes to the overall debate. For something to get exploited it needs a vulnerability and a means to exploit it. The most insecure device in the world can't be exploited if I'm the only one who ahs the means to do it. Unfortunately we live in a world where Zawinski's Law has itself expanded such that everyone wants to be able to access everything from everywhere, which rules out airgapping a lot of devices. It's a consumer economy - we have to build what people want and then secure it. We don't have the luxury of building secure things and then convincing people to want them.
> Disagree, it is extremely common for e.g. TVs and smart phones to ship with malware included.
Both are common! But there are many hundreds of thousands of known software vulnerabilities.
> Having the thing never connect to the Internet at all and never receive updates is a far better security posture
It might be, depending on the particular situation. But it doesn’t really matter for IoT devices, because they all, by definition, connect to the internet. “Don’t connect to the internet” is a nonsensical suggestion for IoT devices.
An interesting thought is how when devices couldn't auto-update, they had to work out the gate. I imagine this encouraged companies to do much better testing to reach a gold-plate before deploying.
Assuming these are network devices - it can be harder to certify future working if the network services they rely on become unavailable or when the failure only occurs at scale.
Case in point when 700,000 Netgear routers pinged the University of Wisconsin–Madison NTP server (harcoded IP address) every second.
Less critical, but video games are the same way. Companies will press and ship discs with known broken games and then issue a patch of dozens of GBs day one. The whole point of having a disc is when all the servers are off line, and the store have shut down, the game is still playable.
This is true, but mostly only relevant to the expected user functionality. User acceptance testing in waterfall development doesn't often identify security vulnerabilities.
Yep! My Insteon home automation devices have no firmware update capabilities. They also have an extremely simple local RF protocol. They allow smart device behavior but are too stupid to be "compromised".
It's proprietary but relatively easy to reverse engineer, the details are out there. In the US it uses like 914.5 MHz or something, and I can send instructions to devices with an extremely simple serial protocol on my computer.
No Bluetooth, no Wi-Fi, no protocol sophisticated enough to distribute code. Just locally transmitted instructions.
Do they require auth and use solid crypto? If not, they are vulnerable, it's just that the vulnerability requires the attacker to be within range.
People thought old analog 900mhz cordless phones were fine until others realized you could just tune a radio to that freq and listen to your neighbors.
They're not vulnerable in any way that matters. If you manage to get a device in range you can... turn my lights on and off? You can't program them to do malicious things over the Internet. They don't have any sensitive information you can access. There's no damage you can do them.
The problem with saying you need auth and crypto is now you just added a bunch of complexity you have to maintain and update and hence now you've introduced vulnerabilities.
Sure, keeping things offline and vulnerable to only local attackers is a valid security posture for some.
But the 'I' in IoT is for internet. "Don't build IoT devices" is not a helpful proposal to increase the security of IoT devices, which is the scope of this initiative.
Eh. Debateable. I can control them over the Internet, I am just not delegating Internet access directly to cheap consumer electronics, which simply put, shouldn't be done.
I would argue the crisis of IoT security is caused largely by poor IoT design.
> I am just not delegating Internet access directly to cheap consumer electronics, which simply put, shouldn't be done.
Yeah, but most people are going to do that. Most people aren't security-conscious professionals, and they do like cheap things.
In a hypothetical reality where home networks were better designed to accommodate remote access, we wouldn't have this problem. And for those of us who can configure networks to be securely accessed remotely, there are definitely better ways to do things.
But that isn't the reality of the landscape of consumer IoT -- which is that people expect to buy a cheap device, connect it to the wifi network of any consumer wifi router, and have it work out of the box. They are already buying these devices regardless of whether they are secure, and will continue to do so. This initiative is about encouraging reasonable incremental changes to the existing reality.
If the requirements for this label were drastic enough that they required people to secure the devices behind behind a firewall, store data locally, and provide remote access only with an inbound VPN or something like that, it would simply be ignored by manufacturers and would have zero impact. Because vanishingly few people are going to replace their Comcast modem/router just to install some IoT device. To most people, they "get wifi" from their ISP. The concept of "reconfiguring a home network" is a nonstarter. Whatever the ISP provides is what normal people use, by default.
You missed my point. On the contrary, having every light switch in the house need its own network stack is not just insecure, it's overengineered and expensive.
It's fine to have a computer or "gateway" device that calls outbound to a server for outside access, no firewall rules or VPN required. The point is there should only be one point of contact with the outside world, and that's a tech device with enough power to update, secure, etc. As Wi-Fi standards and such change, people should expect to replace it.
Hardware in and on your walls should be dumb, cheap, and long-lasting. Insteon's technology hasn't substantially changed in twenty years, most of my smarthome hardware is over ten years old, and is no less secure or current than when I installed it. And of course, all of it works just like a "dumb" counterpart when the Internet is down or there's no smarthome controller involved. This should be cheaper at scale than "wi-fi smart outlets", if they aren't selling your data to offset the cost.
I understand your point, it's just not relevant. Consumers aren't doing any of that, nor are they going to. Expecting consumers to buy smart-home devices as a whole system and integrate it into their structure is just not practical. The barriers to entry are too high.
I'm glad you bought up Insteon. They're a great example of this, they failed commercially.
I understand the benefits to the architecture you're advocating for. Personally, I started with X10 in 1995. But that simply isn't what people buy anymore. People are buying individual smart-home products, not integrated systems.
The requirements of this program are to address the reality of the types of devices people are actually buying, and the security concerns that affect them.
I mean, fwiw, Insteon is in business today as a new entity. They're producing new hardware and all. It's viable enough a technology to have survived business issues that killed the company.
I disagree with your assumption you understand consumers: Many prefer to buy all products from unified systems, and the complaints about how disconnected and disjointed having odds and ends are have led to Matter, which is struggling to solve the problem.
The major players have all sold home automation hubs, and a lot of solutions still use them, but a lot of the hardware is still overengineered, has a short usable life, and creates security risks.
So the highest risk device on my RF network is my thermostat. But not only do I get alerts for out of range conditions, the beauty of the local attacker model is most types of attacks become silly: The thermostat has a predefined range of relatively normal temperatures, so the only way to really cause damage is turning it off.
You could bring a custom-programmed RF transceiver and plant it on my property for the job, or you could use a $5 wrench to shut off my natural gas and pull the power shutoff on my AC condenser.
this is a great example of defense in depth. there are several factors limiting how vulnerable the device is and what can actually be done with it once exploited.
> After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only').
Tons and tons? I don't understand this viewpoint at all. As the saying goes "There is no 'Internet of Things', just an Internet of unpatched Linux devices." That is, the primary vector for malware is devices that aren't (or can't) be patched after vulnerabilities are discovered.
'Cause they need somewhere to load in those exploits!
A hypothetical device which is all read-only (except perhaps for a very carefully crafted, limited set of configurable parameters) might in some cases be more secure than the bulk of what's on the shelves today. After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only').