[beams_of_light]

Things like this are useless, in my mind, because hackers are always going to innovate and find ways around protection mechanisms. Today's "locked down" IoT device could easily become tomorrow's "vulnerable to an easily exploitable pre-auth RCE".

What the government probably _should_ do is begin establishing a record of manufacturers/vendors which indicates how secure their products have been over a long period of time with an indication of how secure and consumer-friendly their products should be considered in the future. This would take the form of something like the existing travel advisories Homeland Security provides.

Should you go to the Bahamas? Well, there's a level 2 travel advisory stating that jet ski operators there get kinda rapey sometimes.

Should you buy Cisco products? Well, they have a track record of deciding to EOL stuff instead of fixing it when it's expensive or inconvenient to do the right thing.

Should you buy Lenovo products? Well, they're built in a country that regularly tries and succeeds in hacking our infrastructure and has a history of including rootkits in their laptops.

[kube-system]

NIST isn't a bunch of dummies that don't know this. The requirements posed are not micromanagement of device design; some address your concern exactly... like a requirement that developers provide contact information to report vulnerabilities and that devices makers just can't ignore authentication entirely.

But this is IoT stuff we're talking about here, not Lenovo/Cisco... but ReoLink/PETLIBRO/eufy/roborock/FOSCAM/Ring/iRobot/etc. Security (or the lack of it) in the IoT world is a whole different ball game. It isn't uncommon for IoT devices to be EOL on release date, or just lack authentication or encryption entirely.

[timewizard]

> NIST isn't a bunch of dummies that don't know this

They've provided thorough definitions and a label that implies they've all been understood by the manufacturer. It doesn't mean that this solves any real world problem.

> Security (or the lack of it) in the IoT world is a whole different ball game.

Those can be described as IoT devices. They're more appropriately categorized as "consumer electronics" and often have a firmware update right out of the box. That's what makes this badging program an absurd idea with no meaningful outcome. This segment is not going to care.

This isn't "Energy Star" where the purchased product does not have additional functionality which can be exposed or exploited through software and no third party testing can be exhaustive enough to prevent the obvious exploit from occurring.

Even to the extent they can it then enforces a product design which cannot be upgraded or modified by the user under any circumstances. Worse the design frustrates the users ability to do their own verification of the device security.

It's a good idea applied to the wrong category of products and users.

[kube-system]

> Those can be described as IoT devices. They're more appropriately categorized as "consumer electronics"

IoT devices are a subset of a much broader 'consumer electronics' category.

> and often have a firmware update right out of the box.

From major, established, mature companies, yes. Many device manufacturers in this category never issue firmware updates. Which is precisely why this is one of the requirements.

> This segment is not going to care.

Some may, some may not. The federal government will care, because they will be forced by law to comply.

> no third party testing can be exhaustive enough to prevent the obvious exploit from occurring.

Of course, no cybersecurity compliance plan can prevent exploits from occurring. If you try to address cybersecurity in that way, you will fail, anyway. The point is to place controls in place which are achievable, measurable, and help to mitigate risk.

> Even to the extent they can it then enforces a product design which cannot be upgraded or modified by the user under any circumstances.

NIST's requirements require the opposite of this.

[timewizard]

> because they will be forced by law to comply.

Which means the program will have zero value outside of federal purchasing offices. They will not evaluate the criteria or care about the reality of the offering, they'll see the sticker, and know it's "default approved."

Is this a good outcome?

> mitigate risk

A sticker cannot do this.

[kube-system]

> zero value outside of federal purchasing offices

I can’t guarantee much but I can guarantee a non zero number of non federal purchasers will consider the sticker.

>> mitigate risk

> A sticker cannot do this.

Correct. The sticker itself doesn’t mitigate the risk. The adherence to the requirements necessary to qualify for the sticker do.

[svnt]

Picking and choosing companies like that could work if it could somehow remain apolitical. This registry can work despite the tendency for these things to become political.

What you’ve described is maybe more possible if provided by a Consumer Reports-style org that consumers could subscribe to.

[Greyfoscam]

Wouldn't it be simpler to have a QR code below the symbol with anything relevant to make this work ?

[ryandrake]

When I buy technology today, I'm 10X more worried about the manufacturer deliberately changing, killing or nerfing the product after I bought it, than I am worried about hackers compromising it. This goes for connected hardware, IOT devices, and software.

[elcritch]

Oddly "hackers" are the ones who often revive defunct hardware or give users back control over their devices. Things like DRM laws seem to only enhance corporate interests.