TMI newsletter 10 Scaling Up Threat Modeling


Hi there, welcome to our next edition of Threat Modeling Insider.

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:

Scaling up threat modeling

Guest article by Mikko Saario, Security Architect at KONE

Threat modeling is a great way to identify potential security threats against a solution. There are many well-known methodologies used, ranging from STRIDE to the simple whiteboard-based data flow analysis. Each one of these definitely has their own strengths and weaknesses. However, it can be quite burdensome to perform analysis when you must support multiple teams that could be distributed all over the world. If the developers are not that used to modeling threats, they will need facilitation to be effective.

Not all security teams scale up to this level of involvement. To run a session effectively, you need to have someone driving and facilitating the discussion and perhaps another to document the discussion results (could of course be the same person, but this can be quite distracting). The facilitator needs to ensure participants are able to think about relevant threats and risks, and should also possess enough technical skill to understand what is feasible and what really isn’t in a given scenario.

Many companies face a shortage of either security competence or resources, and often both. Even if you had a good-sized budget, it might not make sense to just hire more hands, but to approach the challenge from a different angle: How do you do it more efficiently while not sacrificing quality? Don’t take this as a silver bullet, but in cases where you have limited security competence or resources available, perhaps one could automate part of the process? Over several years I have been using tools to help us to manage most of our threat assessments and subsequent requirements’ definition. Forget (most) of your checklists and introduce a workflow instead that basically walks the team through their scenario and as the output provides them with relevant security and privacy requirements. These would be pushed into their own e.g. JIRA project covering typical threat scenarios for the given application.

Gartner calls this approach with a less-catchy acronym: ASTRM (Application Security Risk Threat Management). I just call it another way of doing threat modeling and analysis.

Let’s take a brief look at a few different alternatives available in the market.


goSDL is a simple PHP-based app that allows you to customize a questionnaire which would then select appropriate requirements and push them into a JIRA project or Trello board. It does the trick if you’re ready to get down to the code and JSON configuration yourself but would maybe come a bit burdensome over time to maintain. A good, free alternative to try out the workflow and suitability of the idea.


I have used two commercial applications for a number of years managing most threat modeling cases and all the security requirements, namely SD Elements (SDE) and IriusRisk. SDE is the flagship product in this area, it is most versatile and allows a wide range of customizations. Due to the licensing model, it is best suited for medium to large-size corporations, while IriusRisk could be used by almost any size company. In my experience, when using these apps, they require constant management to maintain and improve the contents and the workflow.

I have tried to get a brain dump of the technical security people and import this knowledge in a consumable format either directly into the tool or alternatively to an internal wiki page linked by the tasks provided by the tool. Out of the box content is always usable, but very generic and I like to include the internal corporate language in the tasks provided to development teams, including things like standard libraries and solutions in use (e.g. for authentication and logging, or perhaps specific SDKs). A quick session with the team would define the app and provide tasks accordingly. A task can be anything that is deemed suitable, but always must be clear, specific and actionable.

What these tools do require, as mentioned, is constant attention. In order to keep the workflow smooth and covering common scenarios in your environment, I continuously fine-tuned the questionnaire, rules and requirements. Over time you can shift the security teams focus from running from one meeting to another, to focusing more on building better tools and integrations in addition to spending more “quality time” with fewer critical areas or components.

Both of these tools currently provide either a restricted feature license (SDE) or limited free license (IriusRisk). They could work in some situations, but to me both of these did not give what we needed in our corporate environment. goSDL could also be somewhat limited and support-heavy to a good solution for larger corporations.


ASTRM tools also provide a good compliance view automatically. As teams address their tasks, the status is automatically reflected back to the tool, or some external reporting system consuming data from the system. In this, compliance also refers to complying with detailed technical requirements, and not some vague high-level requirements often used by corporate security teams.


As an additional bonus, one can address and track privacy aspects as well. We have had tasks that both required the team to perform a general GDPR privacy assessment and also implement key technical privacy controls. Simple examples included mandatory notices and links to privacy policies, and not only traditional technical security aspects such as data encryption.

Mikko Saario

Curated threat modeling content

BIML Machine Learning Risk Framework

Another great analysis of new threat modeling content from Adam Shostack.

The Berryville Institute of Machine Learning (BIML) has released “An Architectural Risk Analysis of Machine Learning Systems.”, addressing what can go wrong in a list of 78 specific risks, organized into both a top ten list and risks to each of the 9 components of their system.

OWASP Threat Dragon 1.2 released

OWASP Threat Dragon is an open source threat modeling tool – still in full development – supporting system diagramming and a rule engine to automatically determine and rank security threats, suggest mitigations, and implement countermeasures. The newly launched desktop version is based on Electron. There are installers available for both Windows and macOS, as well as RPM and Debian packages for Linux.

Medical Device Threat Modeling white paper

Together with peers from the medical device industry James Leone, Axel Wirth and Vidya Murthy our Toreon colleague Thomas Heyman created a white paper on “Medical Device Threat Modeling”, as a reaction to the upcoming FDA regulation that requires ‘security by design’ for Medical Device manufacturers.

Want to know more?

Start typing and press Enter to search

Shopping Cart