Patch Management - Speed Is of the Essence

Symantec’s Hon Lau recently published a blog post titled “Patch Management – Speed is of the Essence.” You may know that we also recently published a blog post titled “Patching Conundrum”, in which we discussed how our studies had convinced us that patching too fast can be a “bad thing™.”

Hon Lau said, “It is this gap between the availability of patches and their application that is creating a window of opportunity for would-be attackers.”

Well, really, it isn’t. The “window of opportunity” begins when the vulnerable version of whatever is actually installed and/or implemented, and lasts until a non-vulnerable version is installed, or until the product stops being used. Nothing terribly significant occurs once a patch is released, unless you fear “Automatic Patch-Based Exploit Generation” (APEG). Hon Lau seems to.

APEG, while being stated as “practical” by its authors, is still unlikely to be used by criminals. Our research strongly suggests that criminals don’t re-invent the wheel. What value is it to them to have their own exploits when they can simply use widely available exploits already in existence? Often, these exploits require nothing more than presenting them to the victim. This is not to suggest that study into APEG will stop. Unfortunately, the idea of finding a way to identify vulnerable systems is a business in and of itself, and APEG may hold the key for vulnerability scanners to more quickly get out new signatures.

Further, our 2008 Data Breach Investigations Study clearly shows that the vast majority of criminals simply aren’t using sophisticated attacks. They’re opting for simpler techniques and easy targets (or low-hanging fruit).

Hon discusses the many vulnerabilities published every day, both with and without a patch. As we have said on numerous occasions, vulnerability is not the key to determining your risk. That you are vulnerable does not necessarily equate to you being exploited.

Hon states, “time and time again in the past…newly patched vulnerabilities have been exploited to great effect.” It would appear to us that his definition of “newly patched vulnerabilities” is different than ours. He also says, “it is well known in the industry that many computer users do not apply patches immediately upon their release.” We therefore must assume that the “newly patched vulnerabilities” are threats which could have been avoided with immediate patching.

As shown by our study, this simply is not the case in our Investigative Response caseload. None of the known vulnerabilities (for which there was a patch) were exploited less than one month after the patch was available. In fact, the study also showed that 90 percent of known vulnerabilities were exploited six months or more after the release of the patch. Certainly patching within six months would not be considered immediate.

In fact, the two references provided by Hon regarding newly patched vulnerabilities being exploited do not support his assertion this is happening. The first case he references is a Word for Mac vulnerability. They received a sample the day after the patch came available from Microsoft, but Microsoft created the patch due to the active exploitation of the vulnerability. In other words, this was a “0-day.” Patching faster means nothing to the people exploited before the patch was released. Patching faster after the release of the patch would be critical in order to avoid becoming another victim. What we don’t know is how many people fell victim to this exploit after Microsoft released the patch, and how many of those are people who do not regularly (e.g. twice a year) patch.

Hon’s second reference was a vulnerability that had been patched for 300 days (almost a year)! Clearly patching faster than 10 months after the release of a patch is a good idea, but when you put these together with the idea that you need to patch immediately after release…well, you end up casting fear, uncertainty, and doubt. Heck, even the APEG authors suggested that Microsoft’s Windows Update method of rolling out patches spread over 24 (or more) hours wasn’t good enough, as criminals might get their copy of the patch before you and automatically generate an exploit before you’ve got the patch applied.

If you take Hon’s observations, and the citations referenced, you could easily come to believe it is impossible to patch fast enough.

Hon goes on to suggest that businesses with highly complex and critical IT infrastructures may be increasing their risk by applying patches. The suggestion is that the patch application could have an adverse effect, while the risk from exploitation is unknown. This certainly does emphasize the need for the services of a group such as ours, who quantify risk, provide analysis that allows you to know your risk and prioritize accordingly. But it also overlooks the very necessary “regular scheduled maintenance window” we speak to in our Microsoft Patch Briefings every month. It also seems to ignore system classification, such as “critical security infrastructure” systems, which should be maintained on their own maintenance schedule. If you’re big enough to have a “highly complex and critical IT infrastructure,” you should also be doing some reasonable risk analysis. We think you likely are.

Hon says, “In the virtual world, it is quite easy for an attacker to reach out and probe thousands of targets for weaknesses and remain untraceable.”

Well, “untraceable” may be an overstatement. We don’t think you can perform such activity and be “untraceable.”

Finally, Hon says, “They should obtain, test, and apply patches as quickly as possible.” However, with this approach, you’ll be mired in testing constantly. What you need to do is understand the risk you face. What do you own that criminals might want? Who can get to it? What would they have to do to get it? What are you doing to prevent that? Well protected systems may do well without patches at all, or maybe by utilizing just a few, of those that are released for it each year.

Tags: , ,

Comments

  1. Vulnerability Life Cycle…

    Schneier once proposed a vulnerability life cycle in a Crypto-Gram newsletter. However, during the time of writing my thesis, there were several important pieces of research no-one had put together to come up with a ‘more correct’ vulnerability lif…

    Posted by: Dominic White's .tHE pRODUCT on July 19th, 2008 at 12:29 pm

Leave a Comment

You must be logged in to post a comment.