Archive for May, 2013

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