Google Project Zero is to give software vendors an additional 30-days before it discloses security issues. That 30-days is to give customers more time to patch their systems. Previously, a vendor would have to create and distribute a patch before 90-days if it wanted to give customers time to apply that patch. In reality, the blog from the Project Zero team says that it didn’t speed up development time. Instead, it put customers under pressure, leaving many unpatched.
In a blog from Tim Willis, Project Zero, he writes: “The goal of our 2021 policy update is to make the patch adoption timeline an explicit part of our vulnerability disclosure policy. Vendors will now have 90 days for patch development, and an additional 30 days for patch adoption.
“This 90+30 policy gives vendors more time than our current policy, as jumping straight to a 60+30 policy (or similar) would likely be too abrupt and disruptive. Our preference is to choose a starting point that can be consistently met by most vendors, and then gradually lower both patch development and patch adoption timelines.”
Project Zero focusing on customers
The change to 90+30 is purely about customers. Many SMEs already use automatic patching so that patches are applied as soon as they are issued. However, over the last year alone, too many high-profile breaches from SolarWinds to Microsoft show large enterprises lag behind.
Last month the FBI sought a secret warrant to remove the Hafnium malware from infected exchange servers. It didn’t patch those servers, and it has no power to force companies to do so. It resulted in malware being removed, but the servers are still open to reinfection. The NSA also listed five vulnerabilities being actively exploited by Russia’s SVR last week. Four of those were identified and patched in 2019. It shows that organisations are still willing to risk their business by ignoring patches.
While this latest announcement from Project Zero won’t have any impact on those patch laggards, it will benefit many other organisations.
What about the future?
Project Zero wants to lower the time it takes for vendors to develop and customers to apply patches even further. According to Willis: “For example, based on our current data tracking vulnerability patch times, it’s likely that we can move to a “84+28″ model for 2022 (having deadlines evenly divisible by 7 significantly reduces the chance our deadlines fall on a weekend). Beyond that, we will keep a close eye on the data and continue to encourage innovation and investment in bug triage, patch development, testing, and update infrastructure.”
The question is, how much lower can that time become? Willis writes: “We anticipate slowly reducing time-to-patch and speeding up patch adoption over the coming years until a steady state is reached.” What he does do is comment on what that steady state is. Much will depend upon the vendor and the complexity of the software. Will we ever see 30+30? That is highly unlikely, but 60+30 might be possible, especially as software becomes increasingly modular.
That raises another challenge. Will older, complex legacy software be able to stay on 90+30 while newer software drops to 60+30? At present, nobody is willing to consider having split times, but as Project Zero looks to lower the time to develop and apply patched, it will need to consider it.
Enterprise Times: What does this mean?
Anything that can speed up the development of patches is to be welcomed. Project Zero has already done much to improve the behaviour of some software vendors. The rules for 2021 recognise that the previous approach was right but hadn’t factored in customer behaviour. Now the programme looks much more balanced with opportunities to fix on both sides.
However, there is still a lot more to be done. While Project Zero is helping vendors be more responsive, it is not having the same impact on customers. What is now needed is a way to require companies to patch faster to reduce the attack window.