Thought some of you might like to check this out. Great info from the Microsoft Team.
Security Development Lifecycle - Overview
The goals of Security Development Lifecycle (SDL) is to reduce the number of security related design and coding defects and to minimize the severity of defects that are undetected. SDL mainly focuses on first two elements of Secure by Design, Secure by Default, Secure by Deployment + Communication Process1 ( SD3+C) . SDL is software methodology agnostic. SDL enhances the software development process by integrating measures that lead to improve security.
Let’s take a look at the major phases of SDL and outline what you can do in your organization to implement SDL.
In addition to executive sponsorship and visibility, organizational accountability is key. There should be one or more individuals that are designated as the point people for security. Their jobs includes staying on top of security issues, promoting security practices within the development organization and being the voice of reason when it comes to making tough security decisions. They should monitor the various security related newsgroups, hold presentations on security topics (like common security code defects, buffer overflow, cross-site scripting, SQL injection, integer arithmetic, weak crypto, and so on), and play a key role in secure design, threat modeling, and security testing.
All engineering staff should be encouraged to update their security related skills at least once a year (whether on their own or by attending staff development events) These activities should be tracked so people don't fall between the cracks. It's critical that your engineering staff are aware of the current security landscape. It tends to change very rapidly.
Some good sources for online and instructor-led security education include Microsoft eLearning (www.microsoftelearning.com/security). Recommended reading includes Writing Secure Code, Threat Modeling, Software Security – Building Security in.
Requirement and Design Phase
The best opportunity to influence the security design of a software product is early in requirement and design phase. All functional and design specifications should contain a section describing security2.
Functional specifications should describe security features that will be directly exposed to the customers such as data gathering on forms, authentication by user password. Also advanced functionality and design specification should describe how to implement security features and make sure that all the functionality is implemented as secure features.
When designing features, it is crucial to carefully consider security concerns. Security must be planed into all projects from the beginning. It cannot be ‘injected’ at the end of the process. Features should be engineered with respect to security, such as robust use of Crypto APIs, use of managed code wherever possible, rigorously validating all data before processing it, and several other considerations.
SDL mandates that engineers spend time in the design phase to think about security of features and implementing secure design. An important part of the design process is understanding how to reduce the attack surface of applications or components3.
Understanding the threats to your software is a critical step to creating a secure product. Too many people bolt security technology to their app and declare it secure. The code is not secure unless the security countermeasures prevent the package from being compromised by all reasonable real-world threats. That's the goal of threat modeling4. Threat models are critical components of the design phase and will reference both a product's functional and design specifications to describe both vulnerabilities and mitigations.
Threat modeling must be completed during the product design process. A team cannot build a secure product unless it understands the assets the product is trying to protect. It is also important to consider threats and vulnerabilities present in the environment in which the product is deployed, or those that arise due to interaction and interfaces with other products or systems in real world solutions. The design phase of a product cannot be considered complete until a threat model is in place.
During the development phase you should implement security tools, security checklists, and secure coding best practice to help implement a secure design. Remember, a secure design could quite easily be rendered insecure by a weak implementation.
Security tools help, but tools alone do not make code resilient to attack. There is simply no replacement for having a knowledgeable work force that will use the tools to enforce policy. The new version of Visual Studio® 2005 Team System Developer's Edition includes some very, very useful security tools like PREFast5, SAL6, FxCop7, Application Verifier8.
To build secure software, you must get as much right as possible in design and implementation phases. Testing should be mainly the verification phase. A very useful testing technique for finding security defects is "fuzzing9 10," which means taking valid data, morphing that data, and then observing how the application consumes the data. Other testing phase steps include Penetration testing, Runtime verification. For critical products, penetration testing should be done by external resources.
You should re-review the threat model and re-evaluate the attack surface area of the software in this phase.
A security push is a team-wide focus on threat model updates, code review, testing, and documentation scrubing. The security push is not limited to code, the main tasks during the push are training, code reviews, threat model updates, security testing, document scrub. The determination of the completion of the security push should be based on task completion not on time elapsed. The exit criteria should be actionable and crisp and should be communicated widely to all the stake holders.
The Final Security Review (FSR) insures that the software is ready to ship from a security point of view. It's performed by the central security team with help from the product team. It should not be performed by the product team alone. The following components make up the FSR process – Product team coordination, threat modeling review, unfixed security bugs review and tools-use verification.
At the end of the FSR process, the findings are written up and a decision is made about releasing the software or reworking sections.
There are two major parts to security response, one is responding to security defects and working with people who find security issues in your code. The other aspect is learning from these mistakes.
The response team should encompass a “security response” team that faces customers and researchers and the product team that investigates and eliminates security vulnerabilities. The product team must learn from each vulnerability report and find related vulnerabilities and fix them in the security update and update the SDK process based on the lesson learned.
Craig Mundie, Trustworthy Computing White Paper http://www.microsoft.com/mscorp/twc/twc_whitepaper.mspx
Michael Howard, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, November 2004 http://msdn.microsoft.com/msdnmag/issues/04/11/default.aspx
Michael Howard, Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, November 2003
Michael Howard and David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003
Frank Swiderski and Window Snyder, Threat Modeling, Microsoft Press, Redmond Washington, 2004
Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, Redmond Washington 2006