My casual quick read did not see any manufacturers being held liable for security breaches. It's not clear to me how serious the USG is being if there is still no fault for the ongoing mass breaches of privacy.
My casual quick read did not see any manufacturers being held liable for security breaches.
Liability as security panacea keeps come up here. It's kind of ridiculous imo.
Electrical components, for example, aren't made safe by liability but by standards. And given there's no set way anyone knows how to manufacture secure components, it's hard to come up with a "you should have known" standard for liability.
Liability guidance is effective at being clear about who needs to pay for security. An example of where this is effective is the rollout of chip-and-pin credit cards. Only when retailers became liable for forgery due to the "weakest link" liability clause put forward by Mastercard and Visa did they become motivated to deploy card terminals that could do chip-and-pin. And fraud has been significantly reduced as a result[1].
> Electrical components, for example, aren't made safe by liability but by standards.
The NFPA and NEC were created by insurance companies, the standards exist because of the liability. UL stands for Underwriters Laboratory, underwriters being the people who write insurance policies (to transfer risk aka liability).
IE, just liability isn't sufficient. Regulation were created to avoid a situation of liability because "raw liability" doesn't work.
The thing is, electrical regulations are not regulations merely on manufacturers, indeed, they only require particular, simple components. They are mainly for the users of electrical components, builders and the electrician they employ.
The constant whine here at HN is that software companies are held liable for their insecure applications. The problem is that the security isn't primarily about buying secure components. It's about having secure practices in place.
For "critical infrastructure", things like "don't connect shit that doesn't need connecting and "build from source, don't download anonymous binary blobs." are standards that should be on the end-user, just for example.
Why do you believe component and product quality and liability doesn’t involve on going manufacturing process best practices and recalls?
IoT and software isn’t special. It’s just getting a free pass because the vendors and solution providers want to dodge the responsibility for as long as they can.
Why do you believe component and product quality and liability doesn’t involve on going manufacturing process best practices and recalls?
-- Maybe I'm not saying it well. But my point is that until someone defines an overall use context, calling a given thing "unsafe" is futile. In an intranet not connected to the outside, an IP camera with no security at all is fine.
Without "customer classes" defined, without security use cases defined, and so-forth, of course manufactures will produce anything they want and why shouldn't they? The implicit standards of security now are the wild, wild west.
The original situation is IP cameras and other devices sold with pathetic security. Sure, it seems intuitively obvious that "these people were doing it wrong and ought to pay". But you can't really do that because there reasonable situation where these devices are reasonable.
IE, manufacturer responsibility can't exist, can't be pinned down, until standards exist.
> anyone knows how to manufacture secure components
I know how to manufacture components that cannot have their firmware updated by malicious code. Put a hardware switch on the "write enable" line for the ROMs. Like people used to do.
Then malware won't survive the "reboot" switch.
The next step is to add a hardware timer that does a hard reboot once a day (or more often for critical stuff).
I don't know why security professionals with clout don't demand this. I would.
There's something wrong with "we need to be able to remotely update the ROMs to protect the ROMs from remote updates."
> trained operator
I'm not sure that flipping an "enable updates" switch requires training.
> reinfected five minutes after they reboot
Scenario A: malware installs itself in device ROM. You remove malware, the ROM code reinfects the system. You have no idea if the device is compromised or not. Your only choice is to buy all new components.
Scenario B: malware keeps reinfecting system 5 minutes after reboot. You remove the malware. Reboot. Your system is clean.
> Scenario B: malware keeps reinfecting system 5 minutes after reboot. You remove the malware. Reboot. Your system is clean.
... for about 5 minutes.
This is very close to what happened with the Slammer worm.[0] It was in-memory only, spread like wildfire, and any unpatched systems were infected within minutes.
There will always, always be entrepreneurs who gamble that they won't get caught, or that they as individuals can cash out early end up money ahead even if the company gets caught and goes down in flames.
Yup, the doc seems to merely make optional recommendations, without enforcement, and only apply them to new devices (not ones already in the field). This is the USA’s way to “get serious” about something. It’s a nothingburger.
However, once some recommendations written as standards, and understood and at least partly implemented by some manufacturers, it would be quite straightforward for other laws to prohibit sales to consumers or import of certain product categories unless they meet those standards - and it would be quite crazy to pass such restrictions before the standards have been made and discussed and tweaked, they take work and time to become reasonable.
So assigning resources and specific organization to define such standards is the way to go even if there's no enforcement scheduled yet.
It is common for contracts to stipulate that performance under the contract must conform to various public standards, recommendations, best practices, etc by reference to an external document or authority (RFCs, standard body outputs, industry consortiums, etc) that are not required by law. People create these publicly referenceable outputs precisely because it allows them to be added to contracting language. NIST is such a reference source. In some sectors, virtually every contract has the same conformance requirements.
In practice, this often has the force of law. There are many domains where regulatory bodies arbitrarily require that all contracts conform to one or more of these recommendations to be in compliance or fit for purpose even if they don’t come from the government. Government contracts often have language that product and delivery must conform to a long list of such reference documents.
This is less common in web tech, but in other market sectors compliance with a set of common public guidelines is a cost of doing business and contracts sometimes have long lists of things to conform to. The real issue is that most organizations do just enough to check the box, even if violating the spirit of the requirement, because it turns out that customers just want that conformance for ass-covering and don’t care about rigorous compliance. Rigorous compliance would be expensive, especially if anyone tested it (which virtually never happens).
People will comply with the NIST guidelines because their contracts will require it. The problem is that is not enough.
Great explanation, and exactly right in my experience. It isn't about "you're breaking the law and the Govt is gonna getcha," but you can't do business without meeting the guidelines and would be in breach of contract if you take on a project where you don't conform.
because a lot of laws do not have consequences codified, or they do but have delegated to an authority that cannot levy any consequence, like the Department of Commerce or in this cast the NIST
sometimes this is intentional, not by any specific lawmaker, but relying on their and everyone else's inattentiveness.
Any device sold to the US Government will eventually have to adhere to those standards.
Sure, this won't stop Chinese consumer junk, but it will likely improve things like medical devices sold to the VA simply because FDA certifying two different devices of different security levels will be too expensive.
The problem with that is that practical cyber security is essentially about the "structural soundness" of a huge infrastructure that's mostly civilian and mostly private, about the resilience of private company internal systems and consumer products - a "cyber force" (no matter how strong or large) has neither authorisation nor practical ability to come in the servers and systems of every important private organization (some large, some quite small - e.g. municipal water infrastructure orgs whose "IT" is a contractor booked for a couple hours per week) and change them so that they'd be more defensible.
As it is now, each service branch has their own cyber operations and command structure for them, and they are all beholden to the central cyber command for strategic coordination. But how the day to day is played out is determined by each branch by itself.
I would argue that it's orders of magnitudes more necessary than a Space Force. after decades of relatively slow advancement, i fail to see why it's vital in 2021 to dedicate an entire branch of the military to space. An area which they have virtually no access to. OTOH, cyber warfare is very real, available and probably more effective then anything short of nuclear warfare.
I don't know how to phrase this idea but maybe someone here can give it more correct context?
If I were in charge of administering MAC/IP/etc addresses that all the proliferating billions of devices were starting to overlap and become a huge noisy pond of traffic and vulnerability, one thing I might do is create classes of devices and different privileges to them.
So instead of every device, from the most important supercomputer/network superhub, down to dumb refrigerator on wifi, having equal priority and "must be listened to" traffic, there would be tiers of who is allowed to take up what bandwidth, assert what privileges, etc.
Otherwise, with the coming storm of devices it will truly be like a shouting match with every device having equal volume and possibility for being a risk to every other device. Of course in some ways a Raspberry Pi can act like a superhub in some respects, so I realize there's challenges on who would decide and how to implement many layers of detail.
This is already a thing: quality of service (QoS).
Your router looks at the protocols and decides who gets priority when sending or dropping packets. Your ISP does it. Etc.
The reason to leave it up to the end user is because the manufacturer can’t know what a class of device truly represents:
My rPi might be monitoring temperature in the boiler room so either the rPi can report itself as a priority device (current situation) or we need some way to know ahead of time “this temperature sensor monitors boilers” and “this temperature sensor monitors back door gardens”.
Same thing with permissions. My firewall is aware my computers and my IOT are different classes of things because I put them on different VLANs. There’s rules about who can talk to who and what they can say.
The hardest part seems to be when the device first appears. The firewall/switch/whatever network appliance has to decide to which class the new device belongs. You can't trust the device, because most devices, from light bulbs to set-top boxes, will just say they're in the class that deserves maximum "upload audiovisual surveillance from the family bathroom directly to our server" permissions. So, the network equipment can compare the MAC to an already-populated (how?) list, but MACs can be spoofed. Maybe the device could obtain a token that proves to which class it belongs? In that case you have to pass out tokens in a reasonable way...
Separate VLANs is right, but it isn't easy. If we have more IoThings every day, we have to get them plugged into the proper VLAN every day.
That would be a mirage anyway. With Nest thermostat's secret microphone, the various smart TVs with hidden cameras, and universal police access to video footage collected by the Ring doorbell network, it has become clear one can't assume any particular device isn't sensing everything in its vicinity. Cell network connections are expensive at scale, but that is due to oligopoly rent-seeking, not technical restrictions. The MNOs are pretending that it's even physically possible for them to own 5g, but it isn't. Connecting around rather than through wifi will become common for IoThings.
Yes — Amazon is rolling out a test gossip network on their latest generation Echos. One of my Echos shared the WiFi password with the other.
I also think separate VLANs could be better (setup is a mess), but using them is pretty easy: you just connect the device to the right VLAN at setup. All of my wall sockets are IOTnet and they have their own AP. I think a big area of improvement is making it easier to provide different VLANs with different DNS.
It’s not perfect, but it is better (owned device can’t access other trust domains; can have firewall rules enforced).
I agree it all could be better and we need regulation around disclosing sensors in IOT devices (eg, Nest should be legally obligated to disclose microphones) or IOT gossip protocols.
Anyone has experience with the KNX standard?. Seems like the solution to all IoT woes. It's an international standard and widely used. Seems to be that only Europeans have heard of it.
Maybe I shouldn't feed the troll, but I'm curious about what you are trying to accomplish with your comment?
Even though he's not the most popular president on HN it's totally fair of you to laud President Trump for signing the bill into law. But bringing up those claims about President Obama's legitimacy comes across as a non-sequitur at best.
https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259.pdf
My casual quick read did not see any manufacturers being held liable for security breaches. It's not clear to me how serious the USG is being if there is still no fault for the ongoing mass breaches of privacy.