1 / 23

Reduce Security Risk in Your Development

Reduce Security Risk in Your Development. Part II: Creating an Agile SSDLC. Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA. What We’ll Cover Today. How is secure Agile development different? Creating a User Story with integrated security Security Tasks and Testing Managing security Defects

marli
Download Presentation

Reduce Security Risk in Your Development

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. Reduce Security Risk in Your Development Part II: Creating an Agile SSDLC Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA #SecureDev

  2. What We’ll Cover Today • How is secure Agile development different? • Creating a User Story with integrated security • Security Tasks and Testing • Managing security Defects • Security architecture • Agile Threat Map #SecureDev

  3. Quick Recap of Session 1 • Information security overview • What are the most common threats? • How to protect sensitive data, both from a methodology and technology standpoint • Standards and tools • NIST SP 800-53A, OpenSAMM, OWASP

  4. How is Secure Agile Development Different? Traditional / Waterfall Agile Security Timing • Distinct security-focused project phases, often at beginning and end of project • Security skills brought in from outside project, often disconnected from dev/test resources • Specific security testing phase, often at end of project. • Every iteration considers security, but is not limited by it. • Every team member is responsible for security. Security skills are embedded in the team. • Hybrid security and functionality testing, throughout project. Security Resources Security Validation

  5. Secure Agile DevelopmentGuiding Principles • Product value improves with security. • Security is integral to the product, not an afterthought. • Outside security resources (standards, threats, experts) provide background, not a cage.

  6. Agile security myths - 1 • Myth: I’m a developer / product owner / scrum master. Security is someone else’s job. • Reality: The complex threats facing applications today requires everyone to be thinking about security. • Secure business logic • Secure coding practices • Secure test methods • Secure data architecture • Secure deployment environment

  7. Agile security myths - 2 • Myth: Compliance with an Information Security Standard isn’t Agile • Reality: Compliance with an Information Security Standard, such as NIST SP 800-53A, is actually easier in an Agile environment, because “baking in” security in smaller pieces allows for simple compliance test cases and less backtracking

  8. Secure User Stories • The #1 tenet of secure Agile development is to “bake” security into every user story • Remember: Stories should be defined such that the lowest level child story can be implemented and accepted in a single iteration • Any security component(s) of the story, therefore, must be lightweight • What is the most basic security functionality required for the story to be compliant? • Don’t let security define the user story. Let the user story define the security.

  9. Great, Secure User Stories(from Write a Great User Story, by Ronica Roth)

  10. VIDEO DEMO 1 • VIDEO DEMO – Creating a great user story with security elements included in Acceptance Criteria and Definition of Done

  11. Secure User Story DON’Ts • DON’T change the user story template “As a <user type>, I want to <function> so that <benefit>” NOT “As a <user type>, I want to <function> so that <benefit> and <yaddayaddayadda security drivel here>” • DON’T create “Security Epics” • DON’T assign secure user story creation to “the security guy/gal” • DON’T put technical security tasks in the user story itself.

  12. Security Tasks • For each user story, the Developer should create tasks necessary to meet security acceptance criteria • Developer should also detail any security testing tasks, as part of defining all the testing tasks for the story • Security review may also be added as a task, assigned to a security specialist

  13. VIDEO DEMO 2 • VIDEO DEMO – Adding security related tasks and testing to a user story

  14. Security Defects • Security defects may be identified • As part of iteration testing • After product deployment • Tagging security defects makes them easier to identify and prioritize • Once defined, security defects are managed along with other defects as part of iteration acceptance and scheduling

  15. VIDEO DEMO 3 • VIDEO DEMO – Security defect management

  16. Security Architecture From The Principles of Agile Architecture by Alex Yakyma and Dean Leffingwell, with contributions from Ryan Martens and Mauricio Zamora

  17. Security Architecture [..] in the context of secure Agile enterprise software systems, we need both: fast, local control of emergent design so that teams react appropriately to changing security requirements without excessive attempts to futurerisk proof the system, and global control of Intentional Architecture, the guidance needed to assure that the system as a whole has conceptual integrity and efficacysecurity. Achieving the right balance of emergent design and intentional architecture drives effectivesecure evolution of the system [..] From The Principles of Agile Architecture by Alex Yakyma and Dean Leffingwell, with contributions from Ryan Martens and Mauricio Zamora

  18. Agile Threat Mapping • Assessment of key threats to business value, process, or data set • Tied to real-world, known threats – not “theoretical” • Communicated to all team members • Completed by team, not by “security guy/gal”

  19. Agile Threat Mapping Template <Business Value>or<Business Process> or <Data Set> <Business Value>or<Business Process> or <Data Set> <Business Value>or<Business Process> or <Data Set> <Business Value>or<Business Process> or <Data Set> • Confidentiality: (High, Med, Low) • Integrity: (High, Med, Low) • Availability: (High, Med, Low) • Confidentiality: (High, Med, Low) • Integrity: (High, Med, Low) • Availability: (High, Med, Low) • Confidentiality: (High, Med, Low) • Integrity: (High, Med, Low) • Availability: (High, Med, Low) • Confidentiality: (High, Med, Low) • Integrity: (High, Med, Low) • Availability: (High, Med, Low) • A1 – Injection • A3 – Cross-site Scripting • A6 – Sensitive Data Exposure • A1 – Injection • A3 – Cross-site Scripting • A6 – Sensitive Data Exposure • A1 – Injection • A3 – Cross-site Scripting • A6 – Sensitive Data Exposure • A1 – Injection • A3 – Cross-site Scripting • A6 – Sensitive Data Exposure

  20. Checking Our Work

  21. Questions? Contact me: trent@appliedtrust.com Twitter: @trenthein #SecureDev

  22. Up Next:Agile Secure Code Review July 24th | 10am ET Trent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA #SecureDev

  23. Go Agile. Go Rally. #SecureDev

More Related