Injecting Threat Modeling into the SDLC by Susan Bradley
Download as PPTX, PDF1 like285 views
The document discusses injecting threat modeling into the software development lifecycle (SDLC). It provides examples of security issues that could have been prevented with threat modeling, such as the Equifax data breach. Threat modeling is a structured approach to identify, quantify, and address security risks. It should be used during requirements, design, and development phases of both new and existing functionality. The process involves data flow diagrams, identifying threats and proposed responses, prioritizing mitigations, and using techniques like STRIDE. Threat modeling sessions should gather documentation and cross-functional teams to holistically understand risks. Identified risks are then evaluated and prioritized to determine how to handle each risk.
Injecting Threat Modeling into the SDLC by Susan Bradley
- 1. Injecting Threat Modeling into the SDLC Susan Bradley QA or the Highway February 27, 2018
- 2. About Me • Mom • Young Adult Mystery Writer • Certified in Risk & Information Security Controls (CRISC) • Certified Software Test Engineer (CSTE) • Certified Six Sigma Black Belt (CSSBB) • Certified Associate Business Continuity Professional (ABCP) • Quality Assurance 20+ Years • Lean Management 5 Years
- 3. Use Case- What Went Wrong?
- 4. Let’s Break it Down • Equifax Data Breach: Patch wasn’t applied, was it identified as a risk, did risk have an owner? Is there a process for applying patches? Millions of people impacted. • NASA Mars Orbiter Lost: Was the process reviewed from start to finish? When looking at the process, did someone ask, “Hey, are we using the metric or English system?”. Costly, and could have been be deadly. • High Sierra: Enter User Name: Root, No password necessary. Security flaws don’t instill customer confidence • Hawaii Emergency Alert: Live vs. Test Alert was sent. Incited panic. “Wow, the live alert looks too similar to the test alert-maybe we should change that?”
- 5. What is Threat Modeling? A structured approach that enables you to identify, quantify, and address the security risks associated with an application.
- 6. When to Use Threat Modeling New: Functionality Application Process Vendor Connection or Existing Functionality Existing: Functionality Application Process Vendor Connection or Existing Functionality
- 7. You’ve already done Threat Modeling “When we think ahead of what could go wrong, weigh the risks, and act accordingly, we are "threat modeling"
- 8. The Software Development Lifecycle- Waterfall
- 9. The Software Development Lifecycle- Agile
- 10. Why Inject Threat Modeling? Mitigate what keeps you up at night How are we going to handle …? Find risks before your customer or a hacker does? Build in quality Build company’s reputation Protect your customer’s data
- 11. Threat Modeling Process Data Flow Diagram Understand the system Identify Threats Proposed Response: Accept, Avoid, Mitigate, Transfer Prioritize Mitigation
- 12. Typical Threat Modeling Session: Gather documentation Gather your team-it's not a solo endeavor Understand your business & technical goals Agree on meeting date(s) and time(s) Plan on 1-2 hour focused sessions at a time Be honest about what is there-it's all about discovery, no blaming or egos *It's a living process to be revisited when major changes occur
- 13. Threat Modeling: Requirements Phase What are the log-in authentications? Do we have standards? How will we handle errors? How will we handle data? Who would want to do us harm?
- 14. Threat Modeling: Design Goal: Decompose the Application. Look at process end-to-end Where are the threats? Are we adding vulnerabilities by integrating with system X? What are my interactions with external entities?
- 15. Threat Modeling: Development Goal: Build in Prevention What are the threats? How can an attacker bypass? What can go wrong with database files? Use STRIDE Method
- 16. STRIDE Spoofing-Assume identity of client, server, or request Tampering-Alter Contents of request of response Repudiation-Insufficient auditing or record keeping Information Disclosure-Unauthorized release of data Denial of Service-Service not available to authorized users Elevation of Privilege-Bypass authorization system
- 17. What to do with the Identified? Determine the potential impact How likely is it to occur? What is the risk = likelihood x impact How do we want to handle the risk? What is the priority?
- 18. Ready to Inject Threat Modeling? Requirements Threat Model Design Threat Model Develop Threat Model
Editor's Notes
- #4: To understand threat modeling, you have to understand the threats
- #5: Outline threat in each example
- #8: What is the damage potential, affected users, and
- #16: Microsoft DREAD method: For Damage: How big would the damage be if the attack succeeded? For Reproducibility: How easy is it to reproduce an attack to work? For Exploitability: How much time, effort, and expertise is needed to exploit the threat? For Affected Users: If a threat were exploited, what percentage of users would be affected? For Discoverability: How easy is it for an attacker to discover this threat?
- #17: Open Web Application Security Project-OWASP