Re: The Treadmill

[Thomas Dullien <thomas.dullien () googlemail com>]

Hey there,

just to argue a counterpoint - irrespective of the concrete proposal
(software bill-of-materials etc.), the reality is that most huge
software companies reap excess profits from incurring risk on behalf
of society. The state of Android security was crappy *by management
decision*; e.g. Andy Rubin deliberately incurred technical debt that
exposed lots of customers; and with all the efforts Microsoft has done
to shore up the security of their platform, it pales with the profits
they have run in the meantime.

If you allow one fraction of society to make an excess profit for
incurring risks to everybody else, then they will incur an excess
risk. In some sense, the big software vendors have been "short-selling
geopolitical volatility using their customers as collateral" for a few
decades, and when people complain about the billions of damages that
IP-theft-via-hacking does, those vendors do deserve some of the blame.

So ... what are the options to align risk-taking incentives? All of
those options will infuriate software companies, but there is no way
to fix the risk alignment without infuriating those that profit off of
it.

Some options:
1) Software liability.
2) Government-imposed fines for actually exploited vulnerabilities, as
percentage of gross profit (This is software liability but cutting out
the legal profiteering).
3) Personal liability for software executives that make "I accept the
risk on behalf of my customers" decisions.

Any other suggestions?

Cheers,
Thomas

Am Di., 7. Apr. 2020 um 21:55 Uhr schrieb Dave Aitel <dave.aitel () gmail com>:
> I've been spending a lot of time reading policy papers on software liability recently. The theory from the policy 
> community is that you can get a software bill of materials as a vendor for every piece of code you include in your 
> tiny home router, then if the router has a known vulnerability and the vendor doesn't update it in a reasonable time, 
> and you get hacked, it's their fault and they are liable for whatever damages you have as a result, especially if 
> they didn't follow some new NIST process or whatever poorly designed "Best Practices" document makes it into the law.
>
> In general the rational for this is that "There is already software liability, enforced by the FTC, sorta" and "we 
> need to correct for shoddy software being forced on the market by using regulation" which may be contradictory 
> arguments but you don't get famous without proposing a new way to keep lawyers in the money by arguing that some 
> company either IS or IS NOT liable for the latest SQL Injection.
>
> If you're on this list, you're probably technical enough to be coughing up your skull right now at the thought that 
> these are serious suggestions, and they are. Pre-COVID they would have been next on the Congressional docket, with 
> bi-partisan support and a lot of cover from NewAmerica's policy generation machine.
>
> I think part of the problem is that software bugs are not about "Shoddy Software" any more than an aphid infestation 
> is about poor Feng Shui in your garden. I look forward to it being basically illegal to code anything in PHP by 
> Congressional Decree, but the level of complexity of the ecosystem we deal in is not reducible to some legal standard.
>
> For most of us who grew up with the Bugtraq mailing list, we remember knowing about every important vulnerability, 
> and reading basically every public exploit. That was a thing you could do. Eventually of course most people lost any 
> grip on that treadmill as the Full-Disclosure mailing list took over and then the scene exploded. Now, just to hang 
> on with our fingernails to the cutting edge you probably have something like 43 tabs open in your Chrome, each of 
> which pointing to a new exploit chain description or paper on WAF bypassing.
>
> The WAF bypassing paper (here) is particularly interesting because it points out that a lot of what we would think of 
> as useful technology that fits best practices is at best useless, and at worst, holding some sort of lifetime grudge 
> which it will express by divulging your domain admin credentials via SSRF. :)
>
> -dave
>
>
>
>
>
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunityinc com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave