Training

Training has always played a critical role in software security because software developers and architects often start with little security knowledge. 

Training Level 1

[T1.1: 77] Conduct awareness training.

To promote a culture of software security throughout the organization, the SSG conducts awareness training. As examples, the training might be delivered via SSG members, an outside firm, the internal training organization, or e-learning. Course content doesn’t necessarily have to be tailored for a specific audience. For example, all developers, QA engineers, and project managers could attend the same “Introduction to Software Security” course, but this activity should be enhanced with a tailored approach that addresses the firm’s culture explicitly. Generic introductory courses that cover basic IT or high-level software security concepts don’t generate satisfactory results. Likewise, awareness training aimed only at developers and not at other roles in the organization is insufficient.

[T1.5: 37] Deliver role-specific advanced curriculum.

Software security training goes beyond building awareness by enabling trainees to incorporate security practices into their work. This training is tailored to cover the tools, technology stacks, development methodologies, and bugs that are most relevant to the trainees. For example, an organization could offer four tracks for its engineers: one for architects, one for Java developers, one for mobile developers, and a fourth for testers. Tool-specific training is also commonly observed in such a curriculum. Note that training is important for many different roles within an organization, including QA, product management, executives, and others.

[T1.7: 46] Deliver on-demand individual training.

The organization lowers the burden on trainees and reduces the cost of delivering training by offering on-demand training for individuals across roles. The most obvious choice, e-learning, can be kept up to date through a subscription model, but an online curriculum must be engaging and relevant to the trainees in various roles to achieve its intended purpose. Training that isn’t used won’t create any change, and hot topics like new IoT and cloud architectures and new delivery styles such as gamification will attract more interest than boring policy discussions. For developers, it’s possible to provide training directly through the IDE right when it’s needed, but in some cases, building a new skill (such as code review or threat modeling) might be better suited for instructor-led training, which can also be provided on demand.

Training Level 2

[T2.5: 27] Enhance satellite through training and events.

The SSG strengthens the satellite network by inviting guest speakers or holding special events about advanced topics (e.g., the latest software security techniques for DevOps or AWS cloud development). Offering attendees coffee and snacks doesn’t hurt. This effort is about providing the satellite customized training so that it can fulfill its specific responsibilities, not about inviting the satellite members to brown bags or signing them up for the standard computer-based training. In addition, a standing conference call with voluntary attendance won’t get the desired results, which are as much about building camaraderie as they are about sharing knowledge and organizational efficiency. Face-to-face meetings are by far the most effective, even if they happen only once or twice a year and some participants must attend over videoconferencing.

[T2.6: 28] Include security resources in onboarding.

The process for bringing new hires into an engineering organization requires that they complete a training module about software security. The generic new hire process usually covers topics like picking a good password and making sure that people don’t follow you into the building, but this orientation period can be enhanced to cover topics such as secure coding, the SSDL, and internal security resources. The objective is to ensure that new hires contribute to the security culture. Turnover in engineering organizations is generally high, and although a generic onboarding module is useful, it doesn’t take the place of a timely and more complete introductory software security course.

[T2.8: 28] Create and use material specific to company history.

To make a strong and lasting change in behavior, training includes material specific to the company’s history. When participants can see themselves in a problem, they’re more likely to understand how the material is relevant to their work as well as when and how to apply what they’ve learned. One way to do this is to use noteworthy attacks on the company’s software as examples in the training curriculum. This training shouldn’t cover platforms not used by developers (Windows developers probably won’t care about old Unix problems) or examples of problems relevant only to languages no longer in common use (Java developers probably don’t need to understand buffer overflows in C). Stories from company history can help steer training in the right direction, but only if those stories are still relevant and not overly censored. Both successful and unsuccessful attacks can make good teachable moments.

Training Level 3

[T3.1: 3] Reward progression through curriculum.

Knowledge is its own reward, but progression through the security curriculum brings other benefits, too, such as career advancement. The reward system can be formal and lead to a certification or an official mark in the human resources system, or it can be less formal and include motivators such as documented praise at annual review time. Involving a corporate training department and/or HR team can make security’s impact on career progression more obvious, but the SSG should continue to monitor security knowledge in the firm and not cede complete control or oversight. Coffee mugs and t-shirts can build morale, but it might take the possibility of real career progression to change behavior.

[T3.2: 16] Provide training for vendors or outsourced workers.

Vendors and outsourced workers receive the same level of software security training given to employees. Spending time and effort helping suppliers get security right at the outset is much easier than trying to determine what went wrong later on, especially if the development team has moved on to other projects. Training individual contractors is much more natural than training entire outsource firms and is a reasonable place to start. It’s important that everyone who works on the firm’s software has an appropriate level of training, regardless of their employment status.

[T3.3: 15] Host software security events.

The organization highlights its security culture as a differentiator by hosting security events featuring external speakers and content. Good examples of this are Microsoft’s BlueHat and QUALCOMM’s Mobile Security Summit, given their featuring of external presenters and their focus on helping development create better code. Employees benefit from hearing outside perspectives, especially those related to fast-moving technology areas, and the organization as a whole benefits from putting its security credentials on display (see [SM3.2 Run an external marketing program]). Events open only to small, select groups won’t result in the desired culture change across the organization.

[T3.4: 14] Require an annual refresher.

Everyone involved in the SSDL is required to take an annual software security refresher course. This course keeps the staff up to date on security and ensures that the organization doesn’t lose focus due to turnover, evolving methodologies, or changing deployment models. The SSG might take half a day to give an update on the security landscape and explain changes to policies and standards. A refresher can also be rolled out as part of a firm-wide security day or in concert with an internal security conference, but it’s useful only if it’s fresh.

[T3.5: 5] Establish SSG office hours.

The SSG offers help to anyone during an advertised lab period or regularly scheduled office hours. By acting as an informal resource for people who want to solve security problems, the SSG leverages teachable moments and emphasizes the carrot over the stick approach to security best practices. Office hours might be held one afternoon per week in the office of a senior SSG member, but roving office hours are also a possibility, with visits to particular product or application groups by request, perhaps prioritizing visits by key functionality being developed and its security implications.

[T3.6: 1] Identify new satellite members through training.

Recruit future satellite members (e.g., champions) by noting people who stand out during training courses, office hours, capture-the-flag exercises, hack-a-thons, and other opportunities to show skill and enthusiasm, and encouraging them to join the satellite. The satellite often begins as an assigned collection of people scattered across the organization who show an above-average level of security interest or advanced knowledge of new technology stacks and development methodologies (see [SM2.3 Create or grow a satellite]). Identifying future members proactively is a step toward creating a social network that speeds the adoption of security into software development and operations. A group of enthusiastic and skilled volunteers will be easier to lead than a group that is drafted.