Process Flow vs. Data Flow Diagrams for Threat Modeling

Threat modeling for IT system and application security entered the cybersecurity mainstream in the early 2000s. Initially, the discipline borrowed its analytic concepts from other, more mature fields. Threat trees, attacker profiles, and risk-analysis – foundational concepts in modern threat modeling – all had their theoretical beginnings in the analytic fields.

When cybersecurity professionals started threat modeling, they borrowed the concept of data flow diagrams (DFD) from system engineers. The mature application and IT system deconstruction comes from process flow diagrams (PFD) which were developed specifically for cybersecurity threat modeling. The reasoning being, a web application may be visually deconstructed in the same way via process flow diagrams.

DFDs are detailed flowcharts first developed in the early 1970s when applications were created to run on a specific infrastructure. At that time, considering threats to an application separately from the infrastructure would not make sense. 

Platform Independent Apps and Interconnected Systems Called for a New Analytics Approach

Compare that to today’s interconnected cyber ecosystem, in which applications are developed to be platform independent, and particular threats exist because of the interactions between applications and shared infrastructure components. Today’s production and operational environments are entirely different from the situation which gave rise to DFDs as a useful analytic tool.

Not only do DFD-based threat modeling methodologies tend to insert layers of non-productive workload to an otherwise Agile development methodology, but the output of such threat models tends to be opaque to all but subject matter experts. Because DFD-based threat models cannot provide developer-level details about the application under development, they miss relevant threats and fail to provide the necessary mitigating controls.

As threat modeling evolved as a discipline in its own right and organizations realize the need for scaling threat modeling across their entire application portfolio, it is not surprising that DFDs are giving way to the more sophisticated concept of process flow diagrams.

Data Flow Diagrams

Source: OWASP

System engineers developed data flow diagrams to provide a high-level visualization of how an application works within a system to move, store and manipulate data. The intended use of DFDs was to provide engineers a way of efficiently communicating their structured system analysis. Security professionals added the concept of trust boundaries to DFDs in the early 2000s to make them more applicable for threat modeling.

Since then many attempts have been put forward by various groups to create a more mature DFD-based process, especially for development environments employing an Agile methodology. Despite the valiant and prolonged effort, DFDs fundamentally remain a means of communicating analysis of a structured system. Hence they have limited capacity to adequately address applications which are created for platform independence and deployed in a highly interconnected environment.

Furthermore, with DFDs, high volumes of documentation were the expected norm. This, of course, makes them unwieldy for Agile sprinting developers who minimize documentation and any other activity they deem non-productive. Without developer acceptance, organizations will find significant challenge scaling threat modeling processes enterprise-wide.

DFD-based threat modeling fundamentally looks at how data is designed to move through a system. The approach cannot, therefore, provide a means to inherently analyze how an application appears to a potential attacker. Since a DFD cannot analyze an application from the perspective of an attacker, any predictive capacity regarding possible attack vectors, entry points, or exfiltration points, requires significant speculation on the part of the user.

As applied to threat modeling, DFDs are typically used to identify broad categories – usually based on the STRIDE threat classification scheme – of potential threats such as elevation of privilege or Distributed Denial of Service. The list of threats identifiable through such methods is rather limited and provides a poor starting point for producing actionable outputs.

DFD-based threat modeling leaves a threat modeling practice with fundamental weaknesses:

• DFDs do not accurately represent the design and flow of an application

• They analyze the operational component and how the data is flowing, rather than on how users interact and move through the application features;

• Data flow diagrams are hard to understand because they require security expertise. The developer community does not embrace DVD-based threat models because they are vague, and complex

• DFD-based threat modeling has no standard approach – different people tend to create different threat models with entirely different outputs

• The DFD process is fundamentally focused on very high-level system issues. It cannot, therefore, to help developers understand the relevant threats and their mitigating controls

Process Flow Diagrams

Process Flow Diagram of an online banking application

By sharp contrast, process flow diagrams provide a visual decomposition specifically designed for illustrating how attackers think. Attackers do not analyze data flows. Rather, they map out how they can move through the various application use-cases. 

Their analysis concentrates on how to abuse ordinary use-cases to access assets or other targeted goals. The correct analysis tool, then, must also map out the application use case processes. Not only does this make abuse-case analysis more practical, but it also makes the threat model outputs much more actionable and accessible to the development team.

Building a threat model utilizing process flow charts involves:

• Displaying the application’s use cases – such as Login, Funds Transfer or Shopping Cart
• Defining the communication protocols by which individuals move between use cases
• Including the various technical controls – such as forms, cookies, sessions, or other coding elements that make up the use-case

Threat models constructed from process flow diagrams view the applications from the perspective of user interactions. This allows easy identification of potential threats and their mitigating controls.

The advantages of utilizing process, or application flow diagrams:

• Creating threat models with developer-level application details of communication protocols and employed coding elements intrinsically included allowing more efficiency identifying potential threats;
• Creation of a “process map,” showing how individuals move through an application. Security professionals and developers can then view the application from the attacker’s vantage, resulting in more efficiently prioritizing potential threats;
• An easy to understand threat model that promotes collaboration across all organizational stakeholders, regardless of an individual’s level of security expertise;
• Standardization of the threat modeling process resulting in consistent, actionable output regardless of who created the threat model.

Process flow diagrams are the result of a maturing threat modeling discipline. They genuinely allow incorporation of developers in the threat modeling process during the application design phase. This helps developers working within an Agile development methodology initially write secure code. The threat modeling initiative then becomes a means of enhancing the developer’s ability to sprint to production. This will significantly help the organization in scaling threat modeling processes.

Choosing a Practical Threat Model Diagram Approach

DFD-based threat models do not integrate well in a production environment built around an Agile methodology. They require non-productive layers of work which sprinting developers tend to minimize. Process flow diagrams, by contrast, are very similar to the way developers map out the coding process. By creating a “process map,” developers and security professionals can work intimately with a threat model that gives each team the concrete, consistent, actionable outputs needed throughout the SDLC initiative. Process flow diagrams are the natural result of a maturing threat modeling discipline. With this new approach, organizations can now focus on scaling threat modeling as opposed to hiring an army of security experts.

Learn more about how ThreatModeler™ can help your organization build a scalable threat modeling process, book a demo to speak to a ThreatModeler expert today.

Common FAQ’s About Process & Data Flow Diagrams: