Welcome

Hi there, welcome to our first 2020 edition of Threat Modeling Insider, Happy New Year!

With this newsletter, we deliver guest articles, white papers, curated articles and tips on threat modeling that help you bootstrap or elevate your security knowledge and skills.

Our “TMI” line-up:

• A guest article by Izar “Infosec Curmudgeon” Tarandach covering “How often do living documents need to breathe?” ;
• Curated resources covering an awesome list of threat modeling resources and a blog on the upcoming ISO 21434 cybersecurity standard  for the automotive industry;
• A Toreon trainer reports from the Archimedes conference;
• Tip of the month: creating ‘evil personas’
• Updates on upcoming Toreon training sessions.

Guest article by Izar “Infosec Curmudgeon” Tarandach, Lead Product Security Architect at Autodesk

The idea of a threat model report as a living document is not novel. It has been championed repeatedly and famously by thought leaders in Threat Modeling like Adam Shostack and Brook Schoenfield, and is reflected in many threat modeling methodologies, implicit or explicitly, by their last step: now do it again.

Microsoft introduced the idea of security spikes to address changes in design during Agile development, and many a threat modeling tool is based on the idea of facilitating the expression of on-the-fly changes into a current threat model.

The currently popular fast development and deployment philosophy expressed in DevOps sees systems deployed and redeployed a hundred (if not more) times a day, with small changes moving from inception to customer-facing in record times. This would surely tax even the most flexible threat modeling tool.

But between the “once and done then again” and a “change at the speed of thought” situations there lies a spot that appears to be promising golden, where changes to a system’s design and implementation can be reflected in the threat model in a way that allows reaping the benefits of this conceptual process and yet keep the model reflecting the system as it moves along, while offering the developer a consumable ramping-up in their experience of security as a programming sub-discipline.

The facts are that if we wait many scrums (or any other unit of development cycles) to address change in the threat model, chances are that important and secure-significant details will be lost. On the other hand, of the hundreds of changes a day that are enabled by DevOps only a very small number will be “security notable events” that modify the attack surface, the security posture or the secure configuration of the system.

These events are more effectively identified at the time they are, for the lack of a better word, designed – at the time the architect or developer needs to add or modify the system in a way that changes its security assertions and/or assumptions.  This magic spot is the feature, fix or story.

As Brook Schoenfield so aptly puts in his new book, “Secrets of a Cyber Security Architect”, “Threat modeling doesn’t have to take a long time. As I’ve noted in this book, if an inexperienced team finds just one requirement that significantly improves a security posture, this is a win and should be celebrated as such. This implies that threat models needn’t be the long, exhaustive exercise often promulgated by software security programs. Rather, get developers thinking about credible attack scenarios. Over time, they will likely get better at the analysis, identify more scenarios that apply, and thus identify more security requirements.”. My interpretation of Brook’s experience is that we trust developers with mission critical decisions when they are writing their code, but for some reason we decided that threat modeling is something better left to the experts – looking for the big bang of a complete solution, But if we want incremental, evolutionary answers, we must trust them, give them the tools and more than that give them the understanding of security fundamentals so they can do their own threat modeling or at least identify their own security notable events.

By queueing these events and having that queue addressed in able time by a curator, who ultimately decides what goes into the threat model and what needs to be addressed in documentation, testing procedures or deployment changes, the threat model keeps apace with development. At all times the changes are reflected in the threat model, with less opportunities for lost details and wrong assumptions and at a granularity that actually addresses only possible security flaws rather than every little change in the system.

This is the basis of Continuous Threat Modeling, or “Threat Model Every Story”, a threat model methodology currently deployed at Autodesk and under consideration by a few other companies. The methodology itself and supporting materials have been open sourced and can be found on Autodesk’s Github repository. A talk at OWASP Appsec Cali from 2019 is available at “Threat Model Every Story: Practical Continuous Threat Modeling Work for Your Team“. The methodology is further explored in an upcoming O’Reilly book co-authored by Matthew J. Coles and myself, “Threat Modeling: Risk Identification and Avoidance in Secure Design” (you can find the first 3 chapters pre-released at O’Reilly Safari. We are really looking forward to feedback and opinions from the secure development community and the development community at large on how to improve on the methodology and its implementation.

Izar Tarandach

Awesome Threat Modeling

An awesome curated list of threat modeling resources (Books, courses – free and paid, videos, tools, tutorials and workshops to practice on ) for learning Threat modeling and initial phases of security review. Created by Practical DevSecOps.

ISO/SAE 21434 automotive cybersecurity standard

Due for release in 2020, this is a new cybersecurity engineering standard for the automotive sector. The guidelines consider all phases of a vehicle’s life and their scope includes on-board systems, components, software and connections to external devices & networks. Read a blog covering this from Itemis here.

Conference report by Joris Van den Broeck, consultant at Toreon

This week Joris (one of our threat modeling trainers) attended the Archimedes Medical Device Security 101 Conference in New Orleans. This conference is hosted by the University of Michigan’s Archimedes Center for Medical Device Security, and is a two-day educational workshop for healthcare providers, medical device manufacturers and industry regulators to learn and speak frankly about medical device security threats and solutions.

Here are some highlights with regards to the threat modeling practice for medical device manufacturers:

1. Suzanne Schwartz, director a the FDA, indicated that the second draft of the pre-market guidance will put even more focus on threat modeling than the first draft. The tiering model from the first draft will be removed and the BOM (hardware + software) will become a sBOM – only incorporating the software Bill of Materials. Boot camps will be organized on threat modeling for medical devices as was reported earlier by MDIC.
2.  The push for threat modeling for medical devices was supported by a great talk from Adam Shostack on threat modeling with Star Wars references (Star Wars is all about information disclosure of the battle ship plans!) In addition to an introduction to the threat modeling methodology described in his book (Threat Modeling: Designing for Security), he also discussed 10 threat modeling traps to avoid. He highlighted that there is more than one way to threat model and that there are different tools that can be used based on the context. (DFD, Swim lanes, STRIDE, Attack Trees,.. ). You can see a similar talk from Adam delivered at the IT Security Community Exchange conference in Germany last November on YouTube.
3. In the last talk of the conference, Alexander Kent from Medtronic tied together cyber security risk and patient safety risk. Alexander highlighted the importance of customizing a threat modeling methodology to fit your own industry/organization. When talking about medical devices and scoring risks, the impact on patient safety is of utmost importance.

Tip from Dave Van Stein on the OWASP #threatmodeling Slack channel: I usually create ‘evil personas’ together with the team in the same way you would create normal personas. That way you divide the ‘almighty super villain hacker’ into more relatable attackers, which is easier to most non infosec people. We then link most likely type of attacks to these and start investigating the attack surface and relevant attack possibilities. At a later stage you can deep-dive into details with things like

Want to learn more about Threat Modeling training? Contact us, so we can organize one in your neck of the woods.

We aim to make this a community driven newsletter and welcome your input or feedback. If you have content or pointers for the next edition, please share them with us.

Kind regards,
Sebastien Deleersnyder
CEO, Toreon