The document discusses continuous threat modeling and what works. It begins by introducing the speaker and stating the talk will cover level setting on threat modeling, how security is currently done wrong and training is wrong, and how continuous threat modeling can help solve these issues. It then defines threat modeling and discusses how security is currently failing due to lack of threat modeling adoption, training developers, and testing tool limitations. It proposes conducting threat modeling for every story using subject areas, checklists, and maintaining findings to help security become continuous. Tools like PyTM are presented that can help automate and integrate threat modeling into the development process.

1. © 2018 Autodesk, Inc.
(Continuous) Threat Modeling: What Works?
Izar Tarandach
Lead Product Security Architect | @izar_t

2. The Bureau of Made-Up Statistics informs:
No surveys were harmed in the making of this talk. All data is
purely anecdotal and open to subjective interpretation based
on the reader’s experience.

3. About Me
Lead Product Security Architect, Autodesk
Technical Leadership Council, SAFECode
Very Active Kvetcher & Ranter
Izar Tarandach

4. Who are you?
 You don’t know what Threat Modeling
is
 You want to add threat modeling to
your practice
 You threat model every day
 You are in the wrong room and too shy
to leave after three slides into the
presentation
Raise your hand if …

5. What are we doing here today?
 Level setting – threat modeling,
what and why?
 We are securing it wrong!
 We are training people wrong!
 How we can try to solve that –
Continuous Threat Modeling
 How can you use it?
 Tools
 References

6. Threat Modeling – what & why
 A conceptual exercise that aims to
identify security-related flaws in the
design of a system and identify
modifications or activities that will
mitigate those flaws.
 Formally, it can be “A technique to
identify the attacks a system must resist
and the defenses that will bring the
system to a desired state” (Brook
Schoenfield)
 Four Fundamental Questions (Adam
Shostack)
 What are we working on?
 What can go wrong?
 What are we going to do about it?
 Did we do a good job?

7. We are securing it wrong!

8. CVE - Common Vulnerabilities and Exposures
Source:
www.cvedetails.com

9. Development
tools, coding
standards
Automated tools,
pentesting
Playbooks,
security controls
Development Process and Security

10. Where is the secure development process failing?
 Threat modeling still not widely adopted, or not optimally adopted
 Developers not trained but expected to provide security, unlike
 We have training material but little absorption
 Testing tools not up to expectations: noise, false-positives,
 Security controls not sufficient

11. A Day In The Life

12. Alice has a task for Bob: deal with a scan from a
customer

13. Bob … is not amused.

14. The only person that influences the whole
development process
Notable security
events

15. Smart sayings by smart people
”The problem with programmers is
that you can never tell what a
programmer is doing until it is too
late.”
– Seymour Cray

16. We are training people wrong!

17. The ”magic” of security training

18. Hours of CBTs - but that is NOT how people learn!

19. Learning – step-by-step, instructional, theory
Training – repetition, building “muscle memory”
Applying – let it flow in a real life situation
From theory to unconscious competence

20. Learning
Training
Applying
We have the how to do and we have
the what to do, now how do we get
the developers to a point where they
know when they need to do it?
We can’t afford the thousands of
repetitions needed for mastery.
There are no short-cuts. Or are there?

21. (Continuous) Threat Modeling

22. Threat Model Every Story
 build a baseline - involving everyone. Use whatever technique works for your team. At
Autodesk we are currently focusing on a “subject based” list of points of interest
 designate one or more “threat model curators” who will be responsible for maintaining the
canonical threat model document and the findings queue
 instruct your developers to evaluate each one of their stories with focus on security:
 if the story has no “security value”, continue as usual
 if the story generates a security “notable event”, either fix it (and document as a
mitigated finding) or pop it up as a “threat model candidate finding” for the curator to
take notice of (at Autodesk we are doing this using labels on JIRA tickets)
 make sure your curators are on top of the finding and candidate finding queues

