The month is over, patching is past and we are not saved.
June 2009 may have been one of the busiest months of the year for information security officers with patch and vulnerability management oversight.
According to the US National Vulnerability Database there were 451 vulnerabilities disclosed during the past month, 46% (209) classify as High risk using the Common Vulnerability Scoring System (CVSS). You should be able to identify and fix them in your operational environment within one month if you needed your organization to be in compliance with the Payment Card Industry Data Security Standard (PCI DSS).
However, it may be misleading to use a count of disclosed vulnerabilities to assess the time and effort needed to maintain any given security posture (if you cared to know the number of overall and high-risk vulnerabilities disclosed in each of the first 4 months of the year was actually higher than the corresponding count for June).
For quite some time the NVD has calculated and published daily a Workload Index that also considers the value of a metric used to estimate impact of each of the vulnerabilities disclosed within the previous 30 days to assess the workload on any given day on the IT security operations staff tasked with vulnerability management duties. The Workload Index on July 1st was 8.46, one point higher than its value on June 1st but consistently lower than that of the first day of each of the previous 4 months.
A colleague, Eric Schultze CTO at Shavlik Technologies, argues that vulnerability counts aren’t relevant to anyone other than Vulnerability Assessment companies and journalists and that one should only care about the number of patches to deploy. That seems to be a reasonable view for Patch Management vendors or for security practitioners with the belief that the only way to fix a security issue is to apply an official patch from the corresponding vendor.
Unfortunately, reality is usually more complicated than the simplistic models either of us could outline in a blog post so rather than arguing about what is The Right Way to assess risk due to security bugs and to estimate time and effort to prevent, mitigate or transfer it I will describe the events of June and present some potentially interesting observations.
On Tuesday 9th Microsoft issued 10 security bulletins listing fixes for at least 31 vulnerabilities in the vendor’s products. The list of products that required fixing included all supported desktop and server operating systems, the vendor’s flagship application software suite (Office) and the world’s most prevalent web browser (Internet Explorer) and the world’s second most-used web server software (IIS).
Adobe announced that from now on it will release security updates following a fixed date schedule in synch with Microsoft’s second-Tuesday-of-the-month cycle and promptly joined the patch fest by issuing fixes to 13 vulnerabilities in Adobe Reader. Later on June 23rd another patch was released to fix a bug in Adobe’s Shockwave Player, a multimedia package for which the vendor boosts an installed base of 450 million desktops.
Not to be undone, Apple released patches for a total of 63 vulnerabilities affecting QuickTime, iTunes, the operating system running on iPhone and iPod devices and the Safari web browser. In addition the vendor finally managed to release a critical Java update for the Mac’s OS X operating system carrying fixes for over 32 vulnerabilities that Sun had already shipped for other platforms several months ago.
Meanwhile Mozilla released a new version of the Firefox web browser that fixed 11 bugs and Google joined the patching party with 2 updates for Google Chrome closing 3 holes. Other security fixes issue during June targeted server-oriented operating systems such as Sun Solaris, IBM AIX, FreeBSD and the Linux kernel.
In sum, during June patches were issued to fix high risk bugs in virtually every server or desktop operating system, application software representing 99% of the world’s web browser market share, around 25% of the world’s public web servers, the most widely used business application suite and the most widely used application runtimes.
If you’ve successfully navigated June’s patching inferno now would be the time to relax a bit, recharge energy and brace for the new set of patches that will be unleashed in the next two weeks except that... even if your systems are fully patched you are not saved yet: Patches for several known vulnerabilities that are being exploited in the wild were not issued during June, most notably the fix for a bug in Microsoft’s DirectShow functionality.
The observed patch release and patch non-release events of June led me to some questions:
What would be the effect on your security ops if every vendor converged on a fixed-date schedule for the release of patches? What if they picked the same fixed day, say the second Tuesday of the month? Would it be better or worse if every vendor released patches as soon as they had them ready to ship?
If patch and bug counts aren’t appropriate, how would you measure the security workload in an organization?
How do you assess risk and measure the extent of mitigation for security bug for which there isn’t an official fix?
If you headed a financially motivated attacker organization monitoring daily vulnerability disclosures and release of patches and needed to focus your limited resources on developing attack tools for specific bugs.
How would you pick them?
How and when would you use them?
