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