Apparently unpopular opinion: an internally-discovered vulnerability with no evidence of abuse is not a breach and does not require public disclosure.
Please stop pretending this isn't a big deal just because of a hard-on for Google. If you'll put a 10 man company out of business for their complacency and ignorance you should be lining up at Google HQ with pitchforks over this. They're supposed to be above this. They are hailed as a gold standard.
Also, I fundamentally disagree with your example. If they did an adequate investigation, using a 3rd party service, and found no evidence of my data being accessed by a 3rd party, and then fixed it- I'd say, "Good job checking up on yourselves" and move on.
Security is still incredibly hard to get right. I'm willing to bet your service has security holes in it, right now- and that's not a hit against you. We haven't mastered these systems and anyone who thinks they have is just waiting to get bit in the ass. Every security professional knows: It's never, ever, a question of "if", but of "when".
If a company is disincentivized to look for security holes because it's highly likely it will find them; that company is on the fast-track to failing.
> If they did an adequate investigation, using a 3rd party service, and found no evidence of my data being accessed by a 3rd party
They found no evidence of data being accessed, but they also don't share how this particular system tracks data that is accessed. This system was vulnerable for 2-3 years. What if you left your car at my house and you found a dent on it, but I claim that I didn't have any security footage of someone damaging your car without mentioning that I don't actually have security cameras.
> I'm willing to bet your service has security holes in it...
You're right, and it I find that my NTP service is exploitable and anyone can DDOS me I'll fix it and move on. There's no need to disclose that I'm an idiot when it doesn't affect other people. But when I accidentally leave my servers mis-configured and my API unprotected against unauthorized access I would make a post about it. We're not talking about an arbitrary vulnerability that lets people echo hello on a Google server. They left data exposed. I would like to know if it involves me.
I don't see any evidence to back up this assertion. FWIW I don't believe this is true.
Sony hasn’t failed yet.
I don’t think your opinion matches with reality.
How'd you feel then?
Also bridges are built with a much bigger lifetime in mind and require (proving GP's point) a much bigger investment.
We've absolutely mastered these systems.
We just prioritize rapid development time and ease of use over security.
People make fun of DoD / space price tags (and admittedly, there's still a lot of crap sold there), but it's a trade off.
If we wanted computers to cost $x0,000 and OSes to cost $x,000, and the pace of progress to be glacial, we could have completely secure systems today.
It's a choice, not an impossibility.
That's an interesting theory that's not supported by historical evidence as far as I can tell. When computers were expensive, there just were less people with access. The systems were not any more secure.
For example, the parent article, the one this comment is ostensibly in response to, has nothing to do with operating system security.
A better example is maybe instead of Google spending $xxx,000 to develop the system that was found insecure they should have spent $x,000,000 so they had more resources devoted to the security aspects.
Perhaps this is too high for this system to exist; well maybe that system just shouldn't exist if it can't be secured properly with the budget for it.
> If we wanted computers to cost $x0,000 and OSes to cost $x,000, and the pace of progress to be glacial, we could have completely secure systems today.
> It's a choice, not an impossibility.
Progress in core OSes and conventional hardware has already slowed down to a glacial pace, compared with previous decades. Rapid development is often used to just create a churn of useless sidegrades and other poorly thought out things (deceptively sold as upgrades).
It might be time to make that different set of choices.
there's two points there
acknowledging it's impossible to have zero bugs ... and ... acknowledging that there will be exploits.
sure you can do better than average but "completely secure" is a myth
as for DoD there's this from 3 days ago
Which is my point and why the broad assertion is wrong.
Look at a VxWorks type OS. Or OpenBSD. Limited capability and compatibility, very strong security guarantees.
"Completely secure" isn't a mythical unicorn. It just costs time and money. A LOT of time and money.
But is that really what would happen? Vulnerabilities are frequently found and publicly reported. The reaction depends on the type of vulnerability (how stupid it sounds) and on whether or not the vulnerability resulted in a breach. You don't get hit equally hard for all security issues.
I think both users and developers have to be mature enough to deal with this sort of thing without resorting to secrecy. Secrecy creates distrust as the reaction to this particular Google+ issue shows.
Were this actually the case, the CSV list (not even mentioning Google's own Project Zero) would have disincentivized companies and projects years ago.
With big enough repercussions it should incentivize processes that don't allow it to happen in the first place. This is how HIPPA and various other things work already and it does a decent job (not perfect though).
I'd also say that we need decide if mistakes are forgivable and whether or not if it's based on impact.
Perhaps for a small data leak it's forgivable, and we won't hit them with a huge fine or whatever. If it's a big leak then maybe we need to jail people.
It's a bit of a strawman to say everything has security holes because it's assuming the problem is unfixable from the start.
It's a bit like launching a person into space. "We know that probability we'll be sending people to their death is high, let's not bother then." We decided to do it anyway but we set extremely high bars for safety.
Especially given the way Google, quite rightly, expose vulnerabilities through Project Zero.
Plus, were this the case, the CSV list would have stunted vulnerability exploration across the board. Have you seen the list of vulnerabilities discovered in curl?
You're supposed to be above this here on HN.
So besides applications, infrastructure, distributed systems, reliability, money & security what have the Romans ever given us?
Furthermore, if every potential vulnerability that might have been exploited needs to be reported as a breach... then each and every bug in any library and other dependency you use likely needs a breach report too - after all, you typically cannot verify retrospectively whether that exploit wasn't independently discovered and abused before the fix.
I'm not even positive such a reporting requirement would really be a bad idea, but it would definitely needs some more mature reporting and population education to tell the two classes of issue apart, especially since it's pretty vague where you draw the line on what needs publication once you get that far.
Please don't project strawmen onto other users, it's intellectually weak and rude besides.
That means that Google was proactively checking it’s work to make sure it was secure, unlike your example where nobody was likely ever going to notice that bucket was misconfigured.
They’re the gold standard because they find and clean up their own shit, even when nobody is pressing them to do it.
Really? If Google has access logging on its content, and as in your example an AWS bucket can be configured for access logging then it would be fairly straightforward to identify if the data was accessed.
It isn't that it is Google that makes the difference, but the extent of the damage.
This is the information that was possibly was exposed: https://developers.google.com/+/web/api/rest/latest/people
> We made Google+ with privacy in mind and therefore keep this API’s log data for only two weeks. That means we cannot confirm which users were impacted by this bug. However, we ran a detailed analysis over the two weeks prior to patching the bug, and from that analysis, the Profiles of up to 500,000 Google+ accounts were potentially affected. Our analysis showed that up to 438 applications may have used this API.
The original WSJ article shared this version of "no evidence of abuse", and it's not very reassuring.
"Because the company kept a limited set of activity logs, it was unable to determine which users were affected and what types of data may potentially have been improperly collected, the two people briefed on the matter said. The bug existed since 2015, and it is unclear whether a larger number of users may have been affected over that time."
It's also not clear that the activity logs would even have the context to distinguish normal access from unauthorized access.
We need disclosure in Open Source because if attention is not drawn to the vuln downstream users won't upgrade, but highly motivated attackers will have what they need. With non-source-available software, there are fewer opportunities for attackers to learn of any vulns.
Bear in mind that proving no abuse is impossible, as it's always possible that the hypothetical abuser got one step further than your investigation and covered their tracks.
When such a vulnerability is discovered the right thing to do is to inform the users of its possible severity and the duration during which it was available.
Always.
At which point why not just stop being proactive?
Hardline stances sell great on forums, that doesn't make them right.
The attitude that absence of evidence should be treated as if it didn't happen leads to exactly that conclusion - that it's better to not be able to tell what's happening.
I'd love for that to happen. Maybe then everyone will start to pick up on the fact that all of our computer systems are insanely insecure.
Canada is going to require disclosure of breaches starting November 1. That may allow for companies to still fail to disclose the _possibility_ of breaches, however.
https://globalnews.ca/news/4122202/data-breach-canada-privac...
Long story short, California requires labeling of things that may contain chemicals hazardous for a variety of reasons. The idea was simple - never not inform. The intentions were pure.
The result is that basically everything has a vague and uninformative label about how it may contain chemicals that could be hazardous. The labels are spectacularly uninformative and incredibly numerous. They are universally ignored by everyone, as they constitute a sea of noise.
The net result is that a wonderful, laudable, pure, kind, and compassionate idea - never not inform - has led to a deluge of useless informational notices in which actual useful notices are impossible to find.
It might be worth considering that there could be a lesson in there.
Warning labels have dubious efficacy, as evidenced by decades of grotesque warnings upon cigarette packaging and their limited success at reducing consumption; but that's not to say we ought not be able to know about the potential harms of a product or service, just that product labels sort of suck as a method of informing users.
OTOH, Canada requires nutritional information on all food, and that's reasonably useful and successful _because_ the content of that label is strictly defined and reasonably useful.
Nutritional information is relatively easy to provide is thoroughly exhaustive detail. How does one go about informing about data events that may or may not have occurred, and may or may not occur in the future, in a way that's comprehensible to users who must be assumed to have absolutely no technical grounding whatsoever?
The most useful informative warning I think that could be reasonably provided runs like this: "Please be aware that any data you provide this service, and any data this service gathers, could previously, presently, or in the future be the subject of a data breach that may or may not be detected."
While the warning could of course be improved by being made more specific about what data is concerned, this does not seem like a good way to produce useful and informative warnings. Instead, it seems to me that attempting to pursue that most wonderful of ideals - never fail to inform - could easily produce a sea of overcautious attempts to ensure a user is never not informed, and instead over-informed into oblivion.
While such labels might potentially be successful in scaring users into using services less, this might not be the same as informing users.
I do hope I've communicated clearly here. Please let me know if anything could have been better-written. More importantly, I've clearly failed to understand some of your wise and well-made points. Can you help me with what I've missed?
X Authentication
X Financial
X Communications
X Property
However, that's just my pie-in-the-sky desire!
Pragmatically, as a technical person, I'd personally be happy with regular release notes of product revisions, including SaaS products, and which are paired with a technical-oriented blog that details the notes in further clarity for the technically adept. The role of journalists can step in here, and appropriately severe information will spread much as it does now.
The upshot is that technical folks like us may learn a thing or two via such an open communication. If everyone did it then there would be less fear to do it and there would be more information avaialable about common risks and their mitigations.
Companies tend not to be terribly good at articulating where we are on that sort of scale.
Even the companies who are the very best at communications will tend to struggle to communicate clearly when filtered through a press that have strong incentives to construe everything as a data breach. Lay people reading either of your statements will tend to stop at "there's no evidence" and go "What do you mean, 'no evidence'!? I want certainty!". Witness how readily and widely this whole G+ event has been mis-reported as MASSIVE DATA BREACH.
While you're completely correct, perhaps there's room for subtlety here.
After reading it, I got the impression they have no idea what did, or did not happen.
Keep in might that effectively means you'd need to report a potential breach every patch tuesday if you're running on windows, and similarly frequently for most linux distros. Oh, and you'd need to report all vulnerabilities in any dependencies of any software you build on, such as webframeworks, libraries, other apps... everything. Oh, and svn had a sha1 collision vulnerability, so any software that ever used SVN, and anything that depended on it might need to report a breach. With meltdown and spectre... OK, we've basically arrived at the point that if your business was somehow in nebulous proximity to a computing device it may well have posed the risk of a breach. Where does it stop?
I mean - I'd love to live in a world where that were a realistic strategy, but in the I WANT MOAR DEPENDENCIES world we live in, which is just waking up to dealing with security issues, I'm not sure this is realistic, nor helpful.
So it's a shame that the best we have is the absence of evidence - but for all my frustration about the cavalier risks google took here, I do actually believe that's pretty plausible evidence of actual absence. After all, if this had been discovered and meaningfully exploited, I really doubt the exploiter would have stopped.
Reporting this kind of stuff as a breach is basically FUD. Essentially: You're distracting from real security issues, of which there are legion. No need to get all hypothetical about it - yet. Google made a shameful bug, but this isn't breach, not by any useful definition of breach.
Put another way, "no evidence of abuse" is not the same thing as "evidence of no abuse".
A company can claim EVERY bug was never exploited, and nobody can disprove them.
There is an inherent conflict of interest there.
The problem with what Google is doing is that they are insinuating that a lack of evidence is evidence of lack. This is not unlike when companies like Equifax claim “we have no evidence...”
We should not be rewarding companies for strategically avoiding culpability.
I understand the position that excessive log retention can itself create a high-risk metadata pool, but there are ways to mitigate that by tokenizing them or removing PII data without having zero usage information.
https://en.wikipedia.org/wiki/Moral_luck#The_problem_of_mora...
Who discovers it or if you can prove it was abused, is not relevant to the security issue.
I'd consider that at least a disingenious reading of "we have no evidence that bad things happened".
400 third-party apps had access to this info. It's not that "Google knows that there wasn't any abuse" but that "Google doesn't know whether there was any abuse, because it didn't have the proper systems in place to check for that anyway."
It's kind of like you saw no crime happening because you didn't look. But that says nothing about whether or not the crime actually happened.
We should not equate "no evidence of abuse" to "evidence of zero abuse", that type of plausible deniability is not going to push improvement in protecting user privacy. Especially in this case, no evidence was really a lack of evidence (probably worse), because logs were only kept for a short period of time.
In the legal sense, or based on "industry practice", they might not be _required_ to disclose to the public. But can they, and should they? because we have all witnessed Google gone above and beyond, and done amazing things over the years. I'm a google fan, and I'm very disappointed by how this was handled.