Threat modeling for information and IT system security entered the cyber security 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 more mature analytic fields. The same is true with how applications are visually decomposed. When cybersecurity professionals started threat modeling, they borrowed the concept of data flow diagrams (DFD) from system engineers. The mature application decomposition, developed specifically for threat modeling, is the process flow diagram.
DFDs were 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. 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 does 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 Diagramming (DFD)
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 in an attempt to make them 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, DFDs high levels of documentation were the expected norm. This, of course, makes them unwieldy for Agile sprinting developers who minimize documentation and any other non-productive activity. Without developer acceptance, organizations will find significant challenge scaling threat modeling processes enterprise-wide.
Moreover, DFD-based threat modeling fundamentally looks at how data is designed to move through a system. They cannot inherently analyze, therefore, 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.
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 Diagram (PFD)
By sharp contrast, a process flow diagram is a visual decomposition specifically designed for application threat modeling. Attackers do not analyze data flows. Rather, they map out how a user 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 accessible to the development team.
Building a threat model utilizing a process flow diagram 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; and
- Including the various technical controls – such as a forms, cookies, sessions, or other coding elements that make up the use-case.
Threat models constructed in this way view the application from the perspective of user interactions. This allows easy identification of potential threats and their mitigating controls.
The advantages of utilizing process 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 developer’s ability to sprint to production. This will significantly help the organization in scaling threat modeling processes.
Choosing a Practical Visual Decomposition
DFD-based threat models do not integrate well in a production environment build 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.
Contact us for a free consultation to discuss how a scalable, enterprise-level threat modeling process can benefit your organization.