Posts tagged "ASSET"

Another Successful Adobe Hackfest!

ASSET, along with members of the Digital Marketing security team, recently organized an internal “capture the flag” event called Adobe Hackfest. Now in its third year, this 10-day event accommodates teams spread across various geographies. The objective is for participants to find and exploit vulnerable endpoints to reveal secrets. The lucky contestants that complete all hacks at each level are entered to win some awesome prizes.

This year, we challenged participants with two vulnerabilities to hack at two different difficulty levels, carefully chosen to create security awareness within the organization. Using the two hacks as teaching opportunities, we targeted three information security concepts under cross-site scripting, SQL injection and password storage categories. Our primary intention was to demonstrate consequences of using insecure coding practices via a simulated vulnerable production environment.

Contributing to the event’s success were logistics we’ve added from previous events to create a more seamless experience. The event was heavily promoted internally, and we had specific channels for participants to ask questions or request hints, including three hosted Adobe Connect sessions in different time zones.  The Digital Marketing security team also created a framework that generated unique secrets for every participant, and a leaderboard that would update automatically.

Participants worked very hard which generated stiff competition, with more than 50 percent unlocking at least one secret, and nearly 30 percent unlocking all four. Though our developers, quality engineers, and everyone else involved in shipping code undergo different information security trainings, this event helps bring theories into practice by emphasizing that there is no “silver bullet” when it comes to security, and the importance of a layered approach.

Participation was at an all-time high, and given the tremendous interest within Adobe, we are now planning to have Hackfests more frequently. Looking forward to Hackfest Autumn!

Vaibhav Gupta
Security Researcher

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.

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