Geeks With Blogs

News

Google My Blog


Murray Gordon Flash a-ah! Savior of the universe...

Thought some of you might liek to check this out. Great info from the Microsoft Team.

 

Security Development Lifecycle – Best Practices

Leadership and Education

·         Get management and executive buy in and spread awareness.

·         All developers, testers and project/program managers must train for security and SDL.

·         Threat modeling training should be incorporated in security training.

Product inception

·         Identify the team that will be responsible for tracking and managing security for the product. The team should coordinate and communicate the status of security issues in the product.

·         Designate a single person, the ‘security coordinator’, as an individual point of contact.

·         Bug reporting tools should be configured to track security bugs by cause and effect.

·         Tracking the security bug cause of the vulnerability should be logged.

·         Define and document the security ‘bug bar’ for the product.

Design Practices

·         Product or component that are designed or redesigned should be reviewed by security team.

·         All functional and design specifications should contain a section describing impacts on security.

·         Use ‘strong-named’ assemblies and request a minimal permission for managed code development

·         Have some logic and consistency in how firewall exceptions are made if any.

Risk Analysis

·         Complete threat models that address all functionality delivered by the product.

·         Document mitigations to all vulnerabilities identified using the threat model in either functional or design specifications.

·         Threat models and mitigations should be widely reviewed and agreed to by the product development team.

·         All architects, developers, testers, program managers and other stakeholders with reasonable understanding of the software involved must be asked to both contribute to and review threat models.

Security Documents and Tools

·         All the stakeholders must meet to identify and discuss what information customers will require in order to use the product securely. This process may involve reviewing usage scenarios with specific consideration of customer needs for documentation and tools.

·         User training teams will need to establish a plan to create customer-facing security documentation. It is imperative that this document must be completed in conjunction with product release.

Development Practices

·         Establish and document development best practices for the development team. Use the currently required versions of compilers, compile options, and tools to avoid delivering binaries with security vulnerabilities that can be avoided.

·         Use current versions of code analysis tools for either native and/or managed code.

·         New native code (C and C++) should not use several ‘banned’ versions of string buffer handling functions.

·         Shipping binaries must not contain sections marked as ‘shared’. These represent a potential security threat and should not be used. Properly secured dynamically created shared memory objects should be used instead.

Testing Practices

·         Testing plans should be created and successfully completed that address the following issues:

o        Security features and functionality act as specified to ensure all of the security features and functionality intended to mitigate threats perform as expected.

o        Security features and functionality function can’t be circumvented: A mitigation that can be bypassed represents a way that an attacker may attempt to exploit software.

·         Validating all data input and parsing code against malformed or unexpected data is a common way that attackers attempt to exploit software. Data fuzzing is an example of a general testing technique that can help prevent such attacks.

·         Test using File fuzzing and RPC fuzzing techniques.  

·         Penetration testing: Using the threat models to determine priorities, test and attack the software as a hacker might, using existing tools or designing new tools if needed.

·         Review and update threat models if needed. Threat models should be reviewed in order to ensure they remain accurate and comprehensively cover all functionality delivered by the software. Threat models should be used to drive security testing plans.

·         Re-evaluate the attack surface of the software. After the attack surface has been evaluated, attack surface documentation should be updated as appropriate.

Security Push

·         Review and update threat models.

·         Conduct code reviews for at-risk components.

·         Identify development and testing owners for everything in product. A development ‘owner’ must be identified for each source code file. A QA ‘owner’ must be identified for each binary file.

·         Code review priority. All code must be prioritized prior to the push starting.

o        Priority1 code is the code that is considered to be the most sensitive from a security standpoint.

§         All Internet- or network-facing code

§         Code in the Trusted Computing Base (“TCB”) (ex: kernel or SYSTEM code)

§         Code running as administrator or Local System, code running as an elevated user (also includes LocalService and NetworkService), or features with a prior history of vulnerability, regardless of version.

§         Any code that handles secret data, such as encryption keys and passwords, is considered Priority1 code.

§         For managed code, Priority1 code is considered to be any unverifiable code (any code that the standard PEVerify.exe tool reports as not verified).

§         All code supporting functionality exposed on the maximum attack surface is considered Priority1 code by definition.

o        Priority2 is optionally installed code that runs with user privilege, or code that is installed by default that doesn’t meet the pri1 criteria listed.

o        Priority3 is rarely used code and setup code. Setup code that handles secret data, such as encryption keys and passwords, is always considered Priority1 code.

·         Any code or component with high rates of security bug discovery is considered to be Priority1 code, even if it otherwise maps to Priority2 or Priority3 per the previous definitions. While the definition of high rates is subjective within the team, it is important to examine with extra scrutiny the portions of code that have experienced the highest rates of security bugs.

·         Include and prioritize all sample code shipped with the product. While generalized guidelines are difficult, consider how customers will be using the samples. Samples that are expected to be compiled and used with little changes in production environments should be considered ’Priority1’.

·         Review the security documentation plan. Examine how any changes to the product design that occurred during the development phase have impacted security documentation. Ensure that the security documentation plan will meet all customer needs.

·         Re-evaluate the attack surface of the software. After the attack surface has been evaluated, attack surface documentation should be updated as appropriate.

·         Focus the entire team on the push. There should be cross team assistance

Final Security Review

·         Make sure the software is ready to ship.

·         Product team coordination and collaboration for threat modeling review.

·         Review of unfixed security bugs and tools-use verification.

Response Planning

·         The software must have a publicly defined support policy that clearly identifies what versions are supported, for how long and in what manner.

·         Resources (Development, QA and Program Management) must be identified within the product team that can work on security response issues.

·         All code in the product must have an identified owner.

·         The software must have a documented sustaining model that addresses the need to release immediate patches in response to security vulnerabilities, and is not wholly dependent on infrequent service packs.

·         There must be a consistent and comprehensible policy for security response for components that are released out of band but that can be used to update or enhance the software after it has released

·         The product team must complete the information needed for an Emergency Response Plan. 

Resources:

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

http://msdn.microsoft.com/msdnmag/issues/03/11/default.aspx

Michael Howard and David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003

http://www.amazon.com/gp/product/0735617228/102-5060284-6046544

Frank Swiderski and Window Snyder, Threat Modeling, Microsoft Press, Redmond Washington, 2004

http://www.amazon.com/gp/product/0735619913/102-5060284-6046544

Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, Redmond Washington 2006

http://www.amazon.com/gp/product/0735622140/102-5060284-6046544

 

 

Posted on Friday, July 14, 2006 1:39 PM .NET Framework 2.0 | Back to top


Comments on this post: Microsoft's Security Development Lifecycle – Best Practices

# re: Microsoft's Security Development Lifecycle – Best Practices
Requesting Gravatar...
Mr Murray Gordon. Thanks for the explanation on the Microsoft Security Development Lifecycle. It has really help me to have a full detail on what it's all about. Cheers
Left by Okoro Bright on Jan 25, 2009 5:12 PM

Your comment:
 (will show your gravatar)


Copyright © Murray Gordon | Powered by: GeeksWithBlogs.net