31–40 of 164 posts
What's to stop the bad actors from just printing the logo on their gear anyways? Like they do with UL and N95?
This is federal offense, like document falsification.
So if somebody will be caught on doing it - could go to jail.
Interesting. I'm not sure if the public comment period is over (The original proposal is dated August, 2023), but this stands out to me from their paper: We propose to focus the scope of our program on intentional radiators that generate and emit RF energy by radiation or induction.31 Such devices – if exploited by a vulnerability – could be manipulated to generate and emit RF energy to cause harmful interference. Wh…
* data stored/transmitted is secured by some kind of means
* the device supports software updates
* the device requires users to authenticate
* the device has documentation
* you can report security vulnerabilities to the developer
And even these are things that many devices fail to do, today. We gotta get the basics fixed first.
But for now, you can presume the Netflix button on your TV remote can't be configured to point to an alternative API if Netflix goes away. :)
I'm interested in the actual details here -- 1) What are the requirements for the mark? E.g. no passwords stored in plaintext on servers, no blank/default passwords on devices for SSH or anything else, a process for security updates, etc.? 2) Who is inspecting the code, both server-side and device-side? 3) What are the processes for inspecting the code? How do we know it's actually being done and not just being rubbe…
Yep, pretty basic stuff, like 'require authentication', 'support software updates', etc
> 2) Who is inspecting the code, both server-side and device-side?
UL is administering the program and they're going to come up with the requirements
> UL Solutions will work with stakeholders to make recommendations to the FCC on a number of important program details, like applicable technical standards and testing procedures, post-market surveillance requirements, the product registry, and a consumer education campaign.
I'm interested in the actual details here -- 1) What are the requirements for the mark? E.g. no passwords stored in plaintext on servers, no blank/default passwords on devices for SSH or anything else, a process for security updates, etc.? 2) Who is inspecting the code, both server-side and device-side? 3) What are the processes for inspecting the code? How do we know it's actually being done and not just being rubbe…
Interesting. I'm not sure if the public comment period is over (The original proposal is dated August, 2023), but this stands out to me from their paper: We propose to focus the scope of our program on intentional radiators that generate and emit RF energy by radiation or induction.31 Such devices – if exploited by a vulnerability – could be manipulated to generate and emit RF energy to cause harmful interference. Wh…
You might be getting a bit too far ahead of where the industry is at with some of those wishlist items. NIST's requirements are things that are best practices that everyone agrees with, like: * data stored/transmitted is secured by some kind of means * the device supports software updates * the device requires users to authenticate * the device has documentation * you can report security vulnerabilities to the develo…
Interesting. I'm not sure if the public comment period is over (The original proposal is dated August, 2023), but this stands out to me from their paper: We propose to focus the scope of our program on intentional radiators that generate and emit RF energy by radiation or induction.31 Such devices – if exploited by a vulnerability – could be manipulated to generate and emit RF energy to cause harmful interference. Wh…
This needs better and more detailed clarification. I've reverse engineered a camera-equipped pet feeder, and videos sent to a cloud (or my emulating server in my case) were partially encrypted - I-frames were, P-frames were NOT. Someone ticked a checkbox "videos are encrypted", and still left the thing glaring open.
Then, of course, it's also a matter of ciphers and modes, authentication, key generation, transmission and storage, etc etc.
Feels like encrypted storage and transmission features alone require a full whole label, like the FCC's broadband facts label, or FDA's nutritional facts label, which outlines what data exists in the system, where the data is stored, how it's encrypted, how it's authenticated, and so on.
Which is probably not happening until cryptography 101 becomes a part of general school curriculum and layman people start to understand the basics. Without people asking real questions and refusing to purchase products from sloppy engineering companies (aka voting with their wallets*), companies will always wave it away with tried-and-proven "military-grade security" bullshit.
___
*) That is, if there's even a competition. When no one does things right (because consumers don't know and thus don't ask for it), there's nothing to pick from.
I wonder how much this is going to add to the cost/effort of creating a new IOT product for startups/small businesses?
I wonder, how strict will be regulations on Chinese software parts. For EU/US/Australia/Korea originated should be less strict if could prove source.
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 ti…
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.
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 ti…