But the users whose data was emitted should have been immediately notified. That's (a) law in some places, (b) common decency if one party holds another's PII and then fails to keep it private.
> But the users whose data was emitted should have been immediately notified.
If we’re still talking about the same bug… I thought that there was no evidence that anybody’s data was exfiltrated through this vulnerability? Granted, absence of evidence is not evidence of absence, but who, exactly, are you saying should be notified?
I would say yes, if some person’s PII data was improperly disclosed, yes, disclose the breach to that person. But if there is not any evidence that some particular person’s data was exposed here, do you go around telling people that their data “could have” been accessed, “if”?
Physical security analogy—let’s say I found out that the window was unlocked. It’s been unlocked for three years, and I pull security tapes. Nobody is on tape coming in through the window, but the old tapes have been erased. I don’t have any evidence that anybody came in through the window, and yet I can’t disprove it either.
Google was able to finger a specific number of accounts that had data marked as private that may have been shared with third parties. The thing that makes this issue unique and interesting is that Google is claiming is that they deleted all the relevant logs, so they can't confirm whether the private information was indeed shared or not. This is a big problem since if this becomes a valid way of deferring responsibility or accountability, it creates a major incentive for companies to copy Google's claim here.
That doesn’t sound especially unique or interesting, I would expect API access logs to expire after a time and without more knowledge of the specifics, two weeks seems reasonable to me. I would assume that the logs themselves contain PII so increasing the retention has a risk, too. Speaking of retention, given GDPR I would expect the logs to be expired after some known amount of time just for regulatory compliance reasons.
If you go too hard towards forcing disclosures you get pathological incentives to not retain the logs in the first place, the same way people at large companies these days will keep some discussions out of email so they can’t get subpoenaed. That’s not an excuse for bad behavior, but if you force companies to retain more logs for audit purposes, and you force companies to have PII retention policies that limit the retention period, you can easily force a company into a position where the cheapest way out is to reduce the detail in the logs to the point where they’re not useful for security audits any more (if this has the primary purpose of PII retention compliance).
Logs with personal information anonymized are still just as useful for security and other system audits. You would be able to clearly see unauthorized access of A from B, even if A and B could no longer be identified.
And you're ignoring the biggest risk here. If this defense of claiming 'we see there was a trivially exploited issue to allow unauthorized access to data users had marked as private, but we threw away all logs so we can't be expected to see if it was exploited, or be held to any level of accountability' passes for acceptable, it's going to set a far worse precedent than any sort of legal action. Get hacked? Worried about regulatory requirements? No problem, just migrate to a two week cycle of completely deleting all logs, patch it, and stall for 2 weeks. There, you can now hoenstly say you have 'no evidence this attack ever happened.'
You're right! There are laws in some places requiring notification in the event of a breach. California has one of these, and some provisions of GDPR are similar.
With that said, I don't think any of these require notification in the event of the abstract possibility, unsupported by any evidence, of a data breach. This is because there is a substantial difference between data that was emitted (factually sent somewhere) and exposed (could have been sent somewhere), and laws tend to trigger on the former.
If you're aware of relevant laws I have missed, I would love to know!
It's disappointing to see people defending Google on this.
Whether the vulnerability was discovered internally or not, they were leaking people's data, and the responsible thing to do is tell them. Even if it's only a possibility, people have the right to know.
I don't think that's up for debate. Both the WSJ and Google's own engineers came to the conclusion that they were. If the data wasn't leaking there wouldn't be anything for Google to cover up in their memo.
The only question left is who was affected, and Google doesn't know because they deleted the logs. The responsible thing to do would be notify everybody using that part of the service.
I agree that it is not up for debate. They did not lose any information. The google announcement here https://www.blog.google/technology/safety-security/project-s... says that they looked for leakages and We found no evidence that any developer was aware of this bug, or abusing the API, and we found no evidence that any Profile data was misused.
The difference is between data being exposed and data being leaked. The difference is quite critical.
First, I don't think the difference between exposed and leaked matters with respect to whether they need to notify users about it.
In any case, I don't believe their answer. Once the API response leaves the server with extra information there's no way for them to know which fields the caller looked at because it's all done client side.
Yes. E.g. did you find a whiteboard facing an open window? Did leave a confidential document sitting on their desk? Did someone forget to close the filing cabinet to sensitive documents? Has anyone ever been able to access confidential information at your company without permission?
Of course we can pick and choose analogies (hint: we'll never get it right, but that's what happens when comparisons are asked for). But if we're asking for disclosures for security holes that could lead (or have lead) to unauthorized access, I expect to see a seemingly interminable list.
No, they don't: they're all more severe than what happened at G+ with this vulnerability. Vulnerabilities of the kind we're discussing are utterly routine, and would probably merit a sev:low in an external assessment.
Depends on the industry. E.g. if you're working in defense or healthcare, then just the possibility of a data leak might be something you're obligated to report on. And a Google- or Facebook-size company might easily fall into the category where even "near miss" events should be disclosed.
Basically you have to conduct an internal risk evaluation and depending on the overall risk assessment, you need or don't need to publicly report on it. Of course the bar is much lower than 'certain data leak'.
I won't do work for the Federal government, but I've worked with companies of all sizes in healthcare, manufacturing, finance, and utilities, and at none of them was it a norm that internal vulnerabilities be disclosed publicly.
People keep saying that there are certain kinds of companies where you have to disclose, and I have come to the conclusion that they are simply making that up because it sounds good to them.
I have worked in healthcare related systems before that needs to be HIPAA compliant, even for those systems public disclosure of a vulnerability is not a requirement. No software is bug free, and many seemingly benign bugs are security vulnerabilities.
Try and name one company that reports all their bugs (security/non security) discovered internally.
With respect to just the possibility of a data leak might be something you're obligated to report on, I haven't heard of this being a real requirement. I would be curious to see links or evidence to the contrary.
But the users whose data was emitted should have been immediately notified. That's (a) law in some places, (b) common decency if one party holds another's PII and then fails to keep it private.