Diagrams on tplat

Data Flow Diagrams

Mon, 01 Jan 0001 00:00:00 +0000

Data Flow Diagrams

Data flow models are often the most effective way to perform threat modeling because security issues tend to follow data flow, not control flow. They can be applied to both networked systems and standalone software.

A Data Flow Diagram (DFD) is a structured representation of how data moves through a system. DFDs model:

Processes (running code)
Data stores (where data is held)
Data flows (communication paths)
External entities (outside the system boundary)

flowchart LR
    webClients["Web Clients"]
    sqlClients["SQL Clients"]
    dba["DBA (Human)"]
    dbUsers["DB Users (Human)"]
    logAnalysis["Log Analysis"]

    subgraph dbCluster["DB Cluster"]
        subgraph sqlAccount["Original SQL Account"]
            frontend(["Acme Front End(s)"])
            database(["Database"])
            dbAdmin(["DB Admin"])
        end
        data[("Data")]
        management[("Management")]
        logs[("Logs")]
    end

    webClients <--> frontend
    sqlClients <--> frontend
    frontend <--> database
    database <--> dbAdmin
    dba <--> database
    dba <--> dbAdmin
    dbUsers <--> logAnalysis
    database <--> data
    database <--> management
    database <--> logs
    logs --> logAnalysis
    dba <--> logAnalysis

style dbCluster stroke-dasharray: 5 5
style sqlAccount stroke-dasharray: 5 5

They are especially effective because they:

Unified Modeling Language

Mon, 01 Jan 0001 00:00:00 +0000

Unified Modeling Language

Unified Modeling Language (UML) diagrams can be adapted for threat modeling, especially if they are already part of the development workflow. In this case, you need only add trust boundaries to highlight security-relevant separations between components.

Advantages

Leverages existing artifacts (presuming you are already using UML in your project): No need to redraw system models
Expressive and detailed: UML supports a wide range of diagram types:
- Structure diagrams
- Behavior diagrams
- Interaction diagrams

Limitations

High complexity: UML includes many symbol conventions, requiring strong familiarity to interpet correctly

Swim Lane Diagrams

Mon, 01 Jan 0001 00:00:00 +0000

Swim Lane Diagrams

Swim lane diagrams are a visual method for modeling interactions between participants in a system or protocol. They are particularly useful for understanding message flows over time, or when modelling human + system interaction.

Each participant (e.g., client, server) is represented by a vertical “lane”
Time flows downward along each lane
Messages are shown as horizontal arrows between participants
Each lane is labeled to identify the participant

This layout resembles swimming lanes, hence the name.

State Diagrams

Mon, 01 Jan 0001 00:00:00 +0000

State Diagrams

State diagrams model a system as a set of states and transitions between those states. They are useful for analysing how a system behaves in response to inputs and how it enforces rules over time.

A system is represented as a state machine with:

States (current condition of the system)
Transitions (movement between states)
Inputs/messages that trigger transitions
Internal data/memory influencing behavior

stateDiagram-v2
    [*] --> Closed

    Closed --> Opened: open
    Opened --> Closed: close

    Closed --> Locked: lock
    Locked --> Closed: unlock

From a threat modelling perspective, state diagrams can help to evaluate whether each transition enforces proper validation and security checks, and to identify:

Trust Boundaries

Mon, 01 Jan 0001 00:00:00 +0000

Trust Boundaries

A trust boundary is any point where entities with different privileges or trust levels interact.

Every system has at least one trust boundary because all computation occurs in some context.

If no boundaries are visible:

Either everything is incorrectly assumed to have equal privilege
Or the model is missing structure

In the extreme case where everything truly shares the same trust level, draw one boundary around the entire system and move on.