5 ms·

So the argument in the linked article is this: "A mandate to disclose internal vulnerabilities would change incentives. Firms would have a reason not to want t

So the argument in the linked article is this: "A mandate to disclose internal vulnerabilities would change incentives. Firms would have a reason not to want to find vulnerabilities." My problem with this thinking is that it could be extended to finding breaches. If you have to publish every breach you're not going to want to find them. It's impossible to prove that a vulnerability has not resulted in a breach and so an argument could be made that every vulnerability has to be considered a breach. That would not be very pragmatic though, especially if we also take the view that every bug is a vulnerability (as the linked article does). I think if the ultimate goal is to protect users, we can't be dogmatic or formalistic about which incidents to publish. It has to depend on the likelihood and the severity of any damage. If a vulnerability concerns highly sensitive data and we don't know whether or not there was a breach then users should be told about the incident so they can protect themselves or change their behaviour in the future. I also think that in this particular event Google tried to downplay the likelihood of a breach. Bad idea.

tptacek 8y ago
The difference between internal work to find vulnerabilities and breach response is that one is optional and the other effectively isn't. There are incentives at play in breach response as well, but they are attenuated. And, again: so far as anyone knows, there was no breach. All software is in a continuous state of "likely breach". But words mean things: a breach happens when a vulnerability is exploited maliciously, not when it's discovered.
- fauigerzigerk 8y ago
  I didn't dispute the meaning of the words, and I agree that making internally discovered vulnerabilities public should be (legally) optional. But that raises the question which ones should and which ones shouldn't be disclosed. In my opinion, knowing for sure that there was a breach is not the right threshold in all cases. A high profile public API that had a glaring vulnerability for years seems far more likely to have been breached than most other software. Also, the more high profile the software the greater the reputational risk of being wrong. What if the bug gets leaked eventually? What if there was in fact a breach and it only becomes known later when people have already suffered the consequences? If that happens, people will question the decision not to publish and the damage to trust will be far greater. This has to be factored into the incentive structure of any disclosure or non-disclosure. I think the best course of action is to routinely disclose all vulnerabilities but not necessarily alert all end-users to all vulnerabilities.
  - tptacek 8y ago
    I don't know where to start with this, so I'll just shotgun my answers: * The vulnerability we're talking about, like all G+ vulnerabilities, has no half-life. It's fixed decisively the instant they deploy the fix to prod. There is no user response we're looking for to mitigate the vulnerability. * The incentive problem isn't eliminated just because you only target Google with the new norm. When we demand that "high-profile" companies disclose vulnerabilities, we create the sentiment, across the industry and in low-profile companies as well, that vulnerability discovery is a bad event, to be avoided. The exact opposite thing is true. * Internal vulnerabilities in high-profile applications are discovered so often that people will quickly tune them out (until someone sets out to take a scalp). It could even wind up benefiting companies with actual breaches, whose announcements will be lost in the noise, and more easily PR-spun. The basic problem here is very simple: found- and- fixed vulnerabilities aren't breaches. A vulnerability and its successful exploitation are not the same thing. It does not matter if the vulnerability is "leaked eventually", so long as it's fixed when it's found. If Google had discovered this vulnerability and then just decided to ignore it for 6 months, that would be a story. That's not what happened.
    - fauigerzigerk 8y ago
      >The basic problem here is very simple: found- and- fixed vulnerabilities aren't breaches. What makes this less than simple is that we may not know whether or not a particular vulnerability was exploited (i.e if a breach has occurred). My opinion is that the likelihood of an undiscovered breach and the potential damage of any such breach should be taken into account when deciding whether or not to disclose a particular vulnerability. >The incentive problem isn't eliminated just because you only target Google with the new norm. I have no interest in targeting Google specifically (I'm actually a shareholder). They just happen to be big and have a lot of personal data. They are in the crosshairs of regulators and politicians as well, which is another reason to err on the side of transparency. I'm also not trying to eliminate the incentive problem by limiting it to Google (or other big companies). On the contrary, my opinion is that disclosing vulnerabilities in a timely fashion should be seen as building trust and become the new normal. Making it the new normal is what should fix the incentive problem over time as people get used to it. People tuning out is not a bad thing. The difference between an actual breach and a fixed vulnerability will not be lost just because vulnerabilities are no longer kept secret. But as I said, I don't think end-users should be notified of every single vulnerability.

tptacek 8y ago

The difference between internal work to find vulnerabilities and breach response is that one is optional and the other effectively isn't. There are incentives at play in breach response as well, but they are attenuated. And, again: so far as anyone knows, there was no breach. All software is in a continuous state of "likely breach". But words mean things: a breach happens when a vulnerability is exploited maliciously, not when it's discovered.

fauigerzigerk 8y ago
I didn't dispute the meaning of the words, and I agree that making internally discovered vulnerabilities public should be (legally) optional. But that raises the question which ones should and which ones shouldn't be disclosed. In my opinion, knowing for sure that there was a breach is not the right threshold in all cases. A high profile public API that had a glaring vulnerability for years seems far more likely to have been breached than most other software. Also, the more high profile the software the greater the reputational risk of being wrong. What if the bug gets leaked eventually? What if there was in fact a breach and it only becomes known later when people have already suffered the consequences? If that happens, people will question the decision not to publish and the damage to trust will be far greater. This has to be factored into the incentive structure of any disclosure or non-disclosure. I think the best course of action is to routinely disclose all vulnerabilities but not necessarily alert all end-users to all vulnerabilities.
- tptacek 8y ago
  I don't know where to start with this, so I'll just shotgun my answers: * The vulnerability we're talking about, like all G+ vulnerabilities, has no half-life. It's fixed decisively the instant they deploy the fix to prod. There is no user response we're looking for to mitigate the vulnerability. * The incentive problem isn't eliminated just because you only target Google with the new norm. When we demand that "high-profile" companies disclose vulnerabilities, we create the sentiment, across the industry and in low-profile companies as well, that vulnerability discovery is a bad event, to be avoided. The exact opposite thing is true. * Internal vulnerabilities in high-profile applications are discovered so often that people will quickly tune them out (until someone sets out to take a scalp). It could even wind up benefiting companies with actual breaches, whose announcements will be lost in the noise, and more easily PR-spun. The basic problem here is very simple: found- and- fixed vulnerabilities aren't breaches. A vulnerability and its successful exploitation are not the same thing. It does not matter if the vulnerability is "leaked eventually", so long as it's fixed when it's found. If Google had discovered this vulnerability and then just decided to ignore it for 6 months, that would be a story. That's not what happened.
  - fauigerzigerk 8y ago
    >The basic problem here is very simple: found- and- fixed vulnerabilities aren't breaches. What makes this less than simple is that we may not know whether or not a particular vulnerability was exploited (i.e if a breach has occurred). My opinion is that the likelihood of an undiscovered breach and the potential damage of any such breach should be taken into account when deciding whether or not to disclose a particular vulnerability. >The incentive problem isn't eliminated just because you only target Google with the new norm. I have no interest in targeting Google specifically (I'm actually a shareholder). They just happen to be big and have a lot of personal data. They are in the crosshairs of regulators and politicians as well, which is another reason to err on the side of transparency. I'm also not trying to eliminate the incentive problem by limiting it to Google (or other big companies). On the contrary, my opinion is that disclosing vulnerabilities in a timely fashion should be seen as building trust and become the new normal. Making it the new normal is what should fix the incentive problem over time as people get used to it. People tuning out is not a bad thing. The difference between an actual breach and a fixed vulnerability will not be lost just because vulnerabilities are no longer kept secret. But as I said, I don't think end-users should be notified of every single vulnerability.