Achieving DevSecOps — Part 3.5: Data Flow Diagrams
A good Threat modeling exercise needs ‘Data Flow diagrams’, they graphically represent every major part of the system. The elements and their interactions in threat modeling help identify threats and reduce system risk.
A Data flow diagram shows how data is created, manipulated, stored, and removed from your system, this is usefull to recognize threats and improve the system itself.
A Process flow diagrams on the other hand is used to understand the possible though process of an attacker and the they can abuse the application flow.
The choice of the type of diagram depends on the requirement.
On that though let's talk a bit more about data flow diagrams.
It consists of shapes and arrows as described below.
Let's talk about the elements a bit more,
- Process — The task element: It is an activity that works with data, changes it, or moves it but definitely works with it. It is mostly between data stores or in communication.
It is important to put the process in perspective with context, permission, and access along with the depth of details that it represents.
An example could be an input validation code. - Data store — The storage element: This is something that stores data temporarily or permanently, a good example can be a browser cache.
Data stores and external entities start the data flow, so verify you have either one in place.
These can be put in perspective with their type, use, access types, and any other controls. - External entity — The no control element: This can be anything outside the application construct, it can even be a complete system in itself.
An example would be a third-party API that the application uses. - Data-flow — The data in transit element: This element is used to represent data movement and its direction, included mostly between elements during their interaction.
This is put in perspective with some description, protocol used, flow sequence, data type, authentication, and authorization. - Trust boundary — The trust zone change element: Trust boundaries are used as an extension of classical data flow diagrams for threat modeling, and represent the change of trust levels as the data flow through the application. They intersect data flows and indicate attack surfaces where an attacker can interject: machine boundaries, privilege boundaries and integrity boundaries are some examples of trust boundaries.
A trust boundary is separating parts in the diagram that have different levels of trust. These parts present opportunities for attackers.
An example could be transferring data from an unencrypted to an encrypted connection.
Microsoft recommends the diagrams be layered such that they preserve relevance without going overboard but also present relevant context for the depth of the layer in the discussion.
Diagram layers and Depth
These layers serve important functions and give way to different levels of assessment for the application.
Depth 0 is a high-level overview done mostly for every application,
Depth 1 starts focussing on various processes and how they handle sensitive data but is still not too details.
For simple systems Depth 0 and Depth 1 are required.
Depth 2 focuses on a sub-section of a system and how it handles data flow. If the process takes up high risks then these are important to determine and threats that are accompanied.
Depth 3 is a low-level layer diagram, these are used for highly critical systems that are designed at kernal level and so they zoom in to great details into parts that make up those subsystems.
Diagrams should be relevant for discussion, not every system needs a Depth 3 diagram.
Context definition should be decided early in threat modeling so that the right level of context is generated according to requirements and expectations.
Microsoft Threat Modeling Tool
The Threat Modeling Tool (download link) is an industry-recognized threat modeling tool that can be used to create Data Flow diagrams to apply S.T.R.I.D.E. strategy afterwards.
It provides customizable templates along with a threat-generation enginefor threats and risk-reduction strategies
The tool only looks at individual elements and single interactions, NOT the complete diagram to generate threats
A visual tour of the tool
The tool opens with a home screen that gives you options to eith create/edit a model or create/edit a template.
Before i move forward, a template is the collection of assets and the threats pre defined based on a framework (S.T.R.I.D.E. in this case). The threats are associated with certain conditions and are generated when those conditions are satisfied by the assets/asset interactions
The tool gives pre defined templates and one of those is an Azure template which has assets hat align with Azure resources and can be used to diagram projects built on Azure.
Each model gives 2 views
- Design View: Used to design a data flow diagram of the project
- Analysis view: Used to generate a S.T.R.I.D.E. based threat list for the data flow diagram created in design phase.
Design view demostrated here with a level 0 data flow diagram for a file sharing application, the picture labels stencil, elements and the canvas.
Remember, every asset has numerous properties that can be used to cutomize the assets for specific project.
Analysis view demostrated in this picture shows how the tool generates threats automatically based on the data flow diagram provided.
When a listed threat is selected from the threat list, it also highlights the asset that is affected by that threat.
The threat list is catagorized based on S.T.R.I.D.E. framework
In case the predefined templates do not suffice, it is possible to create a brand new template from scratch or edit an existing template to add or delete elements like assets or threats.
The picture below shows the edit of the default template. It shows that the edit screen has the template divided into sections (at the bottom os the picture dipicted as tabs) like stencils and threat types etc.
Each section gives more options to customize
The selected section is Stencils used to add assets and asset catagories along with their associated properties and constraits.
The next picture shows Threat Type section which is responsible to add or remove threat definition and the conditions that render them.
The section Threat Properties highlighted in the next picture gives options to add properties that compliment each threat and give them a lifecycle as shown in the analysis view image.
These tools and techniques help creating safe architecture even before coding.
Resources: