Americas

  • United States

Asia

Oceania

by Senior Editor

RSA 2010: Can Adobe Stop the Hate?

Feature
Feb 28, 20106 mins
Adobe SystemsApplication SecurityRSA Conference

Security pros are unhappy with Adobe Systems over recent flaws and attacks. Adobe Security Chief Brad Arkin on what the company is doing about it.

SAN FRANCISCO — The way IT security pros see it, Adobe is the monster they can’t live with anymore. But they really can’t live without it, either.

Users rely on Adobe software to create, edit and view a variety of rich media content. But for many security practitioners, frequent attacks against a range of security holes has become too much to take. In early February — mere weeks after the company patched one critical flaw — Adobe was forced to rush out another patch for its Reader and Acrobat software. The company also had to rush out a critical fix for Flash Player in February. At the start of the year, some security vendors openly predicted that Adobe would be the top target of attackers in 2010.

The company’s security team has not taken the heat lying down. It has tried to use the blogosphere to stay in touch with customers regarding new flaws, attacks and fixes and has taken steps to improve the patch-installation process.

But for now at least, that’s of little comfort to security pros like Christophe Veltsos, president of Prudent Security and keeper of the DrInfoSec.com site.

“I used to require that my students (at Minn. State U. Mankato) turn in their assignments in PDF format instead of Microsoft Word,” he said, adding that in light of recent security problems, “I’ve switched back to Microsoft Word as it appears to be a safer alternative than PDF.”

Not helping Adobe’s image is that Steve Jobs has been slamming Adobe Flash, explaining to the press that it has no place in such Apple devices as the newly-unveiled iPad. Specifically, he called it a CPU hog and a magnet for security holes.

At this week’s RSA security conference, Brad Arkin, director of product security and privacy at Adobe Systems, will spend a lot of time with Adobe customers, explaining what the company is doing to improve security. He sat down with CSOonline.com a couple days before the start of RSA to offer a preview of what he’ll discuss.

CSO: Adobe has had to confront a lot of security holes of late, and a lot of security practitioners have been expressing concern. What will you be doing at RSA to calm their fears?

Brad Arkin: We don’t have any product announcements to make at RSA, but we’ll be having a lot of meetings with customers and people from the media. Adobe is a member of the Software Assurance Forum for Excellence in Code (SAFECode) and I’m on the board, and we’ll be having a meeting Monday. I’ll also be speaking to groups and individuals at the various networking parties during the week. I’ll be giving a lot of short talks to promote the security message we’ve been promoting for the past year. The biggest thing we’re trying to achieve is transparency.

It seems like Adobe is taking the same level of heat Microsoft used to take in the days of Internet Explorer 6 and Windows 2000 and XP. How do you respond when people criticize Adobe for the flaws and attacks?

Arkin: The point we try to make is that the threat landscape is evolving quite rapidly and we’re doing everything possible to react to that and stay ahead of what’s happening. We understand that the reason Adobe is such a big target for the bad guys is that it’s so ubiquitous. Something like Reader or Flash player is installed on just about every single machine out there that’s connected to the Internet. That means the bad guys don’t have to work so hard because if they can find a problem to exploit it can be directed at every machine. As a result, every bad guy on Earth is looking for something to exploit in our software. One thing we can do to make our products less attractive to the bad guys is to regularly update and make sure as many people as possible are using the most updated versions — and make it as easy as possible for them to do so.

How are you making it so?

Arkin: For the consumer, we have a new updater for Reader and Acrobat that’s in pilot-beta phase. We’ve gotten a lot of positive feedback from testers so far. It’ll offer a fully automatic, silent install experience for updates. Today we have what we call semi-automatic mode, where it’ll check for updates and download it, then put up a box that tells the user there’s an update and asks if they want to install it now. The reason people will sometimes say no is because at that moment they’re in the middle of doing something and think the update will require them to reboot their machine. It doesn’t require a reboot but they think it will. This new automatic mode will check for and download updates and then install it without asking the user any questions. Then a box will pop up informing the user that an update is available and will take effect next time they boot up their machine.

Another tool we have for Adobe Acrobat and Reader is something called the JavaScript Blacklist Framework, which we pushed out in October. It provides customers with granular control over the execution of specific JavaScript API calls, providing protection against attacks that go after those specific JavaScript API calls. This has been extremely helpful in helping customers mitigate attacks, even if a patch is not yet available.

You’re going to be on a panel at RSA that’ll tackle the pros and cons of vulnerability disclosure. What’s your personal position on this?

Arkin: There are different levels of disclosure. Full disclosure is when someone publically published a vulnerability along with all the details needed to carry out the attack. Partial disclosure is when someone says they found a new kind of attack but they don’t go into all the details. Responsible disclosure is when a researcher finds a problem, shares all the details with the vendor and no one else. In 2009 there were three bugs that were fully disclosed. It’s a bummer because the bad guys can use the detail to craft malicious exploits and doesn’t give us time to get mitigation down to the users.

Our preference is always that researchers will share their findings with us and no one else. That way we can get a fix out before the bad guys can exploit it.