- The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software
- Foreword
- Introduction
- I. The Need for the SDL
- Bibliography
- 2. Current Software Development Methods Fail to Produce Secure Software
- Bibliography
- 4. SDL for Management
- II. The Security Development Lifecycle Process
- 5. Stage 0: Education and Awareness
- 6. Stage 1: Project Inception
- Determine Whether the Application Is Covered by SDL
- Assign the Security Advisor
- Act as a Point of Contact Between the Development Team and the Security Team
- Holding an SDL Kick-Off Meeting for the Development Team
- Holding Design and Threat Model Reviews with the Development Team
- Analyzing and Triaging Security-Related and Privacy-Related Bugs
- Acting as a Security Sounding Board for the Development Team
- Preparing the Development Team for the Final Security Review
- Working with the Reactive Security Team
- Build the Security Leadership Team
- Make Sure the Bug-Tracking Process Includes Security and Privacy Bug Fields
- Determine the “Bug Bar”
- Summary
- References
- 7. Stage 2: Define and Follow Design Best Practices
- Bibliography
- Bibliography
- 10. Stage 5: Creating Security Documents, Tools, and Best Practices for Customers
- Bibliography
- 12. Stage 7: Secure Testing Policies
- 13. Stage 8: The Security Push
- 14. Stage 9: The Final Security Review
- 15. Stage 10: Security Response Planning
- 16. Stage 11: Product Release
- 17. Stage 12: Security Response Execution
- III. SDL Reference Material
- 18. Integrating SDL with Agile Methods
- 19. SDL Banned Function Calls
- The Banned APIs
- Banned String Copy Functions and Replacements
- Banned String Concatenation Functions and Replacements
- Banned sprintf Functions and Replacements
- Banned “n” sprintf Functions and Replacements
- Banned Variable Argument sprintf Functions and Replacements
- Banned Variable Argument “n” sprintf Functions and Replacements
- Banned “n” String Copy Functions and Replacements
- Banned “n” String Concatenation Functions and Replacements
- Banned String Tokenizing Functions and Replacements
- Banned Makepath Functions and Replacements
- Banned Splitpath Functions and Replacements
- Banned scanf Functions and Replacements
- Banned “n” scanf Functions and Replacements
- Banned Numeric Conversion Functions and Replacements
- Banned gets Functions and Replacements
- Banned IsBad* Functions and Replacements
- Banned OEM Conversion Functions and Replacements
- Banned Stack Dynamic Memory Allocation Functions and Replacements
- Banned String Length Functions and Replacements
- Why the “n” Functions Are Banned
- Important Caveat
- Choosing StrSafe vs. Safe CRT
- Using StrSafe
- Using Safe CRT
- Other Replacements
- Tools Support
- ROI and Cost Impact
- Metrics and Goals
- References
- The Banned APIs
- 20. SDL Minimum Cryptographic Standards
- 21. SDL-Required Tools and Compiler Options
- 22. Threat Tree Patterns
- Spoofing an External Entity or a Process
- Tampering with a Process
- Tampering with a Data Flow
- Tampering with a Data Store
- Repudiation
- Information Disclosure of a Process
- Information Disclosure of a Data Flow
- Information Disclosure of a Data Store
- Denial of Service Against a Process
- Denial of Service Against a Data Flow
- Denial of Service Against a Data Store
- Elevation of Privilege
- References
- Appendix
- Index
- About the Authors
[biblio13_01] (Microsoft 2006) Microsoft Corporation. .NET Framework Tools, “PEVerify Tool (Peverify.exe),” http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfPEVerifyToolPeverifyexe.asp. MSDN, 2006.
[biblio13_02] (Secunia 2004) Secunia Advisories. “Novell NetWare Admin/Install Password Disclosure,” http://secunia.com/advisories/11188. March 2004.
[biblio13_03] (Howard and LeBlanc 2003) Howard,Michael, and DavidLeBlanc. Writing Secure Code, 2d ed. Redmond, WA: Microsoft Press, 2003.
[biblio13_04] (Howard, LeBlanc, and Viega 2005) Howard,Michael, DavidLeBlanc, and JohnViega. 19 Deadly Sins of Software Development. New York, NY: McGraw-Hill, 2005.
[biblio13_05] (Howard 2003) Howard,Michael. “Expert Tips for Finding Security Defects in Your Code,” http://msdn.microsoft.com/msdnmag/issues/03/11/SecurityCodeReview/default.aspx. MSDN Magazine, November 2003.
-
No Comment