As February comes to a close we have already seen critical patches from Adobe and Microsoft. Even more concerning, Microsoft has not yet patched a recently disclosed Internet Explorer zero-day. For better or worse, Google’s “Project Zero” is putting the pressure on vendors like Microsoft to patch reported vulnerabilities in 90 days before public disclosure, which has been a source of public friction between the companies. With this forced public disclosure, there is now a risk of zero-day attacks stretching into weeks or months.
It is easy to feel sympathy for vendors like Adobe and Microsoft, who serve as a public face for the challenges of patching zero-day vulnerabilities. These organizations work ceaselessly and thanklessly to fix, test and deploy patches for vulnerable applications on an increasingly shortened timeframe. Still it seems that as soon as one vulnerability is patched, another one is reported like a Sisyphean game of Whack-a-Mole.
Of course, it does not feel like a game for information security teams. The stakes are quite real, but present a complicated dilemma. Even the most Draconian IT teams could not suggest prohibiting the use of these vulnerable applications that are the cornerstone of our modern productivity, yet even the most obtuse information security professional realizes the risk they present.
When critical security vulnerabilities exist in nearly every common application, from document readers to Web browsers, then it should come as no surprise that the frequency of cyber attacks seems to be increasing.
Beyond unpatched vulnerabilities, security patches present their own set of problems. It is dangerous to patch without testing because deploying a patch that breaks your systems could do more damage than if you are attacked. Security patches have never existed in a vacuum.
Where does this leave organizations? There is a risk if you don’t have the patch, but there is also a risk that you deploy a patch that you didn’t test. Google’s “Project Zero” is pushing vendors to create patches, but could this pressure create more risk? How can we guarantee Microsoft can fix a bug in 90 days without introducing a new bug or breaking the software?
These conflicting challenges represent a real opportunity for Bromium to take the pressure off of IT teams and software vendors. By leveraging micro-virtualization to isolate vulnerable software, organizations can remain protected while they take the time to test critical patches before they deploy.