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."

Comments

Sounds like a huge risk

[anthony_greer]

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

Re:Sounds like a huge risk

[slashmydots]

I'm a software programmer so I can honestly say if a company takes more than 7 days to issue a fix, they aren't good. Let's say there's a team of 20 programmers working on a huge piece of software like an ASP system on a website. If the 1-2 people responsible for the module hear about the problem like 4 days after it was reported, the boss seriously screwed up. That's a lack of communication in their company. A 30 minute delay for "there's cake in the breakroom" and 7+ day delay on "someone's hacking our website" means someone epically screwed up the importance of that e-mail getting relayed to the correct people.

If the programmers can't read their own damn code that they wrote and figure out why the vulnerability happened, they should be fired. They obviously don't know their own code and didn't use comments or worse yet, they don't know what the command they're doing ACTUALLY do and that was the cause of the problem.

Then if it takes more than 7 days to "publish" or "push" a new version of their software live, then the whole project was designed like it's 15 years ago. These days, you need urgent patches faster than that. Let the programmers who wrote the code do the testing so there's zero delay and then don't require some know-nothing 60-year old head of the department review all code before it goes live.

Re:Sounds like a huge risk

[HockeyPuck]

so it's probably better to get out a fix that works for 60% of installs right away and then work on the patch that will work for 100% of installs.

So you're willing to risk breaking 40% of your customer's installs? Are you willing to skip regression testing to make sure your fix breaks nothing else?

Re:And when they get bitten in the ass?

[fuzzyfuzzyfungus]

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.

App approval

[EmperorOfCanada]

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.