MarcoPerazaFCC

Thanks for the thoughtful reply. I encourage you to file an official comment with your ideas.

Thank you for this detailed feedback. In the long-run, it's worth asking whether a business that doesn't make money once externalities have been internalized is a business worth having. But this is a voluntary program, and we're just hoping to spur growth of a segment of the device market where these issues are properly accounted for. Hopefully as more and more purchasers begin insisting on higher-standards, maybe by insisting on this label being present, economies of scale and componentization of secure IoT platforms will drive the costs of good IoT security down to the point where your concerns aren't as salient. Please consider sharing your thoughts through official comments.

One my favorite IoT botnet scenarios is an attacker taking control of thousands of ovens/air conditions/other high-wattage devices and using them to cause power outages. https://www.usenix.org/system/files/conference/usenixsecurit...

I wonder how the impulse to connect everything to the internet will be remembered.

Good question. There's some discussion in this thread https://news.ycombinator.com/item?id=37395218

I think you're right that it would be difficult for the FCC to precisely define exactly when security updates are required. This is a problem in law generally, one that is usually resolved by imposing a reasonableness standard. Maybe here, a vulnerability needs to be patched if it might reasonably be expected to allow an attacker to take control of a device, or to do so when combined with other known or unknown vulnerabilities. Or maybe a different standard. Then when enforcement/lawsuits come around, the judge/jury/regulator has to evaluate the reasonableness of the manufacturer's actions in light of that standard. We'd love to see commentary on the record as to what the right legal standard might be. (originally posted at https://news.ycombinator.com/item?id=37394188)

It's a voluntary label, so it's open to competition from other standard-setting organizations. When it comes to mandatory regulations generally, our office thinks that broad standards that are used to hold people accountable for negligent conduct are better than detailed checkbox-compliance exercises that quickly become out-of-date red tape.

I think you're right that it would be difficult for the FCC to precisely define exactly when security updates are required. This is a problem in law generally, one that is usually resolved by imposing a reasonableness standard. Maybe here, a vulnerability needs to be patched if it might reasonably be expected to allow an attacker to take control of a device, or to do so when combined with other known or unknown vulnerabilities. Or maybe a different standard. Then when enforcement/lawsuits come around, the judge/jury/regulator has to evaluate the reasonableness of the manufacturer's actions in light of that standard. We'd love to see commentary on the record as to what the right legal standard might be.

(originally posted at https://news.ycombinator.com/item?id=37394188)

I think if the box says updates until the beginning of 2025, and they've stopped providing updates before then, you have a pretty good contract lawsuit against them. You'd have to show that their failure to issue a patch for four months constitutes a breach, but that is exactly the kind of thing that gets hashed out in lawsuits. You could even have a class action of all the owners suing the manufacturer. We think one of the great opportunities of this labeling program is to begin developing a caselaw of what it means to hold a manufacturer to the commitments on the label.

These are all great points and maybe a good reason why a voluntary program like this is the way to start, so a higher-tier of secure products can begin to emerge. We would also love to see the emergence of platforms that allow small teams to build on top of a secure, update-ready base. Some interesting discussion here https://news.ycombinator.com/item?id=37394546

Thanks for this thoughtful feedback. I encourage you to file an official comment, especially regarding end-user control of update timing. Maybe my response here https://news.ycombinator.com/item?id=37394935 addresses some of your other concerns? We'd love to hear your thoughts.

This will be a completely optional program. And the proposal is that even for participants of the program, they just have to disclose the update period, whatever it may be (could be zero-length).

This is something that has us worried too. The FCC took some action on this issue last year by outright banning equipment from certain companies (e.g. Huawei), but we haven't even scratched the surface of this pervasive problem. I really encourage you to share your concerns through an official comment. Maybe the label can include commitments about the provenance (and, e.g., control of signing keys) of the on-device software and associated cloud services?

I encourage you to file a comment suggesting this. It's actually not irrelevant. The FCC is free to decide that the label (which can include a QR code linking to more information) must include information about cameras and microphones and whether there is a software-tamper-proof way to tell whether they are on. Or the existence of a hardwired LED could even be a requirement to qualify for a label. Your experience with the OLPC project would really bolster the credibility of your comment as well, so don't forget to mention that.

Hi, the short of it is that I decided to go to law school and then looked for jobs focusing on cybersecurity. If you're interested in jumping over to law, I'm happy to talk about it more. You can find my email in the FCC directory https://www.fcc.gov/about-fcc/finding-people-fcc

This is being proposed as a completely voluntary program. No need to participate in it if you don't want an FCC cybersecurity label on your product.

If you think stronger action is needed, please share it through an official comment. Even if we don't do what you suggest, thoughtful comments really do influence the rulemaking process.

As an aside, it's worth considering that there are also very sophisticated purchasers in this space, such as government and large businesses, and that a standardized, legally binding, label might help them insist on purchasing higher quality products.

>I've purchased equipment, new in the box, after the mfg had discontinued support.

Exactly the kind of thing that sounds crazy but still happens.

>1. Final date the manufacturer will provide firmware updates & security updates 2. If the manufacturer will support open source alternative firmware & security updates. 3. If there are any subscription fees (and how much) to get firmware updates & security updates.

It would be great if you could file an official comment with your thoughts on exactly what disclosures are needed and why you think they're necessary. We want to get this right.

The general rule in tort is that you need physical injury or physical destruction of property to sustain a lawsuit. There's exceptions at the edges of that, but you basically can't sue a device manufacturer for crummy security that caused you to lose money or other non-physical damages like reputational harm. The same limitation does not apply to contract law. We think that a cybersecurity label could be enforceable under contract law, as well as help bolster claims that a duty was breached in tort (when there is physical injury/damage). It would also be subject to FCC enforcement, for failing to live up to the commitments made to get the label.

Good question. The Notice of Proposed Rulemaking has a Legal Authority section that discusses this issue https://www.fcc.gov/document/fcc-proposes-cybersecurity-labe.... I also touch on it here https://news.ycombinator.com/item?id=37393316

Maybe the presence or absence of this capability could be something disclosed on the label? It's an idea worth thinking about. I encourage you to file a comment with your thoughts on the matter. You probably want to focus on how this information could help a security-concerned consumer/business make a better purchasing decision. Or if you're arguing that this be a hard-requirement for the label, why a device should not be considered secure without this capability.

Thank you for these thoughtful points. Some relevant responses from other threads:

From https://news.ycombinator.com/item?id=37394188 :

I think you're right that it would be difficult for the FCC to precisely define exactly when security updates are required. This is a problem in law generally, one that is usually resolved by imposing a reasonableness standard. Maybe here, a vulnerability needs to be patched if it might reasonably be expected to allow an attacker to take control of a device, or to do so when combined with other known or unknown vulnerabilities. Or maybe a different standard. Then when enforcement/lawsuits come around, the judge/jury/regulator has to evaluate the reasonableness of the manufacturer's actions in light of that standard. We'd love to see commentary on the record as to what the right legal standard might be.

From https://news.ycombinator.com/item?id=37394793 :

Agreed. Building an automatic firmware update system from scratch would be burdensome for many IoT makers, but as it becomes necessary or encouraged, we would expect the market to provide a packaged solution/framework that manufacturers could fold into their products. It would be really helpful have to discussion of this on the record. How generalizable do you think such a solution could be? We are aware of the Uptane project, an OTA firmware update framework being jointly worked on by several car manufacturers, but would love to hear more about the feasibility of a solution for IoT devices generally, or particular classes of IoT devices.

From https://news.ycombinator.com/item?id=37393926 :

[...] companies wanting to put a label on their product would probably want to extract similar guarantees up their supply chain. Especially with a voluntary program like the one the FCC is proposing, good practices won't become the norm across the market overnight. But maybe, at the very least, the segment of product and component makers that take security seriously will begin to grow. I encourage you to share your thoughts in an official comment.

>And since this is HN - there is a startup hidden in the midst of all of this: an enterprise-grade IoT OS that "does security right." Sell to the device manufacturers, allow them to market it as "enterprise-ready" or some such. If the FCC guidelines here are approved, there will be a suddenly increased demand!

Agreed. Building an automatic firmware update system from scratch would be burdensome for many IoT makers, but as it becomes necessary or encouraged, we would expect the market to provide a packaged solution/framework that manufacturers could fold into their products. It would be really helpful have to discussion of this on the record. How generalizable do you think such a solution could be? We are aware of the Uptane project, an OTA firmware update framework being jointly worked on by several car manufacturers, but would love to hear more about the feasibility of a solution for IoT devices generally, or particular classes of IoT devices.

These could be great suggestions for the criteria a product must meet to quality for a label. I encourage you to file an official comment with your thoughts.

In the 2010s, the FCC began enforcement proceedings against more than one hotel chain for using Wi-Fi deauthentication attacks against guests using their own Wi-Fi hotspots instead of the official hotel Wi-Fi networks. The claims were settled, so there's no court ruling on the matter, but our office is inclined to believe that the FCC has legal authority over such attacks. But we definitely encourage you to share your views on the record.

I think you're right that it would be difficult for the FCC to precisely define exactly when security updates are required. This is a problem in law generally, one that is usually resolved by imposing a reasonableness standard. Maybe here, a vulnerability needs to be patched if it might reasonably be expected to allow an attacker to take control of a device, or to do so when combined with other known or unknown vulnerabilities. Or maybe a different standard. Then when enforcement/lawsuits come around, the judge/jury/regulator has to evaluate the reasonableness of the manufacturer's actions in light of that standard. We'd love to see commentary on the record as to what the right legal standard might be.

Re: the licensing issue, companies wanting to put a label on their product would probably want to extract similar guarantees up their supply chain. Especially with a voluntary program like the one the FCC is proposing, good practices won't become the norm across the market overnight. But maybe, at the very least, the segment of product and component makers that take security seriously will begin to grow. I encourage you to share your thoughts in an official comment.

Thanks for this great observation. I encourage you to share it in an official comment. In a final rulemaking, perhaps we could make it clear that the purpose of the label is not only to protect the purchaser of the product but also anyone who might be injured by way of a compromised device. In an FCC enforcement proceeding, we have broad discretion in assessing damages. In contract, the third-party beneficiary doctrine could allow victims of such attacks to enforce label commitments. And in tort, statutory duties apply to anyone who is within the class of people that the law seeks to protect. So the law is flexible here, but it depends on what exactly our final rules say.

That's a great question. Devices that emit RF could be hijacked and turned into signal jammers. With smart jamming attacks, even low-power transmitters could potentially cause serious harmful interference to other devices. Botnets of compromised devices could be especially damaging. Since vulnerabilities are often chained by attackers, sometimes in very unexpected ways, to accomplish their final goal, we think that the FCC has a legitimate interest in just about any vulnerability on a wireless device. But the question of legal authority is itself open for public comment and we hope there's vigorous debate on the record to make sure we get it right.