SAN FRANCISCO -- Mitja Kolsek, CEO of ACROS d.o.o., is not impressed with the state of security patch management....
At the RSA Conference, Kolsek said breaking into a network today follows the same four steps as it did 15 years ago: Find a public exploit; tailor that exploit to work with your remote access Trojan; mutate the exploit, so antivirus or antimalware software won't recognize it; then, phish the target until you're in.
According to Kolsek, the basic issue is vulnerabilities are not being patched, and vulnerabilities aren't being patched because software vendors, end users, administrators and security researchers "don't play well together."
Software vendors don't like patching, because they want to do something that brings in new revenue, Kolsek said. Security researchers have an inherent conflict with vendors and are considered part of the problem, because researchers uncover flaws. And Kolsek said end users and admins hate downtime, but are caught between the risk of breaking a system with vulnerability patching, or risking an exploit by not updating.
Even when organizations do update systems, Kolsek said it takes an average of 176 days to apply new patches after Microsoft has one of its monthly Patch Tuesday releases. Unfortunately, exploit developers have been able to reverse-engineer those patches and create an exploit in a much shorter time, Kolsek said. With Adobe Flash, the time from patch release to the addition of an exploit to an exploit kit, or EK, has been found to be as little as three days.
Kolsek said there are two ways to improve this situation, and, maybe, shrink the window between a viable exploit and enterprises applying a patch. First, Kolsek suggested a switch to tiny micropatches, which would need just a few lines of instructions to fix a vulnerability, rather than the hundreds of megabytes of code included in the average Microsoft Patch Tuesday release.
"It can be imperceptible to apply and remove," Kolsek said. "It would require no restarts, so systems could be hot-patched without interruption, and unpatching could be performed easily as well."
Because micropatches would be so small, Kolsek said it would be far easier to create a crowdsourced network of third-party patching from developers around the world. This could reduce the time it takes to get and apply a patch: At worst, it would be a stopgap until the official patch could be applied; at best, it would free up first-party developers to work on revenue-generating products, while improving overall security.
Kolsek said the small size of a micropatch would make it nearly impossible to hide malicious code and make peer review of vulnerability patches much easier.
"It's very difficult to hide malware in a 30-byte patch, and so peer review is very easy," Kolsek said. "If a patch isn't small, it's suspicious. Micropatches can also be signed by trusted parties, and organizations can choose who to trust."
The beginning stages of a "crowdpatching" system like this is already in place, Kolsek said. Vendors already have private disclosure of vulnerabilities, offer bug bounties and even offer rewards for submitted patches.
"No one organization can provide all the micropatches we need," Kolsek said. "For every micropatch, we need a proof of concept; we need people hunting for zero-days in malware, EKs and public forums; we need to analyze open source software to create micropatches; and we need to reverse-engineer official updates to create bridge-the-gap micropatches."
Kolsek said he imagines a process where security researchers around the world who know how to create exploits and analyze vulnerabilities are given the ability to create micropatches and distribute them safely to organizations.
"We need to allow those applying patches to feel safe," Kolsek said. "Only the crowd can do it."
Reliability needs to be able to compete with the official patches, Kolsek said, which wouldn't be an easy task. Enterprises would need the assurance that micropatches would not risk breaking systems, so community feedback could initially validate a patch until an official vendor could validate the patch.
Kolsek admitted that first-party vendors might push back at first, but may eventually see that it would lead to bad press if they didn't let users keep themselves safe. Or, Kolsek said vendors could begin micropatching themselves.
The value for organizations would be easy to express as well, Kolsek said, because a simple list of critical flaws could easily enumerate the gap in vulnerability patching. Additionally, enterprises would be able to avoid out-of-band updates, remove troublesome patches without disturbance, and the entire process should be faster and cheaper for all.
Learn more about the software vulnerability disclosure debate.