Training Secure Software Engineers, Part 1

Ninja Button Black 1in.jpegOverview

You may have seen our previous post about the release of SAFEcode’s Software Security Training, to which Adobe contributed content from our ASSET Software Security Certification Program. This is the first of a three part series of posts about the ASSET  training. It’s our hope that people who want to supplement the SAFEcode training, or build their own training, might benefit from hearing about our experience building our program. In this post, I’ll provide an overview of  the certification program which is a key part of the Adobe Secure Product Lifecycle (SPLC). In future posts, I’ll present the logistics of building your own security training program or supplementing the SAFECode training; using metrics to track your progress; and some tips for success based on lessons we learned along the way.

In early 2009, the ASSET team looked around for pre-existing security training for developers and quality engineers and while we found plenty of content out there, nothing suited our specific needs. As a result, we decided to develop the Adobe Software Security Certification Program to begin teaching our developers, quality engineers and managers the basic, common language of security. Since then, Adobe has gone from being nominated for the “Lamest Vendor Response” at the 2008 Black Hat Pwnie Awards, to implementing the Adobe Reader Protected Mode (sandbox), the Flash Player Protected Mode (sandbox) and drastically decreasing our zero-day exploits and response time.

We believe the ASSET Software Security Certification Program has helped change employee attitudes toward security. This in turn has influenced the way software is developed and how reported issues are fixed. The training program has enabled the Adobe Software Security Engineering Team (ASSET) to transition from educating development teams on primary security concepts to the ability to have more in-depth, fluent conversations regarding security.

The Basics
At the basic level, the ASSET Certification Program is a four-tiered system, where people can earn a “belt” per level attained: white, green, brown and black.

The first two levels, the white and green belts, consist entirely of computer-based trainings (CBTs). The last two levels, the brown and black belts, are purely experiential. As expected, there are a lot more white belts within the company than there are black belts. While every developer needs to know something about security, not every developer needs to specialize in it. We provide an opportunity and a path for people who want to be security leaders, while at the same time providing a foundation for everyone to understand security fundamentals.

While it takes about eight hours of computer-based training to achieve a white belt, it can take hundreds of hours of hands-on project work to earn a brown or black belt. Some projects that can help aspiring brown and black belt candidates earn points toward their goal include: speaking at security conferences, implementing testing strategies, architecting or re-architecting products or components to enhance their security, or creating vulnerability detection and response strategies. Often these projects are combined.

Product teams and managers set goals to have all their employees white or green belt certified by a certain date. Motivated individuals make higher-level belts a part of their annual objectives and gain increased visibility and recognition when they achieve those levels. Another great benefit for those that earn higher-level belt status is they become candidates for the embedded “security champion” role within their team. ASSET leverages these champions and they are a critical part of how Adobe implements our Secure Product Lifecycle.

Birth of the Ninja
Along the way, we created an identity and corresponding mascot for the program – the ASSET Ninja – as a way for people to connect with their achievement. We informally refer to those who achieve certification as Ninjas. There are Ninja pins and digital Ninja badges for people to display. Ninjas have special skills. Ninjas are cool.

In the next post, I’ll talk about the logistics of creating your own certification program or supplemental security training, and tracking your progress.

Josh Kebbel-Wyen
Sr. Program Manager

 

Training Secure Software Engineers

SAFECode today announced the release of a software security training program. This is an exciting new resource, not just for anyone interested in learning more about writing secure code in the real world, but for software security leaders responsible for integrating security into how the development organization builds code. SAFECode’s ambition is that this training resource will provide building blocks for folks to develop a successful customized training program for their environment. I encourage you to check out the training and I also want to provide some context about how this SAFECode release came to be.

When I first joined Adobe, nearly five years ago, my top priority was raising the security IQ across the various roles responsible for getting code out the door: from people who write and test code to the many flavors of managers (product, program, people) and everyone in between. After looking at a lot of options, we built the ASSET Software Security Certification Program and have seen thousands of Adobe employees certified every year, since the launch in early 2009.

I have received many inquiries about sharing our course materials. Rather than publishing one-off drops of the Adobe training content, we instead worked with the other SAFECode members to use our courses as the seed for the software security training site launched today. With the pooled resources of all the SAFECode contributors and a place to focus the broader community of software security champions on training, we aim to have the biggest impact.

Please stay tuned as Josh Kebbel-Wyen, Senior Security Program Manager for ASSET (Adobe Secure Software Engineering Team) publishes a series of blog posts describing the ASSET certification program at Adobe. He will offer insights into how the program helped us establish a security culture at Adobe and share tips and tricks based on lessons learned along the way.

 

Brad Arkin
Chief Security Officer

