DevSecCon London 2017: Threat modeling in a CI environment by Steven Wierckx

1. Join the conversation #DevSecCon
BY STEVEN WIERCKX
THREAT MODELING IN A CI
ENVIRONMENT:
A LIGHTWEIGHT APPROACH TO
WHITEBOARD HACKING

2. Agenda
• TM introduction
• Agile and TM, a problem?
• OWASP Agile TM methodology (STAYPUFT)
• Exercises / examples
• SCRUM
• Kanban
• Summary

3. Steven Wierckx
• 7 years developer experience
• 3 years (technical) testing experience
• 5+ years of information security
experience
• Application security consultant Toreon
• Toreon (www.toreon.com)
• OWASP Threat Model project leader
• Twitter: @ihackforfun

4. You?
• Has threat model experience?
• Works in a CI / Agile environment?

5. SDLC
DESIGN BUILD TEST PRODUCTION
web / mobile applica;on project (acquisi;on / development)
TRAINING
SAMM assistance
Source code review
(sta;c)
Security
tes;ng (dynamic) WAF tuning
Threat modeling
Coding
guidelines Configura;on
guidelines

6. TM introduction
Diagram
• What are we building?
Identify threats
• What can go wrong?
Mitigate
• What are we doing to defend against
threats?
Validate
• Validate steps 1-3, report

7. “Classic” TM
1. Threat Modeler, Business Owner, Application architect
• Doomsday scenario’s
• Context diagram
• DFD diagrams
• Trust boundaries
2. Threat Modeler starts documentation & prepare next workshop
3. Threat Modeler, Business Owner, Application architect
• Perform analysis of trust boundaries
• Find vulnerabilities
• Document all assumptions
• Analyze residual risk
4. Threat Modeler finishes documentation & recommends solutions
5. Threat Modeler, Business Owner, Application architect, Management
• Decide on mitigations

8. Agile and TM, a problem?
• Classic process does not fit fast moving organizations
• Threat models need to be kept up to date
• Threat models are also documentation
• Threat modeling is agile: keep what works, discard everything else
-> A different TM process is needed!

9. OWASP STAYPUFT
• A process that should fit most (all?) agile methodologies
• A process that ensures good TM practices
• Result of the 2017 OWASP London summit
• https://owaspsummit.org/Working-Sessions/Threat-Model/index.html
• https://owaspsummit.org/Working-Sessions/Threat-Model/Lightweight-Threat-Modeling-
Process.html
• Tentative release date: 10th November 2017

10. OWASP STAYPUFT
• Ascertain phase:
• Security information is derived from the functional story information.
• Team is encouraged to draw a high-level diagram of the system for a common talking point.
• A non-granular Context Diagram is created to support the security information.
• Use Cases are defined from the business and security user story information, and are used to
derive abuse cases
• Threats phase:
• The security information from the Ascertain activity is used to select the template from the
Threat Template Library. The Team will know which user story scenario to apply, such as
Client-Server, B2B, Distributed cloud.
• Apply the template threats to the Agile user story.
• Provide a list (& severity) of threats against components. The team will get the basis of this
information from the selected templates.
• Mitigation phase:
• The team analyses the design and threats that were previously discovered.
• The team does a quick subjective analysis on the threats (non-evidence based).
• The team uses existing OWASP countermeasures to mitigate the associated threats.

11. SCRUM
Actions:
1. Sprint planning
2. Daily SCRUM
3. Sprint review & retrospective
Source: wikipedia

12. SCRUM
1. Start the TM, add doomsday scenario’s, create context diagram,
create basic DFD’s, add trust boundaries, write down assumptions
2. Sprint planning
• Agree on scope -> update DFD’s, check trust boundaries and assumptions
• Add security to user stories (on epic normally)
• Create (security) user stories (in backlog)
3. Daily SCRUM
• Notify team of failed assumptions
4. Sprint review & retrospective
• Gather failed assumptions, evaluate impact

13. Kanban
Principles:
1. Visualize Work
2. Limit Work in Process
3. Focus on Flow
4. Continuous Improvement
Source: wikipedia

14. Kanban
1. Start the TM, add doomsday scenario’s, create context diagram,
create basic DFD’s, add trust boundaries, write down assumptions
2. For each story (epic) update DFD’s (if needed), check trust
boundaries and assumptions, add security requirements
3. During acceptance, make sure assumptions were correct and verify
the security requirements
4. Go for standard mitigations that can applied everywhere
• SSL/TLS
• RBAC
• Split application into different smaller ones per role (user vs. administrator)
5. Do a retrospective to eliminate waste & improve the process

15. Summary
• Threat Modeling: the sooner the better, never too late
• Pick what works, discard everything else
• Answer the 4 questions

16. Join the conversation #DevSecCon
Questions?