Diagrams and Symbols in Threat Models
How can we think about non-standard symbols in threat modeling diagrams?
At one of our recent training sessions, a student asked, “I’ve seen different ways people create data flow diagrams to answer the question “What are we working on?” Is it possible to use an AWS-specific architecture diagram like, for example, the following one for this purpose?”
One of the reasons to use a data flow diagram is you can use a technique called STRIDE per element to analyze the diagram. (Originally developed by Shawn Hernan at Microsoft).
Since the AWS diagram example shown above doesn’t use these DFD elements, it is challenging to apply STRIDE per element. But, redrawing diagrams can be a lot of work, and it might feel like busy work.
What I suggested, rather than replacing the AWS-specific diagram components with generic DFD3 elements, to group AWS specific DFD components under relevant generic DFD elements categories and annotate those components with relevant DFD3 equivallents, where possible. We could do this for example, in a key that gets inserted in the diagram:
That looks like this when they're combined:
You could do this AWS services categorization and annotation under generic DFD components for a specific data flow diagram, or it could be a small project to cover all services that AWS offers with an outcome that can be used in any project. (We haven't done this.)
Another option would be to create an AWS template for the Microsoft threat modeling tool. A template in this tool defines all the DFD elements that can be used to create a threat model - generic components (external interactor, process, data store, data flow and trust boundary), other application area specific components, grouped under generic ones, and finally, new components that do not fall under generic categories. Using the template editor, you can customize the list of DFD components that are available in the threat model editor when a template is applied during DFD creation. A template also defines threats that tool generates for each threat model. These templates group application area specific components under generic DFD categories and allow to add new area specific threats under STRIDE, as well as other non-STRIDE specific threats.
Threat modeling templates for concrete application areas (Azure Cloud Services and medical devices), developed and contributed to Microsoft, are now distributed as part of Microsoft Threat Modeling tool. The medical device template was done by me and Jonathan Schaaf while at GE Healthcare.
To summarize, we could do a mapping with just the components used in a project, we could do a mapping with everything we use in AWS, or we could build tooling that let us use AWS iconography directly.