To DFD or not to DFD? 🤔

General
1

Hello again, friends!

The SOTM report shows that diagrams remain central in most threat modeling processes - but their accuracy and purpose vary widely.

So we’re curious:

You (probably) use DFDs, but how do you make them work for you, and not against you (or developers, etc).

This post is part of our new weekly ‘Peer Perspectives’ series! Each week, we’ll explore a new threat modeling topic and open it up for community discussion. For the coming weeks ahead, we’ll discuss key findings from the newly-released State of Threat Modeling Report 2024-2025,

3 Likes
2

As much as I love spaghetti & meatballs I don’t love it when my DFDs look the same. I try to minimise using the DFD for actual analysis of the system (i.e. I don’t require multiple data flows between the same components to be listed) and use it instead to get a good overview and to help spot missing system components e.g. where is the input to this component? does this component talk to anything?

Sequence diagrams are way more useful for analysis.

Usually a mostly accurate diagram is good enough, and much better than having to create a new diagram just for the threat modeling analysis.

1 Like
3

For us, they give a snapshot view of what the system looks like and help us avoid misunderstandings. We have made it a rule always to bring a DFD long to our threat modeling session. Once the threat modeling is over, we keep the DFD for auditing purposes. It helps to have a drawing to remember what you were talking about. We might reuse a drawing if it saves time, but we all know it is a snapshot view.

1 Like
4

We usually take input from solution architects and their diagrams, and enhance them with trust zones (thus still need to draw them from scratch as they use other software for drawing). Output is archived with other parts of security documentation.

1 Like
5

Couple of years ago Matt Coles and I gave a presentation at DF29 AppSec Village called “DFDs Ain’t That Bad” where we explored the reticence some teams have against using DFDs (it’s on the yube, I think).
We divided threat modeling into two separate but obviously linked activities, system modeling and threat elicitation, and we posit that security practitioners are stronger at the later than the former, and developers, the other way around. Developers are constantly informally modeling, but once you call what they are doing part of threat modeling, they get reluctant.

Putting together that DFD leads many times to the “Eureka Moment”, when the assumption is cleared into fact or the hidden issue surfaces because design and implementation diverged. It does improve shared understanding - once everyone is looking at the same diagram and can agree that yes, that thing up there represents the “what are we building” thing in our heads, discussion becomes much easier and clearer.
On the other hand, many teams will see it as extra work or documentation overhead. I have seen teams that absolutely refused to create DFDs, branding them busywork. A lack of an agreed standard (personally we like DFD3) is a further hinderance.

What Matt & I ended saying in the preso is that one should encourage teams to use what they already have: architecture diagrams, pictures of whiteboards, anything - and methodically move towards clearer communication through standardized DFDs. But don’t let “no DFD no TM” be an obstacle. Use tools like pyTM to maintain the DFD as the system evolves - TMaC at its best. Build a library of DFDs to elicit patterns and things to guardrail.

As practitioners we tend to focus a lot on the “what can go wrong” but not so much on the clarity of “what are we building”, many times falling back on the crutch of “all models are wrong but some are useful”. We should try and stop that - if you can’t justify the time to create a model that is as little wrong as possible, you probably got worse problems than not being able to elicit threats.

2 Likes
6

Totally recognize this. Early on, we saw outdated or missing diagrams as one of the biggest blockers — sometimes enough to stop teams from even trying threat modeling because the overhead felt too high.

What helped was reframing the role of diagrams: they don’t need to be perfect artifacts, just good enough to support the security conversation. Two things made the biggest difference for us:

  • Generate them from code so they stay up to date

  • Treat them as living byproducts, not one-off deliverables

At oplane.io, we’ve taken that a step further by automating architecture diagrams from the repo.

(Disclaimer: I’m with Oplane.)

2 Likes