Browser security

In episode 8 of the Eurotrash Security Podcast the subject of browser security was discussed. The guest, Jayson E. Street, asserts early on in the interview that the number of vulnerabilities present in a browser is not an accurate metric of security. Instead, he cites the "mean time to patch" metric that is often referred to when gauging vulnerability management. Mean time to patch is the time it takes for a vendor to release a patch or fix to address a security vulnerability. The idea is that even if there are lots of vulnerabilities disclosed in a piece of software, if the vendor releases fixes rapidly then that mitigates any threat.

While this is a fine sentiment, it is somewhat short-sighted and misguided. Mean time to patch is an important metric, but it is only one of the data points that should be examined. Another critical measure that comes quickly to mind is ease of patching. Even with rapid patches released, if patch download and installation is not automated, most users will not take advantage of the patch, potentially allowing a vulnerability to persist in their configuration for a long time. This point was even hinted at when the podcasters discussed the fact that people running pirated versions of Windows would not get a patch.

Another factor that is important is enterprise patch management. In an organization it is important that IT staff be able to roll out patches and updates in a centralized fashion, because let's face it, having people run around and touch 100's of machines just isn't an effective use of time. This fact is why Microsoft has such a stranglehold in the enterprise environment. If a central IT staff can't push out a patch to the entire organization, or sectors of the organization, at once then the software isn't feasible for the environment.

The entire discussion reminded me of the recently released, and excellent, patch management framework released by Securosis, called Project Quant. The project attempts to identify a streamlined vocabulary and framework for approaching patching by breaking down the process into several steps. The report is technology agnostic so it is applicable to any environment. The report identifies seven steps in patching from monitoring sources to identify patch release to post-patching documentation. It is excellent work and provides a much needed model to the industry.

As client side attacks increase patch management is becoming increasingly critical to ensuring endpoint security. Vulnerabilities are inevitable in software and while patch release and a low mean time to patch is laudable, it is only one piece of the software security lifecycle. Without examining the challenges in implementing patches the metric becomes much less useful.