Adobe makes pitch for defensive security research to cripple exploit writing

News

Adobe makes pitch for defensive security research to cripple exploit writing

Michael S. Mimoso, Editorial Director

To continue reading for free, register below or login

Requires Membership to View

To gain access to this and all member only content, please provide the following information:

By submitting your registration information to searchSecurity.in you agree to receive email communications from the TechTarget network of sites, and/or third party content providers that have relationships with TechTarget, based on your topic interests and activity, including updates on new content, event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile, unsubscribing via email or by contacting us here

  • Your use of searchSecurity.in is governed by our Terms of Use
  • We designed our Privacy Policy to provide you with important disclosures about how we collect and use your registration and other information. We encourage you to read the Privacy Policy, and to use it to help make informed decisions.
  • If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States.

We should be much more interested in how we can drive up the cost of writing exploits.

Brad Arkin, director of product security and privacy, Adobe Systems Inc. 

CANCUN, Mexico – You couldn’t blame Adobe senior director of product security and privacy Brad Arkin for wanting on Wednesday to shift the security industry’s focus away from vulnerabilities and toward understanding the tactics and economics behind exploit writing. Adobe, whose Reader and Flash products are ubiquitous on endpoints, is the top target of attackers who are exploiting Adobe software vulnerabilities at a greater rate and with more success than they have had attacking Windows.

“I think too there’s too much focus on vulnerabilities when we should be talking about exploits,” Arkin said during his keynote address at the Kaspersky Labs Security Analyst Summit 2012. “We should be much more interested in how we can drive up the cost of writing exploits.”

A more subtle point is that security researchers and enterprise security pros should be focusing on exploits in circulation that most impact their respective organizations, rather than trying to apply every software fix and workaround released by the Adobes, Apples and Microsofts of the world.

“It’s unfeasible to fix all this broken code,” Arkin said. “It makes more sense to put mitigations in place that drive up the cost of exploit [writing].”

Arkin took aim at the security research community, whose focus is offensive research; looking for security vulnerabilities in software that enable the writing of exploits, he said, drives down the cost of exploit writing.

“If you publish a paper about a new technique, a previously hard technique becomes easy,” Arkin said. “Offensive research advances very much change the game.”

Once research is published via white papers or presentations at industry conferences that research is quickly adapted and exploits are written relatively simply. Further tweaks lead to variants of malware families, all with minimal initial investment on the attacker’s end.

“Offensive researchers need to consider the consequences of what happens once an exploit or technique gets out there,” Arkin said. “Finding new offensive techniques helps nothing. Find ways to bring the utility of attacks down; that’s where there’s value.”

The research community counters that attackers generally are fluent in the latest vulnerabilities before the legitimate research community is engaged. However, once an exploit is loaded as a Metasploit module, the rate of attacks grows exponentially and a much lower level of sophistication is needed to carry out attacks.

Arkin points out, however, that once exploits are in the wild, their utility drops dramatically because the risk of detection becomes that much greater.

“The [victim] has a copy once the exploit is used, either in a log or trapped on a box,” Arkin said. “Samples get passed around. The risk of getting caught and identified increases the second you use an exploit. Eventually, someone will detect it.”

Security features deployed in software, such as address space layout randomization (ASLR) and data execution prevention (DEP), both on by default since Windows Vista was released in 2007, and the Adobe Acrobat and Reader Java Blacklist Framework, have gone a long way in preventing data execution in the companies’ respective products, in turn, driving up the cost of exploit writing.

“If it’s easy [for a vendor] to turn off a feature, then attackers won’t invest in an exploit,” Arkin said. “These mitigations further drop the utility of exploit.”