nCircle Sync Blog: May 2009 Archives

Adobe had a turbulent start this year and in response to cries from it's disgruntled users, Adobe security has announced several strategic moves. This blog post from Adobe describes the three much-needed things Adobe will be doing to improve security for their popular Reader and Acrobat products.

First, Adobe's existing secure product development standards will now also be used against their existing/legacy code base. Second, Adobe now promises quicker and more in-depth security incident response mechanisms. Finally, Adobe will be moving to a regular patch release cycle.

The three initiatives essentially mirror what we have come to know and appreciate about Microsoft's security processes. About a decade ago, hit by bad press and poor industry reputation, Microsoft embarked on a similar but grander vision. The result of that effort is that today Microsoft is the leader when it comes to managing the enterprise security development lifecycle.

These initiatives are a great start for Adobe to begin rehabilitating their image. These initiatives go a long way, but they are still missing a few important components.

First, Adobe needs to learn how to reign in the bug finders. Both critical security incidents with Adobe so far in 2009 have involved situations where proof-of-concept code was made public before Adobe could repair the bug. Letting bug exploits out into the wild set Adobe back on their heels and left IT security groups in a reactionary mode trying to cover their security assets without much help from Adobe

Second, enterprise IT shops could benefit greatly from centralized tools that allow for product policy changes. If Adobe published means and methods to disable product functionality using active directory group policies, then IT would be in a better position to respond and implement policy-setting changes.

Finally, JavaScript bugs riddled Adobe products in 2008 and in 2009. It would behoove them to consider disabling JavaScript by default.

The long string of critical bugs in Adobe products has disappointed me, among many others. The bugs, coupled with poor company communications and difficult to deploy mitigation steps have made the last six months ever more trying in our security team. Going forward there will be 2 key metrics of Adobe's successful implementation of their new security program. First will the obvious - fewer security holes. The second indicator will be when Adobe has successfully convinced the bug finders to disclose holes to them instead of publishing them online.

The bottom line is that the changes announced today by Adobe are welcome and we all hope that Adobe sees immediate improvement across their install base.

Week 5 of the FBI Citizens' Academy was mostly dedicated to counterterrorism.

First we received an overview of the counterterrorism program from the local assistant special agent in charge for the counterterrorism group. The number 1 priority of the FBI is to protect the United States from a terrorist attack. This includes protecting US interests and citizens both locally and located abroad. We learned about the joint terrorism task force (JTTF) that makes up federal, state and local law enforcement personnel. The JTTF acts as an integrated investigative force to combat domestic and internal terrorism. Here in the Bay Area we also have a northern California regional intelligence center, also referred to as a fusion center. After the overview, speakers led the class thru 2 separate case studies. The first of domestic terrorism related to individuals harming local university professors that worked in areas where animal tested is involved. The second case study demonstrated a case of international terrorism. In this second case, a local bay area resident was found supporting terrorists on foreign soil by monetary means.

The evening ended with a quick discussion of InfraGard. InfraGard is a partnership between the FBI and the private sector for information sharing and analysis. The partnership works towards preventing hostile acts against the United States.

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.

Why couldn't Microsoft have kept things easy this month? Last week Microsoft's advanced notification information spelled out a single bulletin for PowerPoint. Given the single outstanding publicly known vulnerability in Microsoft's products, May patch Tuesday certainly looked like it would be an easy one. Alas, we did receive a single bulletin today, but with it came 14 CVEs and a note of more to come.

Don't get caught up in the details

First thing to take away is that newer Microsoft Office products carry on signs of being more secure. Office 2007, with its new office file format, continues to present lower risk levels. Even in the face of zero day bugs like those of Excel in February and now PowerPoint, Office 2007 was noticeably less affected. Now with the PowerPoint 4 format being totally retired, managers have more ammo than ever to go obtain budget for upgrades.

The second important piece not to overlook is that more patches for today's bugs are due out soon. Microsoft recognized that these bugs also affect the Mac Office products, but don't have patches available yet. Releasing patches for only piece of their product line and leaving the Mac users out in the cold is unlike Microsoft. However, given that current exploit samples were less functional on the Mac and given the market share dichotomy between Office Mac and Windows, the split release cycle is understandable.

The third piece of today's puzzle is that after you look over the mass of CVEs patched; don't forget that one of them is the known zero day bug that was described in KB969136. This means that Micrsoft not only patched the known zero day bug as promised, but also went much further at delivering a more secure Office product lineup.