RSA Conference:Application Security Means Getting Corporate Buy-in, Adobe Says

Adobe security chief Brad Arkin discusses how the company has changed its development process to bolster security and offers advice for organizations struggling to bake security into application development.

Few companies have as bright a media spotlight on their security successes and failures as Adobe Systems does.

During the past two years, that has translated into an increased emphasis on hardening the company's most popular applications by improving the development process and adding technologies such as Adobe Reader X's sandbox into the mix. According to Brad Arkin, Adobe's director of product security and privacy, the key to all this - and to baking security more thoroughly into the development process-is both developer and executive buy-in.

"The details of what you do with the product team are important, but if you can't convince the product team they should care about security, then they are not going to follow along with specifics," he told eWEEK. "So achieving that buy-in to me is one of the most critical steps."

For Adobe, which revamped its application-development process in 2009 amid an onslaught of zero-day bugs, this included a mix of education and a new emphasis on finding problems in legacy code whenever product updates were being prepared. To raise the bar on security, the company launched an internal training program in 2009 with four levels: white belt, green belt, brown belt and black belt. The first two levels are online modules complete with voice-over slides and quizzes. The final two belts involve projects and can take several months, Arkin explained.

"It's nice when we can convince them to do it because it's the right thing to do, but occasionally we use higher-ranking people to tell them they have to do it, or selfishly they realize that (instead of) doing this frantic rework and working six days a week, 14 hours a day to fix all these things, that it's just a lot easier to do it up-front when it's cheaper," said Arkin, when asked about the difficulties organizations sometimes face getting developers to accept security as part of their jobs.

At Adobe, this focus on security hasn't necessarily changed the type of bugs being found-vulnerabilities like integer overflows, for example, still crop up-but it has changed where in the code bugs are found as developers shift their focus to problem areas, Arkin said.

Bryan Sullivan, senior security researcher at Adobe, told eWEEK that one of the biggest gaps in security he has seen lately when talking to researchers and developers lies in the area of availability.

"It's getting harder and harder for attackers to exploit overflow conditions, thanks largely to platform defenses like ASLR and stack cookies, but this doesn't mean cyber-criminals are going to give up their wicked ways and go find legitimate day jobs," he said. "They're just going to move on to the next-easiest attack vector, which in my opinion is denial-of-service attacks. You can make just as much money blackmailing Websites to prevent DoS [denial-of-service] you can selling zero-days on the vulnerability market, and the DoS route is almost infinitely easier."

"The absolute No. 1 best piece of advice I can give to Web 2.0 developers is to be aware of what functionality they're implementing for the client tier versus the server tier," he added. "It sounds simple, but you'd be amazed how often this trips people up...I've seen client-side code that determined whether the user was authenticated, or whether he had admin rights, or that determined the price of items in a shopping cart. None of these activities should be taking place on the client tier."

According to Arkin, Adobe plans to expand the sandbox technology in Adobe Reader X this year to include read-only activities to stop attackers from reading sensitive content on a user's computer. The sandbox currently focuses just on write calls to Windows machines.

Ultimately, getting members of an organization to take security seriously requires top-down support, which requires persistence to build, Arkin said.

"A lot of security guys, they get very frustrated because they are repeating themselves over and over again," he said. "If you are talking to a sales guy, they are used to trying and trying and trying, [and] it doesn't always work. But for a security guy, they say, -oh well, they are too stupid to take my advice, I'm just going to give up'...if you give up, then that's it."