Google's elite vulnerability-hunting team, known as Project Zero, scored some major successes during 2019 with disclosures regarding Signal, iMessage and LastPass to name but a handful. The skills of the team at Project Zero and the effectiveness of their decisions have been appreciated, but there has been plenty of debate surrounding the arbitrary 90-day disclosure deadline that it imposes upon vendors.
Whether the vulnerability has been patched or not, regardless of the criticality of that vulnerability and regardless of the complexity in fixing it, Project Zero goes public 90 days after the private disclosure has been made. This is meant to be a stick with which to prod vendors into taking security more seriously, and get fixes out quickly.
Project Zero has now confirmed a change to its disclosure policy. Vendors will be able to request an extension if the vulnerability is to be fixed after the 90 days but before 104 days. If an exploit is being actively exploited, however, all bets are off as the current seven-day deadline remains in place.
"Too many times, we've seen vendors patch reported vulnerabilities by ‘papering over the cracks’ and not considering variants or addressing the root cause of a vulnerability. One concern here is that our policy goal of ‘faster patch development’ may exacerbate this problem, making it far too easy for attackers to revive their exploits and carry on attacking users with little fuss," Project Zero's Tim Willis wrote.
"If a grace period is requested, and a bug is fixed between 90 and 104 days after it was reported, bug details will be released on the day it is fixed. Grace periods will not be granted for vulnerabilities that are expected to take longer than 104 days to fix. Note that the seven day deadline for vulnerabilities that are being actively exploited "in the wild" will remain unchanged," said the condition listed in the blog post.
The idea behind the disclosure policy change is to give vendors longer to fix their code and, importantly, test those fixes before the technical details (including proof of concept code) are revealed that could enable a threat actor to take advantage. The full 90-day period should enable vendors sufficient time for real-world testing and to fix any problem patches.
Nicholas Miles, manager of the zero-day research team at Tenable, said the intention of the change may well be to give vendors who patch early the ability to notify customers and let them patch before vulnerability details are made public. However, "it still punishes those who do not patch in time by releasing details at the end of the 90 days." He argues that through coordinated disclosure, the vendor and researcher can work to disclose the vulnerability details and fix simultaneously.
"The issue with Google’s new policy is that regardless of whether a patch or solution is available or whether the affected company has responded to Google’s initial outreach, it risks creating even more vulnerabilities within a compromised system," Dirk Schrader, cyber-resilience architect at Greenbone Networks, told SC Media UK. This is because, Schrader says, vendors will rush to fix things within the 90-day time-frame for fear of being called out.
Alex Rice, chief technology officer at HackerOne noted that "the trade-offs involved are complicated with far-reaching implications in the real world," and it's "promising to see leaders in this space such as Project Zero continuing to evoke a mindset of continuous improvement".
Ceri Charlton, associate director at Bridewell Consulting dismissed the idea that the changes will lead to vulnerabilities being open for longer. "What we might see, as an indirect consequence, is a shift to more secrecy in patch release notes, as to the specifics of the security vulnerabilities which are addressed by a given patch," Charlton told SC Media UK.
Cybereason chief information security officer Israel Barak is more direct in his support. "The 90 days give the end-users the right amount of time to fix the vulnerability right after the vulnerability is announced and to reduce the window that hackers have to exploit the vulnerability by introducing compensating controls," he told SC Media UK.
Ed Williams, EMEA director of SpiderLabs at Trustwave, said, "Project Zero are again doing the right thing and giving vendors time to ‘properly’ mitigate the issue." This inevitably will lead to better code and a safer environment, he told SC Media UK.
Jake Moore, cybersecurity specialist at ESET, also supported the decision. "It's an excellent move by Project Zero, because patching cyber-security vulnerabilities does not mean that everyone involved is instantaneously secure. Patches work with a time lag, which here has been taken into consideration to best protect both the company and their users," he told SC Media UK.
Leigh-Anne Galloway, cyber-security resilience Lead at Positive Technologies told SC Media UK that a responsible disclosure policy must mean a researcher who finds a vulnerability will work together with the vendor to fix it. "If the vendor recognises there is a bug, it is entitled to ask for a postponement of publication of an advisory until the issue is solved."
Jonathan Knudsen, senior security strategist at Synopsys, applauded the move, but noted that "only time will tell if the policy changes have the desired effects".
Martin Lee, technical lead and outreach manager at Cisco Talos, agrees that "responsible disclosure is about appropriately balancing different priorities," and "different communities have different requirements." What he does insist upon though, is that "the priority has to be disclosing in the best interests of the community as a whole, and choosing a disclosure policy which is fair, balanced and defendable against scrutiny."
David Kennefick, product architect at edgescan, said Google is looking to standardise disclosures. "There is a sense that they want vendors who own the products they are finding vulnerabilities in to be more aggressive in their patch development," he told SC Media UK.
Oliver Pinson-Roxburgh, co-founder of Bulletproof, observed that the Project Zero change essentially "threatens businesses". "But, it is a necessary change and will highlight organisations’ poor hardening mean-time, revealing how quickly they respond and whether they are aware of the latest threats in time to fix security weaknesses," he told SC Media UK.
Most organisations, he argues, are not fast enough at testing for the latest vulnerabilities, and are often ham-stringed as they can’t just push an untested patch, which may take down their critical systems. "Businesses need to get better at understanding the impact of a threat in order to prioritise the issues to be fixed first: the age old problem of people, process and technologies," he concludes.
That is something that everyone can agree upon.