Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
QA or the Highway, profile picture
Uploaded byQA or the Highway
PPTX, PDF301 views

Injecting Threat Modeling into the SDLC by Susan Bradley

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.

Technology◦
Downloaded 14 times
Injecting Threat Modeling into the SDLC Susan Bradley QA or the Highway February 27, 2018
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
Use Case- What Went Wrong?
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?”
What is Threat Modeling? A structured approach that enables you to identify, quantify, and address the security risks associated with an application.
When to Use Threat Modeling  New:  Functionality  Application  Process  Vendor Connection or Existing Functionality  Existing:  Functionality  Application  Process  Vendor Connection or Existing Functionality
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"
The Software Development Lifecycle- Waterfall
The Software Development Lifecycle- Agile
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
Threat Modeling Process  Data Flow Diagram  Understand the system  Identify Threats  Proposed Response: Accept, Avoid, Mitigate, Transfer  Prioritize Mitigation
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
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?
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?
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
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
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?
Ready to Inject Threat Modeling? Requirements Threat Model Design Threat Model Develop Threat Model
Contact Info  https://www.linkedin.com/in/susan-bradley-cste/