> that vendors ensure the devices are free from known vulnerabilities when sold. > Under the proposal, an IoT device has a fairly broad definition, being described as “a physical object that is capable of connecting to and is in regular connection with the Internet;” and one that “has computer processing capabilities that can collect, send or receive data.”

What is the exact definition of "known vulnerability"? With very broad definition, that would likely prevent them from buying any computers equipped with Windows for good part of the year as while Microsoft is preparing a patch for some vulnerability (which may have been internally discovered).

With even more broad definition, it could prevent selling with Linux as well for similar reason (as one of the tens of thousand packages is likely preparing a patch).

If it means vulnerabilities where there's either 1) exploit 2) patch 3) detailed information available, it would likely be enough.

> What is the exact definition of "known vulnerability"?

I believe the OMB's job is to fill in the details.

The headline seems a bit deceptive. No basic standard is set for IoT security, the government just started demanding a certain quality for their own purchases of IoT devices (i.e. not buying just any old IoT device):

> The IoT Cybersecurity Improvement Act of 2017 seeks to use the government’s buying power to signal the basic level of security that IoT devices sold to Uncle Sam will need to have.

If a large swarm of autonomous cars were taken over because of a software vulnerability, and were roaming the streets threatening people for charge-ups, would we hold the car manufacturer liable?

We’re experiencing this with IoT devices, except that “threatening” for a rogue IoT device means a denial-of-service attack (sending information over a network connection).

If the vulnerability was a result of gross negligence, then oh yes, absolutely.

(now I actually agree with you but). . . Good luck proving that.

I only scanned the article but couldn't see whether it mentioned voting machines. How would this Bill affect the procurement of new /or maintenance for already purchased/ voting machines if at all?

It affects every internet-connected device purchased by the federal government. Since states usually handle their own voting, I don't think this applies.

> For example, the bill would require [...] that vendors ensure the devices are free from known vulnerabilities when sold.

This seems... logistically challenging. It kind of also seems like an invitation to release new, high-priced "only the government will buy these" devices frequently, since (a) new devices don't have known vulnerabilities yet, and (b) older devices do have known vulnerabilities, so the government won't be allowed to buy them. But the security of those new devices will be much worse than the security of older ones.

Ah, I'm not sure I understand your last point. What about selling a "new high priced" item to the government because the engineering team spent some cycles fixing up the known vulnerabilities and re-released the product with those issues fixed. This seems like it would be more secure than a new untested product.

The argument is that companies would not fix the software, but instead release "new" products that don't have any "known" vulns. Basically, it would be cheaper to re-brand every year or two than spend the cycles to actually fix any bugs.

But then any competitor could just find the old vulnerabilities in your "new" code and make them public. The re-branding effort would be completely wasted if you don't actually fix anything.

For one thing, if, as is likely, you try to fix a security vulnerability and fail, then you just fraudulently sold a product with a known vulnerability.

When you release an untested product, you're safe.

Who defines vunerabilities? Standard users, power users, government agencies hiding a zero day?