Brad here. With the Microsoft Security Development Conference coming up on May 14th and 15th, in San Francisco, I want to take a minute to talk about my plans for the week.
On Tuesday, May 14th, at 3:00 p.m., I’ll present the topic “Never Waste a Crisis: Take 2. ” This presentation is based on the original one I gave at the RSA Conference in 2012, sharing some lessons on how to prepare for a crisis and what to do to ensure you leave your software security program in a stronger position once it’s all over. This time, I’ll talk about how we put these lessons to work with respect to another crisis: the inappropriate use of a code signing certificate which happened at Adobe in September 2012. In this second take on the topic of crises, I’ll grade my own advice — and my own performance at following that advice — with lessons learned from the code signing incident.
Then on Wednesday, May 15th at 9:45 a.m., I’ll present a keynote on: “Accepting Defeat: Changing the Battle Plan.” I’ll talk about how to acknowledge when the current approach to a problem isn’t working, abandoning a long-standing strategy and looking for new approaches. I’ll give two examples of how this worked for us at Adobe.
If you haven’t registered yet for the Microsoft Security Development Conference, I encourage you to go ahead. You can use this discount code: ADB@SDC!@
I’m looking forward to catching up with everyone who plans to attend. See you there.
Chief Security Officer
For those who may have seen the news and are looking for more context, I’ve put together a quick post about my new role as Adobe’s Chief Security Officer. While this is a newly created role at Adobe, it’s an expansion of responsibilities that builds upon on the initiatives I’ve been leading for nearly five years at the company.
As CSO, I will report to Bryan Lamkin, SVP of Technology and Corporate Development, and will work in partnership with Adobe’s global information technology team led by our CIO Gerri Martin-Flickinger. I will continue to oversee the Adobe Secure Software Engineering Team (ASSET), responsible for implementing our Secure Product Lifecycle that engineers products to be robust against attacks, as well as the Product Security Incident Response Team (PSIRT), responsible for managing response to product security incidents. In my new role, I have the opportunity to lead Engineering Infrastructure Security, a team that builds and maintains security-critical internal services relied on by our product and engineering teams, such as code signing and build environments. I will also continue to manage and foster two-way communication with the broader security community, a vital part of the central security function.
The driving goal behind our security work is to protect our customers from those who would seek to harm them. Adobe has some of the most widely-deployed software in the world and we are keenly aware that this makes us a target. We remain committed to doing everything we can to defend against the bad guys. I am excited to continue leading the charge at Adobe!
Chief Security Officer
When we look at the exploits that Adobe patched from February and March of this year, it is clear that today’s zero-day exploits are increasingly more sophisticated. This increase in sophistication is not limited to the skills needed to find and exploit the vulnerability. The code used to exploit the environment is also more robust in terms of code quality and testing. In short, exploit creation today requires the same level of rigor as professional software engineering projects.
Today’s advanced exploits need to be written to work in any target environment. For instance, February’s Reader 0-day supported 10 different versions of Reader with 2 sub-versions dependent on the end-user’s language. In addition, Flash Player CVE-2013-0634 had shell code for Windows XP, Vista, Windows 7, Server 2003, Server 2003 R2, Server 2008 and Server 2008 R2 as well as supporting six versions of Flash Player. Variants of CVE-2013-0634 also supported Firefox and Safari on Mac OS X. An exploit developer would need a robust testing environment to ensure that the exploit would work in that many different environments for each version of Flash Player. The exploit writers even took into account different CPU architectures by including a signed 32-bit payload and a 64-bit payload. This reflects the fact that these exploits are written with professional code quality and stability requirements for distribution across a dynamic target base.
As vendors are increasing software defenses through techniques such as sandboxing, attackers are now combining multiple vulnerabilities from different vendors to achieve their goals.When I look at the reports from Pwn2Own and some of the recent zero-day reports such as CVE-2013-0643, attacks are moving toward combining vulnerabilities from multiple products, some of which are from different vendors. We are moving away from the model of single vulnerability exploits.
This is all a part of the natural evolution of the threat landscape and the commercialization of exploits. This will require an equal evolution on the part of vendors in their software defences. Karthik Raman and I will be discussing this topic, “Security Response in the Age of Mass Customized Attacks,” in more detail at the upcoming Hack in the Box Conference (HITB) Amsterdam next week. Please stop by our talk if you would like to discuss this further.
Platform Security Strategist