Last month's race between a group of security researchers who promised to disclose, every day, a newfound vulnerability in the Apple OS X platform, and an opposing group, led by a former Apple employee, to independently plug those security flaws, has sparked new debate around the validity of third-party security patches.
This isn't the first time, and certainly won't be the last, that third-party patches are made available. In fact, in response to a growing number of zero-day vulnerabilities last year, a number of third-party patches were published, including the Microsoft Windows Meta File (WMF) and Internet Explorer CreateTextRange vulnerabilities.
Third-party patches are likely to continue to gain steam as the number of zero-day vulnerabilities continues to increase. Security researchers, eager to devise a solution to a present threat, will continue to rapidly develop and deploy patches on their own. While it shows impatience with the amount of time it takes software vendors to develop patches, it also sheds light on an unfortunate situation: responsible disclosure currently isn't working.
This all began years ago, when it was common for software companies to ignore the security warnings from independent researchers about the security holes they uncovered in commercial software. The researchers, frustrated that the vulnerability went unfixed, used full public disclosure as a way to force vendors to take action. But, in many ways, this increased the risks against systems, as there always is an inherent security risk when too much information about a vulnerability is made public before the patch is issued.
That's why security researchers and software vendors developed the practice of responsible disclosure, by which the announcement of the vendor patch and the vulnerability occurred together. With this arrangement, everyone should win: researchers get their discovery credit; vendors have time to create a patch to protect their software; and software users aren't left vulnerable for extended periods of time while a vendor crafts a patch.
Unfortunately, the system has largely broken down. Criminal hackers, increasingly profit-motivated, are not interested in vulnerability discovery credits. Today, when vulnerabilities are discovered, they're often instantly put to use to infiltrate or infect systems with spyware, adware, or other forms of malware used for fraud and identity theft. That's why many newfound vulnerabilities today become known to the world through zero-day exploits and attacks. In fact, the most recent SANS Top 20 Internet Security Attack Targets report found that zero-days are on rise, and pose one of the biggest challenges going forward.
And attackers are doing everything they can to get the most mileage out of their zero-day vulnerabilities and exploits. We've noticed that many zero-day attacks begin just before, or right after, a software vendor's patch release day. In this way, they can maximize the amount of time their attacks go unpatched - it's highly unlikely the flaw will be patched before the next scheduled patch day.
So, independent parties, in an effort to keep systems as secure as possible, develop and make available fixes of their own. But is it a good idea for you to deploy these patches? Or should you wait for the vendor's patch?
Unfortunately, there's no clear answer. Do you know and trust the group issuing the patch? Little could be worse than issuing patches throughout your organization that end in crashed systems or having the patch itself turn out to be malware. Even if the third party patch comes from a reputable source, there's no way to tell if it's been properly tested and has gone through an adequate quality and assurance process. And even if it did, it's unlikely those assessments could be anywhere near as thorough as those performed by the original software vendor.
When zero-day vulnerabilities surface, your first - and best - move would be to assess your risk by running an assessment scan: does the flaw affect only internal systems, or external, too? How prevalent is it in your enterprise? And do your current intrusion-prevention systems and firewall rule sets mitigate the risk? If you find that your risk is real, it may make sense to deploy a third-party patch—but not without conducting a thorough quality assessment. Unfortunately, most companies don't have the resources to perform such an assessment. If you don't, you want to reach out to your software vendor, other security researchers, and your peers, to see if there is a viable work-around to put into place until the actual patch is published.
The zero-day problem isn't going to abate. And while you don't want to reject third-party patches in your efforts to protect your systems, you definitely want to proceed with caution. Unfortunately, this is a judgment call that security managers are going to be forced to make more often.