1 / 10

XP Security

This article explores how to incorporate security goals into Agile development utilizing extreme programming (XP) principles. It discusses security design principles, SDLC artifacts, security refactoring, security tests, test-driven design, pair programming, and provides references to relevant resources.

jwebber
Download Presentation

XP Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XP Security

  2. XP GOALS User stories No BDUF Refactoring Continuous integration Simplicity SECURITY GOALS Prevention Detection Authentication Integrity Availability Privacy Comparing XP and Security Goals

  3. Security Design Principles • Least Privilege • Fail-Safe Defaults • Economy of Mechanism • Complete Mediation • Open Design • Separation of Privilege • Least Common Mechanism • Psychological Acceptability

  4. SDLC Artifacts

  5. 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.

  6. 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.

  7. 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?

  8. 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

  9. 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.

  10. References • Greg Hoglund and Gary McGraw, Exploiting Software: How to Break Code, Addison-Wesley, 2004. • Gary McGraw, “XP and Software Security?!”, XP Universe, 2003. • Gary McGraw, Software Security, Addison-Wesley, 2006. • Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, 2006. • OWASP, The OWASP Top 10 Project, http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2006. • OWASP, The OWASP Guide to Building Secure Web Applications, http://www.owasp.org/index.php/OWASP_Guide_Project, 2006. • Paul Saitta, Brenda Larcom, and Michael Eddington, “Trike v.1 Methodology Document [draft],” http://dymaxion.org/trike/, 2005. • Joel Scambray, Mike Shema, and Caleb Sima, Hacking Web Applications Exposed, 2nd edition, Addison-Wesley, 2006. • Frank Swiderski and Window Snyder, Threat Modeling, Microsoft Press, 2004. • John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. • VISA, Payment Card Industry Data Security Standard (PCI-DSS), http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf

More Related