Five Important Security Resolutions for Adobe

By Andrew StormsThe year was 2001. Code Red, the Microsoft Web Server worm was running rampant and underscored every security professional’s perception that Microsoft products were both a necessary evil and a serious security liability.

Fast-forward to nine years later. Microsoft products still contain more than a few nasty bugs, but the company is more likely to be considered a valued partner than a security liability by the security community.

The year was 2001. Code Red, the Microsoft Web Server worm was running rampant and underscored every security professional’s perception that Microsoft products were both a necessary evil and a serious security liability.

Fast-forward to nine years later. Microsoft products still contain more than a few nasty bugs, but the company is more likely to be considered a valued partner than a security liability by the security community.


The similarities between Microsoft in 2001 and Adobe in 2009 are eerily similar.  If Adobe were to use Microsoft’s ten-year journey from security pariah to trusted partner as a guide, this is what their New Year’s resolutions for 2010 should look like:

First and foremost, Adobe needs to resolve to get out ahead of zero day exposures.

[SEE:  Despite Danger, Adobe Says JavaScript Support Important ]

The number of zero day events with Adobe products is their biggest security challenge and a huge perception problem for the company. In addition to causing chaos for Adobe customers, these events keep critical Adobe resources locked into time consuming zero day fire drills. These internal resources could definitely be better utilized in ways that would benefit both Adobe and their users.

Second, Adobe needs to resolve to build a real partnership with the security research community.

Adobe continues to be surprised by multiple public bug disclosures last year.  In contrast, nearly all Microsoft bugs were disclosed privately and remained private until a fix was released.  Motivating the security research community to work with Adobe will take cold, hard cash.  Adobe needs to start by offering bug bounties and they need to match the bounties offered by iDefense or TippingPoint. This move will dramatically improve any efforts already underway in this area because money really is the ultimate motivator.

[ SEE:  I Have Only One Security Prediction for 2010 ]

Third, Adobe needs to resolve to provide faster, more detailed and accurate threat intelligence, especially when they have disappointing security news for their users.

Adobe has developed a habit of alerting users to security issues in their products without adding new information. This is very likely a side effect of all the zero day fire drills last year. Microsoft can get away with phased intelligence releases because of the strong relationship they have built with the security community, but Adobe hasn¹t made the same investments.

Adobe did improve significantly over the past year by offering security blogs and providing users with a quick ‘heads up’ when security issues emerge but there is still a lot of room for improvement. Their blog posts need to be stuffed full of actionable mitigation advice within hours of disclosure.  And the security bulletins are still too general. They are a far cry from the detailed bulletins Microsoft provides.

Fourth, and perhaps the most difficult, Adobe needs to resolve to make a huge leap forward in building security advances and technology into their products.

[ SEE: How to mitigate Adobe PDF malware attacks ]

Unfortunately, even perfect execution of all the other resolutions won’t be enough to change Adobe’s momentum at this point. Reactive security responses alone won’t move Adobe ahead in the security war fast enough. To change the tide of negative perception Adobe needs to demonstrate security leadership and serious progress in hardening their products.  For example, Adobe Reader should be a sandbox product similar to Google Chrome or Microsoft’s Office 2010.  Adobe has made headway on an SDL in 2009.  Unfortunately an SDL is not a product strategy, it’s an operational guide.  The immediate future of application security is sandboxing.  Adobe should watch and learn from Google’s Chrome and Microsoft’s Office 2010 sandboxing mechanisms.

Finally, Adobe should resolve to give back to the security community.

Philanthropy never hurt anyone and it goes a long way toward building good will.  Microsoft’s SDL has gained enough maturity that they can share what they have learned with the community.  Adobe has quite a ways to go in this area, but they should at least be thinking seriously about giving back to the community.

Adobe’s security strategy and user’s perception of the Adobe products safety are both at a critical juncture.  Let’s hope that Adobe takes this opportunity to leap forward in both areas for 2010.

* Andrew Storms is nCircle’s Director of Security Operations. He is
responsible for the definition and enforcement of the company’s
security compliance programs as well as overseeing day-to-day
operations for the Information Technology department.

Suggested articles