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.
Step 2 of 2:
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
CANCUN, Mexico – You couldn’t blame Adobe senior director of product security and privacy Brad Arkin for wanting on Thursday 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.”