Adobe Sponsors Microsoft Security Development Conference

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.

Brad Arkin
Chief Security Officer

New Role – 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!

Brad Arkin

Chief Security Officer

The Evolution of Exploit Sophistication

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.

Peleus Uhley
Platform Security Strategist

Top 10 Web Hacking Techniques of 2012

I was honored that Jeremiah Grossman asked me to serve again on the panel for the Top 10 Web Hacking Techniques of 2012. During the process, I get to take a look at the year’s most interesting research in greater detail than what is normally allowed in my day-to-day schedule. It makes me question what I thought I knew about existing attack techniques and how this year’s top research reflects on the industry.

Ranking the entries is challenging when you are comparing an SSL cryptography bug vs. the server side request forgery attacks vs. attacks against Chrome add-ons. To do so, requires that you read the full research, review the source code that was written and try to determine what impact the research had on the community. I typically start by considering factors such as:

  • Is the research completely new or is it just an incremental improvement of a known issue?
  • How many end-users are impacted?
  • Is this an individual bug affecting one vendor or an industry-wide issue?
  • What does successful exploitation yield (XSS, file access, OS control, etc.)?
  • Is the exploit practical to conduct?
  • What was the depth of research (a white paper, a tool, etc.)?
  • Extra points for style or creativity?

Reviewing the research to this depth then leads to uncovering smaller bits that are interesting in their own right. For instance, the Blended Threats and JavaScript research leveraged HTML5 to create cross-site file upload capabilities. You will find links to tools that back up the research in entries such as Blended Threats, Attacking OData, Bruteforcing PHPSESSID, and the Chrome add-on research. In some cases, the research reminds you about how many of the old tricks can be re-purposed against new technologies.

As an example, in July, 1998 Microsoft issued security bulletin MS98-004 which allowed, “Unauthorized ODBC Data Access with RDS and IIS”. In 1999, new information was published regarding the bug and Bugtraq ID 529 said exploiting the vulnerability could result in, “obtaining access to non-public servers or effectively masking the source of an attack on another network”. Today, we would classify this type of attack as, “Server Side Request Forgery” (SSRF). Modern SSRF attacks can include both old and new attack techniques. For instance, the ERPScan paper discussed how to use the gopher: protocol in an XML External Entity to attack SAP gateways. Over a decade later, we now have a formal taxonomy for classifying these types of bugs. However, the core issue of effectively sandboxing a web application to a finite set of resources is not much easier than it was 15 years ago. If anything, it has become more difficult as the number of supported communication channels between endpoints has increased.

Finally, you begin to think about why these top 10 bugs are critical to the industry. The panel ranked,”Compression Ratio Info-leak Made Easy” (CRIME) in the top slot due to the overall difficulty of the research, the vendor action required to address it, and the importance of SSL to the security ecosystem. As we move more data to the cloud where we will access it via our mobile or tablet devices, we will increasingly rely on SSL to protect it in transmission. Another interesting trend in this year’s top list was the multiple SSRF entries. As I mentioned, it wasn’t a completely new concept but rather a concept that is seeing a renewed interest as more data moves to the cloud. There were three SSRF entries in the Top 15 and the SSRF entry that was ranked number 2 includes research by two separate groups. As our dependence on cloud storage grows, SSRF will become an increasingly used attack vector for reaching all the critical data that lies behind those front end cloud servers.

As everyone reviews the Top 15, I encourage you to find time to read through each entry. The final list represents great information by talented researchers. Also, I would recommend sharing the list with your engineers. When I shared the Top 15 list with our internal Adobe community a few months ago, I can attest that at least one developer recognized a flaw that existed in his system and corrected the issue. Thanks to Jeremiah Grossman for putting this together each year and allowing me to be a part of it.

Peleus Uhley
Platform Security Strategist

RSA Conference 2013

Brad here. With RSA around the corner, I want to take a minute to talk about my plans for the conference. On Wednesday morning at 9:20 a.m., in room 132, I’ll debate best-selling author John Viega on the topic “Software Security: A Waste of Time.” Who will take each side? Which side will win? Show up on time to find out. Based on the prep sessions, this one should be fun.

Then on Thursday morning, (again at 9:20 a.m., in room 132), I’ll present “To the Cloud! The Evolution of Software Security at Adobe.” I’ll give a look into how the Adobe Secure Software Engineering team retrenched and retooled to help the company secure new hosted service offerings such as the Adobe Creative Cloud and the Adobe Marketing Cloud. I’ll reprise the talk in a 20 minute format at 3:00 p.m. on Thursday, in the RSA studio, in room 300.

As with every conference, I’m most excited about the hallway track. Looking forward to catching up with everyone who plans to attend.