23. But…how do my developers know
what has “security value”?
Subject areas
Question and then
continue
questioning during
“official design time”
or when building a
baseline
Checklist
Verify that the
principles have
been followed at
implementation
time

24. Change results by changing approach
“In 2001, nurses at Johns Hopkins Hospital inspired a specialist to develop a
checklist for central line infections. Within a year, the infection rate among
patients in the ICU went from 11% to 0.”
– “The Checklist Manifesto”, Atul Gawande

25. Handbook and Subject areas

26. Principles Checklist

27.  “Uh...what?”
 “This is still too heavy”
 “But how do I know I did everything?”
 “I never saw a room of architects excited about threat modeling
before”
Reactions from product teams

28. Our current findings

29. Caveat Emptor: This Is Not Perfect
 Difficult to convince teams that the Subject List is not a threat library and developers that the
Checklist is not a requirements list – not exhaustive, just a starting point
 The resulting TM won’t be perfect – evolutionary
 A security expert, or security group is still necessary for education
 GIGO – garbage-in, garbage-out

30. So…about that automation thing.
 What are the parts of Threat Modeling we can most easily automate?
 Diagraming - cross-platform, over the network, simple and quick yet representative
 Reporting - having a standard and keeping to it; information passing
 Threat ranking - CVSS or some other agreed ranking system (L/M/H/C, colors)
 Low-hanging fruit - threats that can be immediately derived from a formal description
of the system should emerge
 Tooling should:
 help discuss the system
 keep the model as close as possible to the reality of the system
 disseminate information
 and not hinder collaboration

31. What is available today?
 There are many threat modeling tools; some are platform-dependent, like the MS Tool,
others are web-based
 Some start the process with a questionnaire along the lines of “what do you want to build”
and generate a list of requirements that the developers must follow
 Others get a description of the system and generate threats based on characteristics of the
design
 But … developers write code; why not have them feed the threat model with something that
looks like code?
 “TM-as-code” is in the same place “DevOps” was a couple of years ago. There is talk of,
people want to do it, but the definition of what it actually means is murky

32. Three current practical approaches
ThreatSpec Fraser Scott
@zeroXten
Threat modeling IN
code
ThreatPlaybook Abhay Bhargav
@abhaybargav
Threat modeling
FROM code
PyTM Threat modeling
WITH code

33. PyTM – A Pythonic way of TM’ing
Matt Coles, @coles_matthewj Nick Ozmore, @nozmore
Rohit Shambhuni, @rshambho Izar Tarandach, @izar_t

34. PyTM – Creating a Threat Model

35. PyTM – Elements and Attributes

36. PyTM – Generating a Dataflow Diagram (DFD)

37. PyTM – Sequence Diagrams

38. PyTM – Listing threats

39. PyTM – Report template

40. PyTM – generating reports

41. PyTM – how is it being used?
 during team meetings to create the initial diagram
 in discussions with the product team - “it is missing this attribute”, “why is this a threat”,
“what if?”
 keep threat models in revision control, together with the code they describe and generate
automated, standard threat model reports

42. References
 OWASP Threat Modeling Slack Channel –https://owasp.slack.com #threat-modeling
 OWASP Application Threat Modeling - https://www.owasp.org/index.php/Application_Threat_Modeling
 SAFECode “Tactical Threat Modeling” - https://safecode.org/wp-
content/uploads/2017/05/SAFECode_TM_Whitepaper.pdf
 ThreatSpec - https://threatspec.org/
 ThreatPlaybook -https://we45.gitbook.io/threatplaybook/
 PyTM - https://github.com/izar/pytm

43. Thank you!
 Questions ?
 Don’t forget to leave feedback!

44. Rate today ’s session
Session page on oreillysacon.com/ny O’Reilly Events App

45. Autodesk and the Autodesk logo are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders.
Autodesk reserves the right to alter product and services offerings, and specifications and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document.
© 2018 Autodesk. All rights reserved.