Information Security: Data Flow Diagrams

Continuing from my last post on STRIDE and threat models, I will discuss Data flow Diagram (DFD) in this post. Data flow Diagrams are useful tools used in threat modeling, that capture system detail and data flow information in common element in a standard format. At a high level, it can be used via  0 GUI for end user while saving the threat model to file system.

Following are the 4 major components of a DFD:

• Process Elements
• Any element that is an active processor of data
• These elements are the focus of DFD
• There must be a sensible breakdown of system processes
• Represented by Single circle
• External Interaction Elements
• These refer to the original points of interaction, and also the final destination
• For Example: valid end users, authenticated 3rd party systems etc
• These interactions can input, read and update (CRUD operations) on data
• While these are similar to Process Elements, these are beyond the control and scope of the system developers
• It is important that the threat model contain summary of the interactions with these,
• A list of security promises made by the elements should also be documented
• The role that each interactor plays must also be captured in the threat model
• Represented by rectangles
• Data Store Elements: Passive Storage
• These elements represent that data is being stored, however, no computation is being performed on it, and hence, no processing happens here
• Represented by horizontal parallel lines (imagine a rectangle with vertical side missing)
• Data Flow Elements
• These elements represent inputs and outputs between different other elements 
• Represented by single directional arrows

Representation of different elements

Apart from the above, following representations are also used based on the complexity at hand:

• Boundaries
• The boundaries represent privilege differentials between different elements where applicable
• A boundary may be of multiple types:
• Process boundary: cross process data flows on same machine
• Machine boundary: cross process data flows across a network
• Trust boundary: Emphasize a privilege in general case
• Other boundary: generic
• Represented by dotted red line
• Multiple Process Element
• Sometimes, in the interest of space and ease of representation, multiple processes may be abstracted at the higher level using this element
• Each multiple process element has a separate DFD
• Each such element represents sub components using multi process elements
• Represented by concentric circles

Any system of sufficient complexity will require multi level DFDs. Due to which, the DFD can become very complex and hard to read. In such cases, context diagrams are used to present information in an easy to understand manner.

Context diagrams are useful to divide systems based on physical realities. For example, the context diagram may be based on major components (rather than high level logical diagram), so that they are  functionally comprehensible. Grouping into logical divisions is helpful in case of multiple ways to divide because of similar realities

Thus overall, a major system can follow the DFD organization as:

Context diagram -> L1 diagram -> L2 diagram and so on at each element

The engineers should ideally continue to decompose the system, till relevant security detail is achieved in order to think of a DFD as complete. For example, for a webapp, it could mean not caring about how the data is stored within your MySQL internals, as long as it reaches the database.