Brad Arkin
Sr. Senior Director of Security

Click-to-Play for Office is Here!

Last week, we introduced a new Flash Player feature that includes a new Microsoft Office click-to-play capability that determines whether Flash Player is being launched within Microsoft Office and automatically checks the version of Office. Launching Flash Player 11.6 from within a version of Office older than Office 2010 will prompt the end-user before executing the Flash content, ensuring potentially malicious content does not immediately execute and impact the end-user. This feature adds another layer of defense against spearphishing attacks by allowing the end-user an opportunity to realize that they have opened a potentially malicious document and close it before the exploit executes.

Click-to-Play for Office should make this attack vector less attractive for attackers. Please update your environments to Flash Player 11.6 as soon as possible.

Peleus Uhley, Platform Security Strategist, ASSET

Raising the Bar for Attackers Targeting Flash Player via Office Files

Adobe has worked hard to make Flash Player more secure. We have worked with our partners Google and Mozilla to sandbox Flash Player in Google Chrome  on Windows, Mac, Linux and Chrome OS, and in MozillaFirefox on Windows. We have also been working closely with Microsoft to deliver Flash Player with Internet Explorer 10 on Windows 8, which means Flash Player runs in Enhanced Protected Mode, further restricting the plugin’s privileges in the browser, and Flash Player updates are delivered through Windows Update. (I’ll be blogging on the protections Enhanced Protected Mode provides for Flash Player users in a separate blog post later this month.) We also welcomed Apple’s initiative to  encourage Mac users to stay up-to-date by disabling older versions of Flash Player and directing users to install the latest, most secure version of Flash Player, and Mozilla’s click-to-play feature in Firefox. And we have worked hard on improving the update mechanism in Flash Player to make it easier for our user s to stay up-to-date. Windows and Macintosh users receive critical security patches through regular update checks by the Flash Player update mechanism. These enhancements help to protect users as they browse the Web.

Over the last year, Adobe has been driving down the number of Flash (SWF)-based zero-days used in the wild. Since the introduction of Adobe Reader X Protected Mode (aka sandboxing) in November 2010, the most common Flash Player zero-day attack vector has been malicious Flash content embedded in Microsoft Office documents and delivered via email. In fact, today’s Flash Player update addresses CVE-2013-0633 and CVE-2013-0634, both of which are being exploited in targeted attacks leveraging this very attack vector. In the next feature release of Flash Player, which is currently in beta, we will be delivering a solution designed to help make this attack vector less attractive.

Microsoft Office 2010 includes a Protected Mode sandbox for limiting the privileges of content within the document. If the document originates from the Internet or Untrusted Zone, the Protected View feature will prevent Flash Player content from executing by default. However, not everyone has the ability to update to Office 2010. In Office 2008 and earlier, Flash Player content will run by default without sandbox protections, making it an attractive attack vector for targeted attacks.

To protect users of Office 2008 and earlier, the upcoming release of Flash Player will determine whether Flash Player is being launched within Microsoft Office and check the version of Office. If Flash Player is launched within a version prior to Office 2010, Flash Player will prompt the end-user before executing the Flash content with the dialogue below:

OfficeClickToPlayFP

Therefore, if an end-user opens a document containing malicious Flash content, the malicious content will not immediately execute and impact the end-user. This extra step requires attackers to integrate a new level of social engineering that was previously not required.

We’ve seen these types of user interface changes lead to shifts in attacker behavior in the past and are hopeful this new capability will be successful in better protecting Flash Player users from attackers leveraging this particular attack vector as well.

We’ll post an update here as soon as this new feature in Flash Player becomes available. Stay tuned!

Peleus Uhley, Platform Security Strategist, ASSET

Firefox Click-to-Play Helps Protect Our Customers

The Adobe team has worked hard to improve patch adoption by delivering background updaters for Flash Player and Adobe Reader. In addition, we have worked with partners, such as Microsoft and Google, to reduce update fatigue by delivering patches through existing update mechanisms. However, one of the hardest challenges in protecting end users is reaching what is sometimes referred to as the “long tail” in an update graph. These are the users who, for various reasons, have not updated their systems in several months or even years. Reaching these last few end users can be difficult if they have disabled their update mechanisms. Unfortunately, they are also the users who are most likely to be successfully attacked.

Yesterday, Mozilla announced an update to the Firefox click-to-play feature that will warn users when they try to play plugin content with an out-of-date browser plugin. Since Mozilla will now be assisting plugin vendors in reminding these users to update, we will hopefully be able to convert more of them to patched versions. At the same time, Mozilla is helping to protect these users from those who would use older vulnerabilities to infect their systems. We support Mozilla in their efforts to protect and inform our mutual customers.