"Threat Model Every Story": Practical Continuous Threat Modeling Work for Your Team

Editor's Notes

• #3: Running for 8 or so months. Results are promising but not enough empirical data yet. not saying one thing is better than another just offering the justification and the initial findings of the experiment
• #4: 8 years at EMC IBM start-up game consulting work
• #5: calibrate comments - need to know who you are
• #6: just a brief agenda
• #7: Ideally, traditionally performed at the design stage. The objective is to generate findings, but may serve as a framework for other stages of the secure software development cycle. Widely agreed to be an activity with high returns on investment: flaw correction, learning and documentation are immediate products, with training, testing and of course development also impacted. The four questions start with understanding, then wondering, then inventing, then measuring.
• #8: As a developer I was all about the results. I just wanted to know which holes I had to plug. As an architect, I focused on coverage. Every single aspect of the system had to be considered to exhaustion, lest something fall between the lines. As a security consultant, it all became about scalability and being able to help the product team as much as possible, hopefully at some point growing security champions and architects that would take over the consulting. It was also about adapting to the rhythm of the team. 
• #10: The issue with STRIDE and STRIDE/element is that they need someone who knows how things can be broken in order to figure out what is potentially possible as a flaw, or they need the use of attack trees that add complexity and weight to the process. As a learning tool they have their value since they lead to discussion of those findings, but they still depend on having someone, a SME, to do that teaching. They are not constrained, but at the same time a lack of structure may leave areas unresolved or unexamined.  They don’t scale well due to the time needed, the knowledge needed, the need for a SME. The threat library is an improvement on needing a SME, as the team looks at issues that have historically been a problem. On the other side, that tends to constrain the team to only those issues, as they look to discharge themselves of the requirement of a threat model, and the exercise becomes a compliance checklist rather than an examination. The issues are very descriptive and lead to over-focus. It scales better than STRIDE, but still needs the SME to explore beyond the library. Having a tailored conversation on each product amounts to a SME-led threat model. It will surely generate the most correct findings, but at the same time it will not scale at all, it will not teach much to the product team, but in small shops it may be the easiest and best way to go The idea of continuously improving a threat model is not new - it has been pushed, for example, by Microsoft for a long time - but it was in a vague sense, that “a threat model should be updated in every sprint” without giving a practical way to do so that didn’t fall foul of the other issues. It assumes that all the resources needed for a “threat modeling spike” are in place and willing to do what’s needed, and that the process is easily reduced to the scope of a sprint.
• #11: The saying that “threat modeling happens at the design stage” used to be fine when we were waterfalling, since you could threat model until you had an acceptable design that would then be implemented. Nowadays with agile methods and emergent designs we don’t have that luxury anymore. Seymour Cray - The problem with programmers is that you can never tell what a programmer is doing until it is too late.
• #12: to the meat of the thing.
• #13: Richard Feynman: Do your own homework. To truly use first principles, don’t rely on experts or previous work. Approach new problems with the mindset of a novice. Truly understand the fundamental data, assumptions and reasoning yourself. Be curious. This is where the education angle comes in. We are training our developers wrong. We are providing huge amounts of information that do not correspond to huge amounts of useability. We are doing the busywork of teaching people how the RSA algorithm works without focusing on the aspects of choosing the right key length, algorithm and secret protection scheme that their system needs. In order to create sensitivity to what “security notable events” are, we at Autodesk are experimenting with providing developers with a checklist that they use as part of the definition of done of their stories. 
• #14: The subject areas are more important than the sample questions.
• #15: This checklist follows a “if this then that” model - the developer only needs to relate to those items that are relevant to the work at hand The language on the “if” side is developer language. There is no need to decipher what the security team intends in order to figure out if something is relevant or not The checklist is limited in length - one double sided printed page should be the limit so ideally it can be printed and kept at hand The “then that” side is not prescriptive. It pushes the developer to search for the information that relates to whatever environment or framework they are using. This is for three reasons - to keep the list short, to make it somewhat open-ended, and to tickle the curiosity innate to most developers. Pointers are given but not “absolute solutions” The checklist is backed by documentation and live support by the security team It is made clear to the developer - once you don’t need the list anymore, throw it away. The list focuses on teaching fundamentals, not formulas.
• #17: If we look at the threat modeling spike in detail what we see is that at the end of the sprint, the same process used to generate the baseline threat model should be again used to update it. The mitigator is that this time only those things that changed will need to be revisited. That is well and fine, but it still doesn’t answer the basic questions: who is responsible for doing the update? the whole team? the owner of the tm who will provide guidance? is a SME available? when will the findings be fixed? is a finding enough to hold back a story? are they automatically addressed in the next sprint?
• #22: Tm-IN-code – threat modeling happens as code is written and mixes with the code, encapsulates the problem with the solution Tm-from-code - deriving previously identified threats from other tools, validating or discovering threats present in code and providing a proper language to talk about these threats Tm-with-code - we use code to express the system to be modeled and derive information about it