As usual, another discussion of regulation of software safety or security ignores real-world, past/present schemes regulating software safety or security. Regulations that worked in terms of vastly improving both. Then, after ignoring that, the author claims no benefit to government stepping in with regulations. Let's quickly look at those instead to see what was done.
For security, Walker's Computer Security Initiative mandated the DOD would only buy computer systems if they were secure to an appropriate level. The initiative included (a) guidance for improving security through whole lifecycle, (b) an evaluator (NSA) that would have to certify that guidance was followed w/ pentesting of anything claiming high-security, and (c) a requirement that vendors wouldnt get paid unless their products were certified. Lo and behold, the market suddenly produced half a dozen products with vastly better security than before plus a few that seemed free of vulnerabilities even down to covert leaks of information. The TCSEC had issues but fundamentals were sound of picking something businesses could understand, evaluating it, ensuring assurance of correctness, and financially incentivizing them. The bribes companies paid to Congress to get a change to COTS acquisition, uncertainty in export restrictions, NSA competiting with private sector under MISSI, and no demand in mass market for things that were actually secure killed the market for high-assurance security. Got watered down to mostly paperwork in Common Criteria w/ very few systems going for the standards that are actually secure (EAL6/7) and usually for select components in systems. Yet, the process worked with security improvements across the board w/ a few, highly-secure systems delivered.
On safety side, let's look at DO-178B (now C) for aerospace. They require carefully documented requirements, design, and so on with code proven to match it with code review and rigorous testing. It has to pass certification with no problems for them to make money on it. Re-certification is expensive. That led to vendors throwing as much QA as possible at their code which they simplified as much as possible. A whole ecosystem sprang up for safe languages, drivers, protocols, and so on. Also, tools for automating testing, supporting reviews, semi-automated generation of code, etc. The quality of all of this is much, much higher than typical of mainstream proprietary or FOSS apps. So, again, the sensible regulations worked.
That's twice it's happened. It could happen again for Internet security if it was a combination of reasonable protection profiles for certain classes of devices with focus on assurance of design, implementation, configuration, and maintenance like in TCSEC or high EAL's of Common Criteria. Just requiring memory-safe languages, POLA, safe/secure-by-default configuration, using components with few CVE's, fuzz testing, and secure authentication for admins would go a long way. On ISP side, the ability to detect DDOS's and temporarily throttle or cut off the nodes sending them until they've gotten their act cleaned up. This filtering could be done right in the ISP's modems or routers.
So, we can do a lot more than the OP lets on. Regulation on safety and security has worked twice. It's still working on safety side. We should do it again on security minimizing paperwork, expensive evaluations, etc to focus on minimum subset of features and assurance activities that get most of the results. 80/20 rule. Also, allow new methods or tools so long as they've previously proven to work on whatever they claim to do.
I never knew regulation also referred to government procurement requirements. I thought it was only for rules for market participants in general. If you do include government procurement requirements then your post adds a lot to the conversation.
If you were to jot down some rules of government procurement for IoT, what would you put in there?
I'd say most of the important government regulation comes in the form of procurement requirements.
It's far more politically tenable to suggest that "here is a quality that needs to exist in a product the government buys" than "here is something everyone needs to do."
And it just so happens that the US government is a huge buyer, so the market adapts.
That last line is exactly what happened for a while. They maintained and enhanced the products for over a decade, too, since there were profitable sales. Same thing is happening with DO-178B/C. One company even made a robust graphics driver for Radeon on non-Windows and non-Mac platform. Something the private sector can't be expected to do based on my experience. ;)
Instead of telling you what they recommended, I'm going to give you my modern list instead of assurance activities that could be considered for the next evaluation scheme. Orange Book had a subset of these. I pulled from the whole field to get a larger list.
For security, Walker's Computer Security Initiative mandated the DOD would only buy computer systems if they were secure to an appropriate level. The initiative included (a) guidance for improving security through whole lifecycle, (b) an evaluator (NSA) that would have to certify that guidance was followed w/ pentesting of anything claiming high-security, and (c) a requirement that vendors wouldnt get paid unless their products were certified. Lo and behold, the market suddenly produced half a dozen products with vastly better security than before plus a few that seemed free of vulnerabilities even down to covert leaks of information. The TCSEC had issues but fundamentals were sound of picking something businesses could understand, evaluating it, ensuring assurance of correctness, and financially incentivizing them. The bribes companies paid to Congress to get a change to COTS acquisition, uncertainty in export restrictions, NSA competiting with private sector under MISSI, and no demand in mass market for things that were actually secure killed the market for high-assurance security. Got watered down to mostly paperwork in Common Criteria w/ very few systems going for the standards that are actually secure (EAL6/7) and usually for select components in systems. Yet, the process worked with security improvements across the board w/ a few, highly-secure systems delivered.
On safety side, let's look at DO-178B (now C) for aerospace. They require carefully documented requirements, design, and so on with code proven to match it with code review and rigorous testing. It has to pass certification with no problems for them to make money on it. Re-certification is expensive. That led to vendors throwing as much QA as possible at their code which they simplified as much as possible. A whole ecosystem sprang up for safe languages, drivers, protocols, and so on. Also, tools for automating testing, supporting reviews, semi-automated generation of code, etc. The quality of all of this is much, much higher than typical of mainstream proprietary or FOSS apps. So, again, the sensible regulations worked.
That's twice it's happened. It could happen again for Internet security if it was a combination of reasonable protection profiles for certain classes of devices with focus on assurance of design, implementation, configuration, and maintenance like in TCSEC or high EAL's of Common Criteria. Just requiring memory-safe languages, POLA, safe/secure-by-default configuration, using components with few CVE's, fuzz testing, and secure authentication for admins would go a long way. On ISP side, the ability to detect DDOS's and temporarily throttle or cut off the nodes sending them until they've gotten their act cleaned up. This filtering could be done right in the ISP's modems or routers.
So, we can do a lot more than the OP lets on. Regulation on safety and security has worked twice. It's still working on safety side. We should do it again on security minimizing paperwork, expensive evaluations, etc to focus on minimum subset of features and assurance activities that get most of the results. 80/20 rule. Also, allow new methods or tools so long as they've previously proven to work on whatever they claim to do.