Download as ODP, PPTX
Uploaded bySource Conference
Matthew Coles - Izar Tarandach - Security Toolbox
The document discusses challenges for incorporating security practices into agile development and proposes a "Security Toolbox" to help development teams identify and mitigate security risks through the use of accepted security knowledge bases and guidance mapped to specific architectural elements. The toolbox is intended to minimize "Security Debt" by predicting security issues upfront and providing acceptance tests and estimates to integrate security into sprint planning and product backlogs. An example is provided of how the toolbox could be applied to help three development teams implement a secure online comment system.
More Related Content
Similar to Matthew Coles - Izar Tarandach - Security Toolbox
Matthew Coles - Izar Tarandach - Security Toolbox
- 1. Security Toolbox: ManagingSecurity Risk for Agile Practitioners Matthew Coles & Izar Tarandach RSA, the Security Division of EMC
- 2. Challenges in AgileAgile Development simulated by a classic arcade game
- 3. Defects (”holes”) occurfor many reasons Flood of requirements
- 4.
- 5.
- 6. Challenges in AgileGoal to successfully implement slices of requirements, adapting to changes as they come from the customer Function over Form
- 7. Success criteria definedby Product Owner (channelling the customer)
- 8. Acceptance tests anddesign requirements only as good as team Reliance on subject matter expertise; not always dedicated to the effort
- 9. Traditional Techniques Securityfor Software Development Lifecycle Risk Analysis
- 10.
- 11.
- 12. Security Documentation OnlyRisk Analysis can help avoid security risk Before ”security debt” exists
- 13. But can stillbe too late to avoid costly rework
- 14. Security Debt TechnicalDebt Measure of rework that will be required to address built-in flaws Security Debt Technical Debt which leads to security vulnerabilities
- 15. Our Vision GiveProduct Owners and Agile teams a method to prevent injecting security defects Predict backlog items, acceptance tests, and documentation as architecture is defined
- 16. Enable better workestimation
- 17. Identify and managetechnical debt Give security SMEs a helping hand or give small organizations the benefit of an SME if they don't have one Minimize Security Debt
- 18. Security Toolbox ”Playbook”for security Collection of security knowledge
- 19. Each item associatedto architectural feature Built-in Security Functional elements for security improvement
- 20. Acceptance tests toimplement
- 21.
- 22.
- 23. Priority Hints toProduct Owners and Scrum Masters
- 24. Constructing the ToolboxRequires security knowledge (of course)
Editor's Notes
- #2 Welcome This presentation is presented by Matthew Coles and Izar Tarandach with the EMC Product Security Office. We are presenting a method for identifying and managing security in product development. While our focus today is a result of issues we have observed from teams performing software development in an Agile or iterative lifecycle, this approach may be feasible for more traditional development methods. Ask people why they are at the presentation. Have they done agile before? Are they planning to? Software development team. Scope of work we do at EMC.
- #3 Security engineering is a puzzle game. We thought Tetris actually provided an excellent way to represent Agile development. Tetris presents a number of matching qualities: * The game starts cleanly, and builds upon previous layers, ad nauseum * Components are added according to some pattern, but that pattern is not known to the player * The player must somehow make all the pieces fit together, and must do this more quickly as time progresses * When (not if) mistakes are made, holes are present in the structure being built. These holes represent security defects. The caveat: in the real world, those holes are not visible, unless certain activities are performed.
- #4 In an Agile development model, requirements are collected and components fit together, but unlike in standard development lifecycles (i.e waterfall) the order and priority is vaguely random. This is similar to the selection pattern of components in the game from the previous slide. Success criteria is also a moving target, and requires the Product Owner to successfully interpret customer and stakeholder requirements. Finally, acceptance tests, functional design, and other metrics are only as good as the subject matter experts knowledge. Given the often shortened timeframe between requirement generation and functional product, there is limited time to review possible options to select the most secure option.
- #5 There are of course ways to detect security defects. Risk Analysis – EMC uses a variant of Threat Modeling based on a ”library” tying architecture to threats.
- #6 As more features are added, security debt (and therefore risk) increases, without mitigations. When mitigations happen (fixing threats and bugs, not testing or threat modeling), there is a momentary drop in debt/risk. Until security detection activities like Threat Modeling or Code Analysis is performed, debt/risk is ”potential” rather than ”kinetic”.
- #8 Caveat: Toolbox cannot alone fix security defects, only help you avoid them. Just-in-time guidance, without the promise of 100% completeness.
- #12 .
- #24 Describe how to select based on architecture, and how to choose between generic or specific.
- #25 The architecture of the knowledge base upon which the toolbox is created is a great example of the use of the famed expert systems of years gone by. A team looking for help can perform many different queries upon the same fact database: Given a need for a web server, which instance would give me less work to make secure? Given a vulnerability (at any granularity) what instances are NOT vulnerable? Given a set of constraints, what kind of mitigations will I be considering?