Google Advocates 7-Day Deadline For Vulnerability Disclosure
Trailrunner7 writes "Two security engineers for Google say the company will now support researchers publicizing details of critical vulnerabilities under active exploitation just seven days after they've alerted a company. That new grace period leaves vendors dramatically less time to create and test a patch than the previously recommended 60-day disclosure deadline for the most serious security flaws. The goal, write Chris Evans and Drew Hintz, is to prompt vendors to more quickly seal, or at least publicly react to, critical vulnerabilities and reduce the number of attacks that proliferate because of unprotected software."
What if a bug cant be fixed and systems patched in 7 days time? are they going to cut corners on something like testing?
Going from bug report to design and code a fix, to test, to roll it out to the infrastructure in 5 working days seems like an impossible benchmark to sustain even with the super brainiacs working at google
Why is there only one guy?
How incompetent is the management an organization that does not have enough coverage to deal with those issues?
Hewlett-Packard started with only two...
He's getting rather old, but he's a good mouse.
What we call incompetent, newly minted MBA drones call efficiency optimization.
Seem like they recommending it only for "critical vulnerabilities under active exploitation". For vulnerabilities where exploits increase as each day passes because of non-disclosure, I would want quick notification.
FTA and not quite in the summary:
“Our standing recommendation is that companies should fix critical vulnerabilities within 60 days — or, if a fix is not possible, they should notify the public about the risk and offer workarounds,” the two said in a blog post today. “We encourage researchers to publish their findings if reported issues will take longer to patch. Based on our experience, however, we believe that more urgent action — within seven days — is appropriate for critical vulnerabilities under active exploitation. The reason for this special designation is that each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more computers will be compromised.”
What about coporate environments that are strictly change controlled? The extra visibility may produce significant risk to systems that cannot be patched in such short order...
The big kicker is "under active exploitation". If no exploits are known in the wild, it's still necessary to light a fire under the vendor's ass(you can't assume that the flaw isn't just sitting in somebody's high-value-zero-day arsenal, or that it won't be discovered and exploited in the future); but there is a real argument in favor of trying to work with the vendor to get a proper fix in place before releasing the details, and more or less assuring that every dumb script kiddie can implement the attack if they want.
If something is already 'under active exploitation', though, the cat is already out of the bag, and the choice isn't really in your hands anymore. The clock already started ticking. Whether you like it or not, every hour it goes unfixed is more room for more attacks. Keeping quiet about it harms the ability of end users to take protective action, and really only helps the vendor save face, which isn't a terribly valuable feature.
Now, I don't doubt that Google's 'webapps and silent autoupdaters' style gives them a certain self-interested enthusiasm(compared to vendors who cater to much more sedate patch cycles) for fast disclosure; but, again, 'under active exploitation' is the phrase that makes their position(however self-interested) merely realistic. If you know that team black hat already knows about it, you don't really get to choose when it is disclosed, since that has already happened. You only get to choose how slow you make the vendor look.
Seem like they recommending it only for "critical vulnerabilities under active exploitation".
Honestly, I'm a bit surprised that they offer even seven days of cover for vulnerabilities with detected exploits. I can certainly see the wisdom of the "Please, don't release 'proof of concept exploit toolkit, not for use for evil' ten minutes after emailing the vendor about the problem..." appeal; but I'd be inclined to report the discovery of an active exploit immediately, as being a noteworthy event in itself.
Active Exploitable (in the wild) Security flaws should have ZERO day disclosures. And companies should be required to offer up mitigation tips for people who have software that isn't patched.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Not sure coding works on something the scale of google, but programmers are people and they go on vacation, funerals, get fired, get hired and freeshly acquainted with their jobs too.
Will Google be as supportive of this policy after the first time some major bug hits one of their more minor products and the guy who knows all about it is gone whereever hat week?
Huh?
Google can push out 20 versions of chrome in 7 days.
I haven't thought of anything clever to put here, but then again most of you haven't either.
They're not expecting to get 7 days but they'll reach a compromise close to what they actually want which is probably a couple of weeks, may 30 days.
Personally I think that 2 weeks is reasonable.
You could get into trouble if the guy who knows the intricacies of that area is on holiday/leave for those two weeks but that's an education/complexity problem that you should never place yourself in.
It all relies on having good testability so that you're confident that the changes have no side effects.
http://googleonlinesecurity.blogspot.com/2013/05/disclosure-timeline-for-vulnerabilities.html
If we ask the question: "for how many days in a year is a specific browser/application vulnerable to an unpatched exploit?", then we get awful numbers. There are plenty of applications used by millions of people where that number is more than half of the year.
The 7 day limit is probably a compromise between trying to get the vendor to fix the vulnerability that is actively being exploited and disclosing the information and thus increasing the pool of people who'd use the exploit.
For vulnerabilities where there is no known active exploitation, we should assume that there is. 30/60day delays are unforgivable.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
If one hour ago I was notified of a flaw in my app, and 59 minutes ago I fixed it, and 58 minutes ago I submitted it for approval it could easily be a week before it get approved.
I would say that after a week they should notify that there is a flaw, but not what the flaw is. Then maybe after 30 days release the kraken (exploitable flaw that is).
Let's say they discover a pacemaker flaw where a simple android app could be cobbled together to give pacemaker people nearby fatal heart attacks. If they release that in a week then they are vile human beings.
Most companies do seem pretty slothful in fixing these things but pushing for a company to process the flaw, analyze the flaw, find a solution, assign the workers, fix it, test it, and deploy it in under a week seems pretty extreme.
> What we call incompetent, newly minted MBA drones call efficiency optimization.
New and old MBA drones call this bonuses. Look, I did something! I reduced headcount of people who understand our critical systems to only one!
I'll see your senator, and I'll raise you two judges.
Don't get me wrong, I agree that they are screwed, it's just that the 7-day window is when black-hats are already known to be using the bug. Under those circumstances, you would be screwed no matter what: the 'disclosure' has already happened among the people who are interested in using it for evil. The only value in a delay by the 'responsible' parties is that it reduces the apparent lateness of your fix.
I disagree.
What would they do if the one dev died?
Then likely even 60 days would not be enough to get his replacement up to speed.
Any company that has employees it cannot lose deserves this.
Exactly. If it's under active exploitation, then you need to let people know about it immediately so they can defend themselves.
Delaying disclosure in that situation does no one any favors, except evil exploiters (including governments).
"First they came for the slanderers and i said nothing."
The big kicker is "under active exploitation". If no exploits are known in the wild, it's still necessary to light a fire under the vendor's ass(you can't assume that the flaw isn't just sitting in somebody's high-value-zero-day arsenal, or that it won't be discovered and exploited in the future); but there is a real argument in favor of trying to work with the vendor to get a proper fix in place before releasing the details, and more or less assuring that every dumb script kiddie can implement the attack if they want.
And yet Microsoft's policy is that unless it is "under active exploitation" they won't necessarily fix it. They get lots of notices about potential exploits, but don't fix them, even likely high targets, until someone exploits them - which, by then, is really too late.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
One of the key concepts taught in *any* decent MBA program is risk management. For a software development company, having more than one person available to make emergency fixes to code is much cheaper than the cost in not being able to deploy a fix in a reasonable amount of time, so any decent MBA graduate will make sure that there is always a backup person available for his purpose.