But rewind to last year, when I was still at Latacora. Ask me the question: can I hire you to make my development process more secure? Sure, I think I can add value there. Ask me instead: can I hire you to make my software liability-proof? Not a chance.
Take 9 strong software security people and divide them into 3 teams. Give each team a stretch of time to find vulnerabilities. There will be a ton of overlap in the findings, but each team will find different things. One team will happen to have a specialty in the low-level details of the platform it's running on; another will spend 80% of their cycles thinking about SSRF and HTTP desync vulnerabilities; still another will happen to have a reliable process for exhaustively testing authorization. Don't get me started on K8s or Electron or cryptography or iOS or browser extensions or Node.js.
And that's all for pretty standard app stack stuff. None of those problems are the subtext for Perlroth's book; the vulnerabilities she's trying to write about are in low-level C/C++ code. The biggest security teams in the world have build enormous, carefully-instrumented fuzzing farms for this stuff and they don't find everything.
I literally mean nobody.
I think you could stand a chance if you designed your product to fit the limitations of what we can deliver reliably. You'd lose most of your features. You'd ship boring CRUD stuff exclusively on your own dedicated hardware, and you'd build it with minimal library support. It would be excruciating, but people do it. Just not for any of the kinds of software we normally interact with.
> I think you could stand a chance if you designed your product to fit the limitations of what we can deliver reliably. You'd lose most of your features. You'd ship boring CRUD stuff exclusively on your own dedicated hardware, and you'd build it with minimal library support. It would be excruciating, but people do it. Just not for any of the kinds of software we normally interact with.
I think we are in agreement then. If you are targeting K8S or Electron, you've already lost the battle against many threat-models that matter for liability. I think what you are pushing back against is people imagine bug-free software and they think "oh maybe 4x more expensive and it will look like it's from 2005" while the reality is more like table-stakes of 10x more expensive and it will look like it's from 1980.
I personally think that the tradeoffs are worth it for more industries than currently make it, but I don't think the law can be nuanced enough to both be effective and not cause massive collateral damage to many other industries. Look at the chilling effect regulation has had on software in the medical industry, and yet those regulations seem to have done little to increase the resources required for an attacker who wishes to exfiltrate patient data.
Nate Lawson used to tell me (I assume he'd still tell me) that companies trying to ship secure software need to budget 10x for verification what they do for implementation. The best companies in the world don't even budget 1x. I'm not sure it's reasonable to ask them to. I think we'll know stuff in 10 years that will change how we look at things.
It's fundamentally impossible given that you won't control everything about the operating environment of the software, and can't see into the future.
I mean, even if you could create a perfect piece of software with no bugs present at the time, that's still not enough, because vulnerabilities in dependent components will arise which were unknown at the time.
For example, if you'd written the perfect web browser a few years back, how would you prevent vulnerability to CPU-level attacks such as Spectre and Meltdown discovered later on?
Or consider if you write the perfect wireless networking firmware, but then end up being subject to vulnerabilities in the protocol standards (WEP was a good example of this)?
This is on top of software development being such a complex process that even the best of its practitioners write code strewn with bugs.
Why not? Given the cost of writing secure software, for all but the highest volumes, you can ship it as a dedicated app on its own hardware.
> For example, if you'd written the perfect web browser a few years back, how would you prevent vulnerability to CPU-level attacks such as Spectre and Meltdown discovered later on?
Given that we are talking about liability here. Presumably Spectre and Meltdown would be primarily liabilities for hardware vendors. Software shipped after the vendors recommend software mitigations would shift that, but I don't think
> Or consider if you write the perfect wireless networking firmware, but then end up being subject to vulnerabilities in the protocol standards (WEP was a good example of this)?
First we must put aside the fact that WEP raised red-flags for cryptographers far before an exploit was found, and the fact that those concerns were dismissed with a hand wavy "People can tap into Ethernet lines too, this is just 'Wired Equivalent Privacy'"
Now, I think that if you write software that faithfully implements a protocol, advertise it as implementing that protocol, and it is exploited not in-spite-of but because it did so, what exactly are you liable for?
Even knowing that WEP, WPA, WPA2 and WPA3 are all flawed protocols, I'm sure there will be a WPA4 some day that is also flawed. If the only thing we had to worry about in WiFi stacks were protocol flaws, attackers would have a much harder time of things. No flaw in the WEP protocol allowed gaining execution access on the WiFi adapter, much less the host computer (though given the bus designs of the time, the former inevitably led to the latter).
In my opinion, if Jeff Bezos, Satya Nadella, Sundar Pichai, and Tim Cook all got together and wanted to put together a team that ship secure commercial software, they would probably be unable to put together a team that knew how to get to the $10M level, and there is zero chance at the $1B level. If they all worked together and put their full focus and resources on the problem, they might be able to put together a team that could invent how to get to the $10M level, but they would not be able to put together a team that already knew how and had experience doing so. The key difference between these two cases being that in the former the team would need to invent good practices and experiment to see if they worked, where as the latter only needs to apply already existing known good methodology.
If you want some 3rd party evidence for my claims, not that I am claiming this is exhaustive proof, bug bounties that get claimed are, generally speaking, less than the cost of discovery for a bug otherwise security researchers would not put in the effort to discover than claim them. Not a single one of their premier products that they ship and sell [1][2][3] offers a bug bounty over $1M for total and complete remote zero-interaction compromise. It is very unlikely that they can do an order of magnitude better than the premier products just because they want to.
[1] https://www.microsoft.com/en-us/msrc/bounty
[2] https://www.google.com/about/appsecurity/android-rewards/
Do you literally mean "nobody" here? As in if I wanted to hire you to put a team together to reliably ship secure commercial software, you couldn't do it either?
I think we have, as an industry, tacitly agreed that it's better to ship cheap, insecure software than it is to ship expensive, secure software. A lot of the innovation in software has occurred specifically because it is so inexpensive.
It seems clear to me that, so far, this tradeoff has been a net benefit, but at some point we may want to trade the inexpensiveness and innovation for some security, particularly has we start to put software into more things that can kill and maim us.