[tptacek]

If you believe any part of innovation comes from new products launched by small new companies, then regulation will hurt security, because to a first approximation none of those kinds of companies have any coherent plan for software security. None of them can afford market rates for this kind of work.

Another problem with regulating software security is that it will inevitably involve licensing software security assessors (it's hard to meaningfully require audits without doing that). The history of licensed security auditors is not reassuring; the economics predict a race-to-the-bottom, and that's what you get (see: PCI).

[tzs]

The concerns in the first paragraph could perhaps be addressed by having volume thresholds before regulation kicks in. If your internet-connected special purpose device has more than N unit sales, more than $M dollar sales, or is offered in more than K brick-and-mortar stores, then it is subject to security regulation.

I too am not in favor (at this point) of requiring licensed assessors to approve software after it is complete, at least for most products. Embedded medical devices, vehicle control systems, and things like that probably should have an outside assessment.

I'd be happy for now just having some rules to try to make it so IoT device breaches are mostly due to bugs in the implementation of a good design, rather than due to the producers not having a clue about security.

I think we are fast approaching (if we have not already past) the point where good security practices are something that almost every programmer and software architect should know and practice. There should be basic coverage of this in the standard computer science/software engineering curriculum, and there should be more extensive coverage as an optional part of the curriculum. If you take these optional courses, your degree is "B.S. in Computer Science and Computer Security" (BS CSCS). (There should also be a way to get this training outside of college, and get some sort of certificate that you have had this training).

Those making products that reach the thresholds for regulation should have to have someone with a BS CSCS (or a certification of equivalent security training) who signed off on the architecture, development standards, and testing process used for the product.

My expectation is that as everything (for better or worse) gets connected, the vast majority of CS students will go for the CSCS option and so people with a BS CSCS will not be significantly harder to find or more expensive to hire than people with just a BS CS, and so even small new companies should be able to afford them once they get past the point of the founders doing all the work and start hiring employees.

[woah]

Do you really think that you can give an programmer a certificate and have them write secure stuff? Exploits are always changing.

[tzs]

"Exploits are always changing" is not really a meaningful objection, because it applies to every way that one might try to ensure security short of only deploying software and systems that have been mathematically proven to be secure.

The vast majority of exploits against IoT devices do not involve new exploits. They involve ridiculously ancient exploits, like finding plaintext passwords embedded in the firmware, or adding something like "&admin=1" to the end of a URL.

If we could get to the point where breaking an IoT device requires something like finding a hole in, say, the TLS protocol (or in a widespread TLS library), rather than just looking because the damn thing doesn't use encryption at all, we'd be vastly better off than we are now.

This is what I meant when I said, "I'd be happy for now just having some rules to try to make it so IoT device breaches are mostly due to bugs in the implementation of a good design, rather than due to the producers not having a clue about security".

Right now far too many devices are vulnerable even if they are 100% bug free.

[tptacek]

I'd like it if there were some sort of non-profit Underwriters Laboratories for software security. But what we're more likely to get is a captured cartel of government-supported commercial labs.

For IOT, the bigger problem is that most of this stuff is getting deployed on BOM constrained designs, so they can't take advantage of safe programming environments, but instead pretty much have to link random C libraries together.

[tbrownaw]

Laws and case-law are always changing, but whatever lawyers do to stay current seems to work well enough.

Building codes change, but certifications for electricians/plumbers/whatever seem to work well enough.

The certifications I've heard of all come with an expiration date. The professional organizations I've heard of all require at least a little bit of ongoing study from their members.

I don't see why what works well enough everywhere else wouldn't work well enough here?

[firebones]

I'm confused by your first sentence. Read as you have written it, I think you mean that regulation will hurt innovation in the IoT space, not security in the IoT space, because you've already said that none of these companies have coherent plans for software security today. Regulation won't hurt security; it may help it by creating incentive for standardization around secure infrastructure to chip away at the "market rates for this kind of work" which "none of them can afford".

There is good regulation and bad regulation, but regulation can accelerate innovation. With or without regulation, addressing this problem with more standardization of secure software and hardware infrastructure would reduce the need for human assessors (or at the very least, push what they're worrying about higher in the stack). Addressing it with licensing and more humans is probably not the kind of regulation I'd look for. So could there be bar-raising regulation that encouraged infrastructural solutions that benefited the industry as a whole?

I'd hate to inject insurers into this world, but one way might be to require IoT manufacturers to carry some sort of indemnification against potential consumer damages, and the insurers drive the security quality. In the 1990s, it was insurers, tired of anesthesia-related malpractice losses, who created back-pressure on the profession to put better clinical standards in place, and errors related to anesthesia-related causes dropped, as did premiums for practitioners following the guidelines. Everyone benefited--especially the patients.

But in the IoT world today, there are no meaningful incentives around securing devices, and consumers have little influence.

[tptacek]

Yeah, you're confused because I mis-wrote that. Wow, that was indeed a confusing sentence. I meant regs will hurt innovation, not security.

The problem is that I think the security gains will also be marginal, and the innovation harm will be significant.

In particular, the history of security standards, which you bring up as an example of "good regulation", is checkered.

I agree with you that mandatory insurance could be a "middle way" between intrusive regulation and no regulation. But that's essentially the structure the payments industry uses with PCI, and PCI has been a race-to-the-bottom.