One of you readers asked me to investigate why Microsoft decided to train all developers on Security, rather than targeting either (a) those developers who touch security-related features or (b) one designated “security expert” on each development team.
You asked, I answer with a collection of quotes from various sources, but basically all from the horse’s mouth (yes Michael, that makes *you* the horse in this analogy). Please enjoy, and feel free to link others you might stumble across…
http://web.archive.org/web/20031202020539/http://blogs.gotdotnet.com/mikehow/PermaLink.aspx/1c7eb862-aec9-475e-bff3-c32bb3f063f5
“We need to teach more people about security. Now, you’re probably a geek, or a geek-wanna-be, and I bet you’re thinking, “ah, he’s trying to sell more copies of his book, he wants to teach people about writing secure code.” Ok, that’s true, I think software designers, developers & testers need to understand what it takes to build secure software; the threats have changed, and security no longer resides in the realm of the Security High Priesthood nor the Security Learned Few. Building secure software is simply part of getting the job done. Just like we learned the basics of optimal algorithms in school, kids coming out of school need to know the basics of building code that will run in that most hostile of environments – The Internet.”
http://blogs.msdn.com/sdl/archive/2007/05/02/security-education-v-security-training.aspx
“We require our SDL training to emphasize the basics of secure design, development and test – then allow employees and their management to select the training that meets the needs of their particular product or service. There is one other point that bears mentioning – our training is constantly being reviewed or embellished to make sure that emerging security or privacy issues are being addressed. ”
http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/
“If your engineers know nothing about the basic security tenets, common security defect types, basic secure design, or security testing, there really is no reasonable chance they could produce secure software. I say this because, on the average, software engineers don’t pay enough attention to security. They may know quite a lot about security features, but they need to have a better understanding of what it takes to build and deliver secure features. It’s unfortunate that the term security can imply both meanings, because these are two very different security realms. Security features looks at how stuff works, for example the inner operations of the Java or common language runtime (CLR) sandbox, or how encryption algorithms such as DES or RSA work. While these are all interesting and useful topics, knowing that the DES encryption algorithm is a 16-round Feistel network isn’t going to help people build more secure software. Knowing the limitations of DES, and the fact that its key size is woefully small for today’s threats, is very useful, and this kind of detail is the core tenet of how to build secure features.
“The real concern is that most schools, universities, and technical colleges teach security features, and not how to build secure software. This means there are legions of software engineers being churned out by these schools year after year who believe they know how to build secure software because they know how a firewall works. In short, you cannot rely on anyone you hire necessarily understanding how to build security defenses into your software unless you specifically ask about their background and knowledge on the subject.”
http://msdn2.microsoft.com/en-us/library/ms995349.aspx
(a) “But is it important to note that an education program is critical to the success of the SDL. New college and university graduates in computer science and related disciplines generally lack the training necessary to join the workforce ready and able to design, develop, or test secure software. Even those who have completed course work in security are more likely to have encountered cryptographic algorithms or access control models than buffer overruns or canonicalization flaws. In general, software designers, engineers and testers from industry also lack appropriate security skills.
“Under those circumstances, an organization that seeks to develop secure software must take responsibility for ensuring that its engineering population is appropriately educated. Specific ways of meeting this challenge will vary depending on the size of the organization and the resources available. An organization with a large engineering population may be able to commit to building an in-house program to deliver ongoing security training to its engineers, while a smaller organization may need to rely on external training. At Microsoft, all personnel involved in developing software must go through yearly “security refresher” training.”
(b) “One key aspect of the security pushes of early 2002 was product group team-wide training for all developers, testers, program managers, and documentation personnel. Microsoft has formalized a requirement for annual security education for engineers in organizations whose software is subject to the SDL. The need for an annual update is driven by the fact that security is not a static domain: threats, attacks and defenses evolve. As a result, even engineers who have been fully competent and qualified on the aspects of security that affect their software must have additional training as the threat landscape changes. For example, the importance of integer overflow vulnerabilities has increased dramatically in the last four years, and it has been demonstrated recently that some cryptographic algorithms have previously unrecognized vulnerabilities.
“Microsoft has developed a common introduction and update on security that is presented to engineers in both “live training” and digital media form. Microsoft has used this course as the basis for specialized training by software technology and by engineer role. Microsoft is in the process of building a security education curriculum that will feature further specialization by technology, role, and level of student experience.”
http://msdn.microsoft.com/msdnmag/issues/03/11/SecurityCodeReview/default.aspx
“Hopefully, you realize that reviewing other people’s code, while a good thing to do, is not how you create secure software. You produce secure software by having a process to design, write, test, and document secure systems, and by building time into the schedule to allow for security review, training, and use of tools. Simply designing, writing, testing, and documenting a project, and then looking for security bugs doesn’t create secure software. Code reviewing is just one part of the process, but by itself does not create secure code.”
The Security Development Lifecycle Chapter 5
“If your engineers know nothing about basic security tenets, common security bug types, basic secure design, or security testing, there really is no reasonable chance that they will produce secure software. We say this because, on average, software engineers know very little about software security. By security, we don’t mean understanding security features; we mean understanding what it takes to build and deliver secure features.”
The rattled cough of a Hyper-Empathetic PM 