By Stacy Simpson, SAFECode
This post is the second in our Fundamentals of Managing Software Security series, a collection of articles that expand on the SDL planning and implementation guidance offered in SAFECode’s Fundamental Practices Paper and point to additional SAFECode resources that can assist with these key elements of program management. See the first post here.
We recently kicked off a new series of articles on the Fundamental Practices of Managing Software Security with a post that reinforced SAFECode’s assertion that a mature secure development lifecycle (SDL) is more than a checklist of secure development practices, but rather encompasses all aspects of a healthy business process, such as program management, stakeholder engagement, deployment planning, program measurement and continuous improvement. Building off of the SDL planning and implementation chapter of our Fundamental Practices for Secure Software Development publication, our last post discussed the intersection of corporate culture and SDL planning. In it, we referenced the important relationship between the security expertise and skill level of an organization and its security culture. In this post, we’ll expand on that theme a bit more.
As discussed in our Fundamental Practices paper, if an organization is to be successful in implementing an SDL, some level of training is necessary. The entire organization should be made aware of the importance of security, and more detailed technical training must be provided to development teams that clearly articulates the specific expectations of individuals and teams. Let’s break that last sentence down.
Part One: The entire organization should be made aware of the importance of security. Ask yourself – are you targeting a broad enough audience with your training initiatives? While there is an obvious need to educate developers on the specifics of writing secure code, does your organization also ensure that all individuals with a role to play in product development understand the importance of the secure development process and their role in supporting its implementation. If the engineering team expresses a need to address priority fixes identified in a recent pentest before production, does your product manager understand why that time needs to be built into the launch timeline – or will they demand a risk exception? Is the head of your development team supportive of team members taking time away from the project to participate in company-sponsored hackathons?
When we reviewed the secure engineering training programs in place at various SAFECode members, one of the most important aspects we uncovered was the need to set a solid base of foundational knowledge across the entire product team – Product Managers, Product Architects/Designers, Technical Writers, Program/Project Managers, Development Engineers, Service and Quality Assurance (QA) Engineers. It is imperative that foundational training be given to everyone who touches product development in order to build a more security-aware culture. Once this mindset is achieved, it becomes easier to change the specific behaviors of product engineering professionals.
SAFECode members also emphasize a need to tie training initiatives – and for that matter, the entire security program – to corporate objectives, as well as employee performance expectations. This requires visible executive support for security as well as training program initiatives and, sometimes, their direct participation in program execution. One SAFECode member credits the CEO’s explicit endorsement of the secure software effort coupled with the active involvement of group vice presidents in the training sessions themselves with raising the participation and enthusiasm for training within their organization.
Further, in soliciting feedback from employees undergoing training, it is evident that the training is most embraced when the employees can directly apply what they learn to their daily work. In this way, training becomes more than an abstract corporate requirement, but rather a tool they can use to continue their professional development and further their careers. To achieve this, many SAFECode members favor targeted, role-based content over generic training modules.
In fact, in-house security engineering training programs are such a significant focus at SAFECode members that one of our earliest papers offered guidance on the design and implementation of security engineering training programs. While the paper is certainly showing a little age, its core emphasis on the need to target a broad audience with in-house training initiatives that are tied to corporate goals and processes still holds today. If you are in the process of creating, reviewing or adding to your approach to security engineering training, it should have some helpful advice.
Of course, you also can’t ignore Part Two: More detailed technical training must be provided to development teams that clearly articulates the specific expectations of individuals and teams. For each of the secure development practices your organization requires or promotes, you’ll need to consider the expertise/skill level required for their proper execution and the coverage of that expertise in the organization. For example, the Secure Design Principles practice requires threat modeling expertise and possibly cryptography expertise. Does the organization have any resident experts in these areas? Is the number of experts sufficient?
Some organizations will bring in outside trainers to assist with skills development, while others will use in-house expertise, like resident Security Champions, to provide training and support. Many employ a hybrid of approaches to ensure adequate security expertise. You can also take advantage of community resources like Security Engineering Training by SAFECode, an online community resource offering free software security training courses delivered via on-demand webcasts. Our hope is that these training modules will be useful not only to individuals looking to enhance their own skills but can also be used as building blocks for those creating or managing an in-house training program for their development teams. All courses are free and published under a Creative Commons license and open, non-commercial usage of the content is encouraged. SAFECode members also have access to the source content for each course, allowing for simpler customization of materials.
Measuring the efficacy of the training program is also important. One SAFECode member suggests tailoring your measurement approach to the different roles and training levels. For example, recognize that while those at the foundational level can use multiple choice “guess-by-exclusion” verification questions to evaluate their progress, the more focused training levels for coders and designers often require a stronger verification and measurement mechanism to effectively measure knowledge transferred.
To close, there are a number of different approaches to designing and implementing a training program around secure software development. But if you take one thing away from this article, it should be to think bigger when deciding who to target. Software engineering and management professionals are joining your organization with what is likely to be highly variable degrees of security knowledge, so assumptions about the expertise of the development organization should not be made. And this is not simply a developer problem. Even if every single developer in your organization has a high level of security expertise, if the rest of the product development and management organization does not understand the SDL process and its relevance to their goals, it unlikely that the organization will have the type of security-supportive culture those highly-trained developers need to succeed.