Adobe’s Software Vulnerability Report Form Gets a Facelift

This week Adobe launched a new software vulnerability report form. This web form is the primary mechanism for our colleagues in the information security community to disclose security vulnerabilities that may impact Adobe’s customers.

In addition to some functionality improvements, we’ve included additional questions to accelerate our vulnerability triage process. We welcome your feedback on the new form, as well as suggestions on ways to improve our process. You can always reach us via PSIRT@adobe.com.

Finally, we’ll be at Black Hat and DEF CON this year, and we’re looking forward to catching up with everyone who plans to attend. See you there!

Pieter Ockers
Program Manager, PSIRT

Recon 2013

Recon, held annually in Montreal, Canada, has a reputation for being one of the best technical security conferences in the world. I was once again privileged to attend Recon (June 21-23) and this year’s conference did not disappoint.

Slides from the conference are up here on the conference Web site. As a security defender, I especially enjoyed learning about the innards of EMET 4.0 from Elias Bachaalany of the Microsoft Security Response Center (MSRC). Christopher Domas’s talk on using visualization for reverse engineering will strike a chord with anyone who has thought about using the human brain’s formidable pattern-recognition capabilities for sifting through masses of data — in this case, binary data.

Recon is known for assembling researchers from the US, Canada, Europe, and many other parts of the world and it was fun, as always, to engage in conversations with friends, colleagues, partners, and the independent research community.

Vieux-Montréal (Old Montreal) is a 15-minute walk away from the conference venue and at sunset it is more than pleasant there:

Montreal

 

 

 

Until belle Montreal beckons again!

Karthik Raman
Security Researcher

Adobe Sponsors and Participates in FIRST Conference

Last week I attended the Forum of Incident Response and Security Teams (FIRST) conference in Bangkok,Thailand. Adobe has been a member of FIRST for a few years, and has sponsored  the annual conference, which is always excellent.

This year we had a special opening keynote presentation by the Prime Minister of Thailand. It was lovely to see such a high-ranking official rate security as important enough to make time to participate in the conference. One presentation that really stood out for me was Verisign’s talk about some of the investigations they have conducted and the tactics they use for information gathering. In addition to presentations from experts from around the world, I spoke about a recent incident and how Adobe was able to leverage the event to drive lasting positive improvements.

I was so impressed with the conference and the organization, I am now proudly serving as the corporate secretary of FIRST.

Lindsey Wegrzyn Rush
Sr. Product Manager, Abuse and Security

Reader 9.x Reaches End-of-Life

In line with the Adobe Support Lifecycle Policy, Adobe’s Acrobat 9.x and Reader 9.x suite of products reached their end-of-life (EOL) today, June 26, 2013. This means that Adobe will no longer provide security or other updates to this product suite.

Over the years, we’ve made several security enhancements in the successors of Reader 9, Reader X and Reader XI, including the Protected Mode (aka “sandboxing”) and Protected View. There has never been a better time to upgrade to Reader XI. Please upgrade, ensure automatic updates are turned on, and stay secure!

Karthik Raman

Security Researcher, ASSET

Training Secure Software Engineers, Part 3: Tips on creating your own training

This is the third and final post in our series on the Adobe Software Security Engineering Team’s (ASSET) Software Security Certification Program, which formed the basis for the newly released SAFEcode Software Security Training. In the Overview post, I talked about the overall program, in the second post, I talked about the logistics of creating your own training program and using metrics to track your progress. In this post, I’ll provide some tips for creating your own software security certification program or supplementing the SAFEcode Software Security Training with your own training.

Tips
While we were in the process of creating the ASSET certification program, there was a lot of trial-and-error learning that took place. Here are some of our lessons learned so if you’re building your own training, you can skip the growing pains we experienced:

  • Know your audience and tailor content to their needs. People will become frustrated if they cannot connect what they are learning to what they need for their job. It’s like the age old question, “Why do I have to learn algebra if I’m never going to use it?” I’m not going to explain that one, but I do not want to address my deadline crunched Java developer with the specific reasons of how a course called “How to Write More Secure C/C++” is going to alleviate a worse situation down the road.
    • We began with a more liberal arts approach to security and have since shifted to a more proscriptive approach over time.
    • Also, we now have different tracks for different roles at Adobe. There’s a manager’s track, a Dev track and a QA track.
  • Get executive buy-in. You can market a training program within a company until you die and get no traction unless somebody with power and influence throws their weight behind it. People want to know that the investment they make with their time will be recognized and valued by someone. What does it matter if I have a fancy badge if nobody cares what it means? Get executives to talk about, email about and even mandate trainings.
  • Use crises to push your agenda. In order to get executives to pony up, you need to demonstrate the value of your offering. The most effective way to do this is to leverage a crisis. Use vulnerabilities that are painful or embarrassing to remind execs that proactive security work pays off; use the training to show them you have a solution. A developer who knows secure coding will be more efficient at hardening code.
  • Use metrics to encourage participation, stimulate competition and show progress. We use our training metrics tracking tool (TESSA) to allow everyone to see who is and isn’t trained. Training metrics consistently show that teams with higher training density perform better on quantified metrics like incident response time. Making metrics public, within the company, sparks competition among teams and individuals. Employees have tied achievement of certification belts to goals for their annual reviews.
  • Refresh content on a regular basis. As we all know, the threat landscape continues to change. The Web hacking techniques from 2013 are different than the ones the Web hacking techniques for 2012. Developers continue to use new languages, open source components and new tools in their jobs. For this reason, it’s important to revisit your security training content on at least an annual basis and update anything that’s out of date.

