The date is May 12th 2009 and you are a mild mannered IT manager anticipating a single bulletin from Microsoft and a possible update from Adobe. The team has their assignments; their computers are locked and loaded. The team is ready to execute on the planned patch release mechanisms.

At 10AM Pacific Microsoft releases their patch on time. The single bulletin is the anticipated bug fix for the PowerPoint vulnerability. Some members of the team are a bit agitated by the high CVE count and the lack of updates for the OSX Office platform. You are able to quickly refocus the team and move forward. Hours later, rumors hit that not only did Adobe publish their fix, but also Apple released a new revision of their operating system.

In fact both of these things happen and OSX 10.5.7 includes fixes for 67 vulnerabilities. Together the Apple, Adobe and Microsoft patches account for 83 CVE fixes. Now the team is seriously disheartened. Your job is to draw the group together, review the unexpected workload and set priorities. Did I mention that because of the economy, your team is now smaller, but doing just as much, if not more work.

Microsoft produces their risk categorization. Adobe employs yet another risk methodology and Apple also defines bugs in their own way. The lack of any common metric across the three vendors in combination with the additional calculus needed to accommodate your internal risk equations equals uncertain resource drain.

On any normal Microsoft patch Tuesday, most enterprises IT teams have their risk calculators in hand and resources at the ready. Some teams split up the duties between client and server vulnerabilities. Others take the highest risk first no matter where the bug lies. Either way, the security team adapts in order to deal with the Microsoft specific criticality ratings and their exploitability index.

The same thing ensues on an Oracle CPU day. And even when smaller vendors like Adobe release bug fixes, most enterprises know how to massage the vendor specific risk data into their own risk profile equations. This data manipulation is a completely avoidable step.

CVSS (Common Vulnerability Scoring System) version 2 was finalized two years ago. Even before that, CVSS v1 was in play for a number of years. While everyone recognizes that there are some shortcomings with the standard, it is nonetheless a common means to reliably communicate information about risk. It enables vendors to consistently distribute quantifiable information to enterprises who then use this data in their own decision-making engines.

So with this industry wide tool readily available, why is it that today enterprise IT must differentiate and discriminate the various meanings of the word 'critical' from multiple vendors?

On a day like May 12th 2009, enterprise IT had a whole range of decision making to perform. Which bugs were most important for my enterprise? Where do the greatest risks lie and which patches should be tested and delivered first? Do you tackle the low hanging fruit or the higher risk and possibly more cumbersome patches first?

These decisions are made countless times every year as vendors release patches. Unfortunately for those in the trenches, too many valuable resources are consumed with just trying to normalize the vendor datasets. If all vendors across the board delivered data with standard metrics, then at least enterprise IT would be in a better position to handle the inevitable changes smoothly and with minimal disruption.