And even assuming we have a definition of 'infrastructure software' and a way to reliably enumerate a set of vulnerabilities, attribution of liability is even harder:
- Is the distributor of the router liable for a vulnerability in a used library? Surely they could vet and review libraries.
- What happens if that library is openssl and almost all webservers on the internet are vulnerable?
- What happens if the library is used in an insecure way? For example, if you seed openssl or libressl with weak random numbers, it is possible to attack algorithms provided by the library.
- On the contrary, if the author of a library is liable, what's going to happen if I use a library of a company and build something vulnerable with it intentionally?
I dislike being so negative about it, but I wouldn't want to get sued for sticking an MIT license on a silly project 10 years ago someone necro'd and stuck into a router, so to say.
Most FOSS licenses come with 'without warranty' notice. Businesses, who use it, should know that.
There's no such thing as absolutely safe software.
And yes, organizations and versions of software would have to be recertified on a regular basis.
You would want software versions to be able to be certified quickly and through an automated process, but there is already some best practice in this space — it’s just unevenly distributed.
IMHO, we should have optimistic check: any public network device must have guarantee from the vendor to fix any remote vulnerability in 30 days after discovery by independent security organization(s), otherwise vendor liable for the damage done by his device.
Past event: https://www.aei.org/events/securing-the-internet-of-things-a...
Partial event video: https://www.youtube.com/watch?v=DrnFcLuqzd4
When it comes to SOHO routers it's not as hard as it should be, by a long shot. Tons of hardcoded creds and pretty surface vulns in them.
> - Is the distributor of the router liable for a vulnerability in a used library? Surely they could vet and review libraries.
Yes.
> - What happens if that library is openssl and almost all webservers on the internet are vulnerable?
Everyone deploying it is liable.
> - What happens if the library is used in an insecure way? For example, if you seed openssl or libressl with weak random numbers, it is possible to attack algorithms provided by the library.
The company doing so is liable.
> - On the contrary, if the author of a library is liable, what's going to happen if I use a library of a company and build something vulnerable with it intentionally?
You are liable.
As in, the person who produces the product is liable for what they put in the product.
But, as I said elsewhere, this is all off the cuff and relies on a way to properly classify software, which is extremely hard.
But yeah, to your points, none of those feel hard to deal with at all.
I'm not a lawyer. This is not an area I'm so familiar with. But we already have some controls for CC info, and extending those further would be hard but a good start. This situation is extremely out of hand, whether I have the solution today or not.
We don’t need hardware and software costs spirally out of control like healthcare because of the liability. If device makers would just support their products (bug fixes) for 10(?) years I think that would do it.
In programming, you have true and false, and generally things fall into one or the other category with no human input.
In law, you have concepts like "reasonable", and a whole lot of human input, by design.
So my expectation would be that if software vendors were to be held responsible for bugs in their products, the standard they would be expected to adhere to would be "reasonable expectation of proper functioning", with humans intepreting what "reasonable" means.
Change the phrase "software bug" to "engineering error". Then consider the liabilities involved with the manufacture of any real-world-might-kill-someone product. The lawyer's view starts to make a helluva lot more sense.
Millions of malicious people constantly attacking it with cheap equipment from a distance with little chance of being caught doing so?
For one thing, we would be much more conservative in how we wrote code. Libraries would be vetted, with insurance contracts attached to them. Programming languages would not allow for dynamic data, type coercion, or weak typing. In the 80s, rather than C rising to prominence, Ada would have. Haskell would be our generations Javascript, and XHTML would have won over HTML5 simple because guessing how rendering should work would open up a browser maker to high fines and lawsuits.
We'd have to rewrite our entire software stack from the ground up. It's not impossible, but we'd have to view it as a multi-decade transition like how the chemical industry was slowly forced to not use heavily polluting procedures.
There is tradition, but a lot of it military in origin, not civil: ARPA net, Grace Hopper, and the first bug, Turing and the Enigma. Stealworking as a military secret in comparison is thousands of years old. And so far, leaked DB content has per the official record not killed anyone ... perhaps a few astronauts but none of the people responsible in place to fix it, as would be the case in a family of incorporated electricians.
We need a code-code.
Manufacturers should be liable for the poor quality of the devices they make. Software vulnerabilities are a fact of life, because there is no driving force to be better. Strict liability would force the industry to be more like other engineering disciplines.
There is a line somewhere, and beyond that line is negligence. A developer exposing a potential vulnerability in an internal service that does not handle sensitive information is clearly not across that line, a company that creates routers that constantly have serious holes, that handle sensitive information, seems clearly on the other side.
Deciding exactly where that line exists is obviously complex.
>>> Everyone deploying it is liable.
> I've been shipping production software for years...
Have you ever shipped software which depends on openssl? If not, then pretend that you have. Since you believe that you are liable, can you give me a ballpark of how much money you think you personally should be sued for because you deployed something using openssl?
> Since you believe that you are liable, can you give me a ballpark of how much money you think you personally should be sued for because you deployed something using openssl?
This is a really ridiculous question. I've already stated that these things are complicated - you're asking for a hard number?
Companies should take responsibility for their users data, which includes understanding the risk involved in third party libraries they use.
If they're concerned about fees, invest in the security of the project you're using.
But this is all based on some hypothetical, undefined 'law', so arguing about the specific mechanics is pointless.
> you're asking for a hard number?
No, I am not asking for a hard number, I specifically asked for a ballpark.
> invest in the security of the project you're using
I agree, but slapping fines of developers for using openssl to enhance security makes it a bit hard for anyone to afford putting any extra money towards security
> arguing about the specific mechanics is pointless
Agreed, my goal is not to flesh out the mechanics, it is to demonstrate the pitfalls of such a law. I'm only asking for a ballpark (again, not a hard number) so that you can personally understand why you and every other serious developer would be sued out of existence unless you propose obscenely small fines (which would make the whole idea useless, because then developers could easily afford to be negligent without getting too much of an increase in fines).
Yes, and it's a fake law that doesn't exist. How would I possibly answer this?
Off handedly, I'd say that the fine could really range depending on a lot of things. Was this an outdated version of OpenSSL that they just didn't patch? Was it a programmer error using the library? A 0day? All of these things would probably make a big different - charging companies for 0days in 3rd party code, in at least many cases, would not make sense.
> I agree, but slapping fines of developers for using openssl to enhance security makes it a bit hard for anyone to afford putting any extra money towards security
At some point if companies can't afford to keep users safe maybe they just shouldn't be companies. And if we're talking about router companies, they have the cash.
> why you and every other serious developer would be sued out of existence unless you propose obscenely small fines
I would imagine instead that companies would have insurance around these issues to cover developers, but again, the legal components of this are not something I'd want to get into since I'm not qualified to.
Well you've just made the workaround trivial. Open source the majority of everything under a separate org and then use that stuff from the product being shipped. Therefore any vulns are not their problem.
>And if we're talking about router companies, they have the cash
I don't think you understand how tiny the margins are in consumer networking gear. Lowest price dominates.
>the legal components of this are not something I'd want to get into since I'm not qualified to.
Suggesting they be liable is a legal component.
you mean like, say, routing all of the traffic from my system to the internet?
No commerce, no liability.
You nailed the problem here, though you don't seem to realize it. Yes, software is very complex. Maybe it should be made simpler instead of buggier.
Nobody has half a fucking clue where the libraries they're slapping together come from, nor how they're maintained, nor how they're vulnerable. It gets worse every day with trash like DockerHub, and has no relief in sight.
So yeah -- let the folks who won't adhere to proper engineering burn.
So you consider well-known and well-understood design limitations to be comparable to unknown defects?
At least users can apply workarounds in that condition. As it stands, there are no options for the owner of the device.
I think that there would probably need to be classifications of software.
Things like:
1) Is this infrastructure (routers, scada)
2) What level of user data is exposed to this software ? (unencrypted user data, credit card info, etc - we already do this to some extent)
3) What level of exposure exists? (NAT'd, routable, etc)
And then start imposing restrictions on software in those cases.
But this is very off-the-cuff, obviously it's far more complex than this. But someone needs to be responsible.
The problem is that this is entirely useless.
There are basically two classes of software company.
The first is the likes of Google or Mozilla. They, as a rule, do the right thing. All humans make mistakes but the mistakes are understandable and there isn't really much we can expect to incentivize them to do that they aren't already doing.
The second is Fly By Night IoT Device Corporation. They make garbage, it has a million vulnerabilities, but they're judgment proof. If you sue them they just file for bankruptcy. Many of them don't even exist within your jurisdiction and the ones that do are likely to have gone out of business by the time you get around to filing a lawsuit. You might as well pass a law imposing liability on raccoons for spilling garbage.
There is a much better solution to all of this. Fund a government agency to search for vulnerabilities in popular products and report the vulnerabilities to the developers. Then remove products from the market that have had known unpatched vulnerabilities for more than a limited amount of time, and require updates to be offered to any product sold in the past X number of years.
Because it's a lot easier to get a company to spend $5000 in developer time to fix their garbage than to get them not to avoid a twelve billion dollar lawsuit by filing for bankruptcy -- which only leaves all their customers in the lurch with hardware that will then never be patched.
Cisco hasn't owned Linksys in years and Linksys itself is tiny. This kind of liability absolutely could bankrupt them.
And they're one of the major players. There are companies making this kind of hardware with like twelve employees.
The barrier to entry is so low that even individuals commonly make one-offs from scratch for personal use.
I didn't say they did... I was providing two examples. I wouldn't call linksys tiny, either.
You're assuming a lot about the costs of this liability for a made up law with no defined penalty.
Maybe if companies building software can't afford to keep it safe... they shouldn't be companies? Is that so controversial?
But Cisco (i.e. Talos) are the ones finding the vulnerabilities in routers made by other companies in this case.
> Maybe if companies building software can't afford to keep it safe... they shouldn't be companies? Is that so controversial?
They still would be companies though. That's the point. If they expect to be out of business by then regardless, or they're outside of your jurisdiction, or they know they're judgment proof, it doesn't change their behavior.
It's like trying to address homelessness by allowing the victims of panhandling to sue the perpetrators. There is no blood to be had from that stone.
All you do is make the problem worse, because every company you destroy is a company which is no longer around to patch their installed base of devices. Meanwhile they're immediately replaced in the market by another company which is no better.
Regulation and liability only works against monopolies and other huge companies. When you actually have a competitive market like this, you need to use the carrot rather than the stick.
That's not true at all. Many industries that are very competitive and are full of small companies are effectively regulated.
>There is no blood to be had from that stone.
There's a simple fix to this problem. You require companies to carry insurance to cover the problems you're talking about. We do it with general contractors, doctors, tree removal companies etc...
The regulation says it's illegal to manufacturer, sale, or distribute non-licensed routers, and part of the requirement for licensing is insurance.
I'm not saying that this is necessarily the best course of action in this instance, but there are definitely time tested solutions for the problem you're describing.
There are many industries that are very competitive and full of small companies and have regulations, but what most commonly happens in those cases is that the regulations are rarely enforced which nobody much minds because the competition is preventing abusive practices regardless.
> There's a simple fix to this problem. You require companies to carry insurance to cover the problems you're talking about. We do it with general contractors, doctors, tree removal companies etc...
None of those things happen at scale. When a doctor makes a mistake, it affects one patient. A single security vulnerability can affect millions of people.
That's the problem with this. Typically what regulators try to do with risk is to find a deep pocket to stick it to that can absorb it with minimal consequences, but there isn't one here because the risk is large compared to the (inexpensive) cost of the device.
It's also a poor thing to try to insure because the main risk factor is code quality but insurance companies are generally not equipped to evaluate that. It doesn't help anybody to triple the price of every device just so the customer can still get pwned because once the insurance is covering it the developers lose the incentive the liability was supposed to be giving them to improve their security.
Again I don't think this is true at all. Some counter examples: restaurants, electricians, general contractors, engineering firms, beauty salons, and tanning salons.
>None of those things happen at scale. When a doctor makes a mistake, it affects one patient. A single security vulnerability can affect millions of people.
A single bridge failure can affect an entire city, and a large building collapse could cost billions in payouts--yet engineering and construction firms can and do buy insurance to cover these things.
Magnitude isn't a problem here, even insurance companies buy insurance from larger insurance companies.
>It's also a poor thing to try to insure because the main risk factor is code quality but insurance companies are generally not equipped to evaluate that.
Insurance companies are able to evaluate risk factors for every industry--they are better able to evaluate risk than anyone else, and it's not like they wouldn't hire domain experts.
There's nothing special about software in this regard--it's a complex system, but the insurance industry regularly insurances against damage resulting from far more complex systems than software--weather for instance.
I'm not sure if requiring router manufacturers to buy insurance would lead to a net benefit or not, but the problems you're creating have already been solved by other industries. There's nothing magic about software that makes it impossible to insure.
That said in extreme cases like e.g. airplanes I think it would be fair to consider it negligent when code is just brought into production without any kind of debugging or testing.
I guess the stakes decide when something is or isn't negligent.
Next time you get a prescription filled, ask yourself if you're willing to pay that much for a router.
Yeah, definitely. Especially for infrastructure.
I realize the implications of this are significant.
I don't think the solution is "all bugs cost every company money for every product", but there's definitely more or less risk involved in some software and we are well past the point of negligence from router manufacturers - the vulnerabilities we see from them are absolutely absurd.