Real Results
We believe the evidence proves our security training program is working. The first two levels of the certification program are now required of every developer and tester on every product team, as part of the Secure Product Lifecycle (SPLC) at Adobe. In 2008, security wasn’t a regular topic on executive roadmaps, today the highest levels of management at Adobe review the “Security Health” dashboard for each major product and service on a regular basis.

The Intangibles
Although there is an initial investment associated with creating your own training, it’s a great way to brand your security team(s) throughout the company and get the word out.

The training program has allowed the ASSET team to transition from “giving a man a fish” by repeatedly teaching primary security concepts, to raising security awareness among the development teams and “teaching a man to fish” by scaling and creating embedded security leaders (brown and black belts) to lead the security charge within development teams.

The impact of the ASSET certification program can’t be overstated. Creating a training and certification program at Adobe catalyzed a cultural shift and ultimately built a foundation for the company to innovate and improve the security of all its products.

We began with approximately 25 original course offerings, and have since doubled that number. We continue to revise and add courses to our curriculum and build on the security culture at Adobe. If you’re interested in talking about security training and our certification program, let’s catch up at the next conference.

Josh Kebbel-Wyen
Sr. Program Manager

Training Secure Software Engineers, Part 2: Criteria, content and metrics

This is Part 2 in our series of posts on the Adobe ASSET Software Security Certification Program which formed the basis for the newly released SAFEcode security training. In the first post, I gave an overview of the program. This second post deals with the logistics of creating your own certification program or supplemental training, and tracking your progress.

Setting Criteria
As I mentioned in the previous post, the ASSET (Adobe Secure Software Engineering Team) certification program is a four-tiered system, where people earn a “belt” per level attained: white, green, brown and black. Let’s start with the first two belt levels – the computer based trainings (CBTs).

It was important to us that participants set their own pace for going through the training. We knew that an average developer or quality engineer would not want to sit in, nor get a lot out of an eight hour classroom session delivered in a single day. Long sessions aren’t scalable for what we were trying to achieve – that is, basic security training for people that need to know security concepts as part of their job, but don’t necessarily want to be security professionals. We wanted security to be a necessary skill-set of everyone involved in development at Adobe.

Our original criteria for the training is that it must:

  • Be around 30-40 minutes in length (we have since shortened our goal length to 15-20 minutes)
  • Employ as simple an approach to the concepts discussed as possible
  • Use real-life examples from Adobe code and web sites
  • Have direct bearing on the job functions of our audience

Creating the Content
Security topics were divided up among the researchers on the ASSET team. Researchers chose topics either based on their own areas of expertise or areas where they wanted to become stronger. A subset review team critiqued the training and helped create tests for each training module, consisting of 10 to 15 questions about the most important elements of the training modules. Content took about two weeks of research per topic and a week of revisions. The CBT’s (computer based training) consist of PowerPoint decks with recorded voice-overs and some animated demos. As examples, we used Adobe code to drive issues home to developers who may have created, or at least worked with similar code. Fortunately, Adobe has an excellent multi-use product called Adobe Connect that, among other things, can be used as a Learning Management System (LMS). We were lucky to be able to adopt something native to our company rather than have to re-train people to use something new.

Using Metrics
We wrote a web tool called Tessa to interface with Adobe Connect to allow people to check the status of their progress through the training and provide an automated way for managers to follow-up with team members about their certification status. Status is visible to anyone within the company, which is a subtle way of encouraging competition among teams and individuals.

Ninja blog post

Above is a screen shot for Brad Arkin’s org. The yellow buttons allow him to automatically send a “nag” email to any slackers in his org. Clicking on a yellow button opens his email client and populates a message with the appropriate content to the person he has selected to nag. That way, all he has to do is hit “send”.

Going Public
We’ve also used this data to pull reports on geographies and business units to help spur competition. We found that our biggest success comes from the India offices, which have about twice the compliance level of the US and Europe combined. People get so into the program that they have requested paper certificates, signed by CSO, Brad Arkin, which we then mail to them.

Ultimately, per product certification status rolls up to an overall “Security Health” dashboard which is reviewed by executives at quarterly operations meetings.

In my next post: Tips for supplementing the SAFEcode Software Security training or building your own.

Josh Kebbel-Wyen
Sr. Program Manager

 

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