What a beautifully structured, thoughtful, surprising, and helpful document!
These in particular jump out:
- Risk profiles for diverse users can be very different:
Any discussion of the pros and cons of disclosure should take into account that risk profiles vary drastically. Taking this argument to the extreme, the question arises: "Is it OK to put 100m people at risk of inconvenience if I can reduce the risk of death for 5 people?"
- Ultimately a patch must be published. If a corresponding vulnerability disclosure does not also go out this leads to information asymmetry between attackers and defenders:
People in the offensive business can build infrastructure that helps them rapidly analyze patches and get the information they need out of them. Defenders, mostly due to organizational and not technical reasons, can not do this.
- The incentives inherent to the software development lifecycle are out of alignment with the incentives of writing secure code:
By the time the security flaws in the newly-shipped features become evident, [the software manager responsible] is four steps in the career ladder and two companies away from the risk they created.
The last point is the one that really rings out to me as an Info/IT Security person.
While these incentives aren't aligned it is unlikely there will be a significant improvement in overall IT Security practice.
It's been proven time and again that the optimal approach for organizations is "move fast" and worry about security later.
Of course the problem from a societal standpoint is that there are externalities there, so the entities suffering from the consequences of this mismatch of incentives aren't the same as the entities making the money out of it.
These in particular jump out:
- Risk profiles for diverse users can be very different:
Any discussion of the pros and cons of disclosure should take into account that risk profiles vary drastically. Taking this argument to the extreme, the question arises: "Is it OK to put 100m people at risk of inconvenience if I can reduce the risk of death for 5 people?"
- Ultimately a patch must be published. If a corresponding vulnerability disclosure does not also go out this leads to information asymmetry between attackers and defenders:
People in the offensive business can build infrastructure that helps them rapidly analyze patches and get the information they need out of them. Defenders, mostly due to organizational and not technical reasons, can not do this.
- The incentives inherent to the software development lifecycle are out of alignment with the incentives of writing secure code:
By the time the security flaws in the newly-shipped features become evident, [the software manager responsible] is four steps in the career ladder and two companies away from the risk they created.
While these incentives aren't aligned it is unlikely there will be a significant improvement in overall IT Security practice.
It's been proven time and again that the optimal approach for organizations is "move fast" and worry about security later.
Of course the problem from a societal standpoint is that there are externalities there, so the entities suffering from the consequences of this mismatch of incentives aren't the same as the entities making the money out of it.