August 1, 2006 XP Security. August 1, 2006 Comparing XP and Security Goals XP GOALS User stories No BDUF Refactoring Continuous integration Simplicity.
Published byModified over 5 years ago
Presentation on theme: "August 1, 2006 XP Security. August 1, 2006 Comparing XP and Security Goals XP GOALS User stories No BDUF Refactoring Continuous integration Simplicity."— Presentation transcript:
August 1, 2006 Comparing XP and Security Goals XP GOALS User stories No BDUF Refactoring Continuous integration Simplicity SECURITY GOALS Prevention Detection Authentication Integrity Availability Privacy
August 1, 2006 Security Design Principles 1.Least Privilege 2.Fail-Safe Defaults 3.Economy of Mechanism 4.Complete Mediation 5.Open Design 6.Separation of Privilege 7.Least Common Mechanism 8.Psychological Acceptability
August 1, 2006 User Stories Security needs to be included in development –Constraints –User Stories modeled after Abuse Cases Security needs to be included in completion –Unit tests pass + customer sign off –Static analysis scans clean + risk analysis update.
August 1, 2006 Security Refactoring Software security through refactoring –Replace Insecure API –Add Input Validation –Single Point of Validation Use one iteration for security refactoring –Construct security stories to support goals.
August 1, 2006 Security Tests First Design security tests with unit tests –“Unit hacks” –Fuzz tests Need security knowledge to construct tests –Attackers head immediately for edge cases. –Attack patterns, working with security experts. –Do developers know enough about testing? –Do developers know enough about security?
August 1, 2006 Test Driven Design Coding to tests works well for features. –But security isn’t a feature. –Two features that are secure apart may be insecure when combined. Acceptance tests –Customer may not have security knowledge necessary to evaluate product security. Undocumented assumptions –Code is too low level to express design assumptions –Data flow between components
August 1, 2006 Pair Programming Security training –Pair with a security expert to learn software security. Security code reviews –Use a static analysis tool before checking in code.
August 1, 2006 References 1.Greg Hoglund and Gary McGraw, Exploiting Software: How to Break Code, Addison- Wesley, 2004. 2.Gary McGraw, “XP and Software Security?!”, XP Universe, 2003. 3.Gary McGraw, Software Security, Addison-Wesley, 2006. 4.Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, 2006. 5.OWASP, The OWASP Top 10 Project, http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2006. http://www.owasp.org/index.php/OWASP_Top_Ten_Project 6.OWASP, The OWASP Guide to Building Secure Web Applications, http://www.owasp.org/index.php/OWASP_Guide_Project, 2006. http://www.owasp.org/index.php/OWASP_Guide_Project 7.Paul Saitta, Brenda Larcom, and Michael Eddington, “Trike v.1 Methodology Document [draft],” http://dymaxion.org/trike/, 2005.http://dymaxion.org/trike/ 8.Joel Scambray, Mike Shema, and Caleb Sima, Hacking Web Applications Exposed, 2 nd edition, Addison-Wesley, 2006. 9.Frank Swiderski and Window Snyder, Threat Modeling, Microsoft Press, 2004. 10.John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. 11.VISA, Payment Card Industry Data Security Standard (PCI-DSS), http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_D ata_Security_Standard.pdf