Join the conversation #DevSecCon

BY STEVEN WIERCKX

THREAT MODELING IN A CI ENVIRONMENT: A LIGHTWEIGHT APPROACH TO WHITEBOARD HACKING

Agenda

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

• Summary

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

You?

•  Has threat model experience?

•  Works in a CI / Agile environment?

SDLC

DESIGN BUILD TEST PRODUCTION

web/mobileapplica;onproject(acquisi;on/development)

TRAINING

SAMMassistance

Sourcecodereview(sta;c)

Securitytes;ng(dynamic) WAFtuning

Threatmodeling

Codingguidelines Configura;on

guidelines

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

“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

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!

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

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.

SCRUM

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

Source:wikipedia

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

Kanban

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

Source:wikipedia

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

Summary

•  Threat Modeling: the sooner the better, never too late

•  Pick what works, discard everything else

•  Answer the 4 questions

Join the conversation #DevSecCon

Questions?