Assets & Dataflows

An asset with a vague name produces a vague threat. Assets and dataflows are what the AI reads to generate anything specific — the more real detail you give it, the more useful what comes back.

What counts as an asset#

Any component of the system you're modeling: a server, an API, a database, a third-party service, a user, an AI model. Assets feed two things at once — the AI uses them as context for generating threats, and the risk engine uses their properties (is it reachable from the internet, how critical is it, what does it store) to adjust probability.

THREE WAYS TO ADD THEM: an interactive canvas for drag-and-drop design, a form for adding one at a time, or a CSV import for bulk setup.

The detail that actually changes the analysis#

A handful of fields do most of the work:

NAME, TYPE, VERSION, TECHNOLOGIES: specific beats generic — "PostgreSQL 16 — customer accounts" produces a sharper analysis than "database."
TRUST ZONE: internet, DMZ, internal, or restricted — used to catch the moment a dataflow crosses from a less trusted zone into a more trusted one.
CRITICALITY: how much it matters if this component goes down or is compromised — the engine weighs how often that class of asset gets targeted.
DATA CLASSIFICATION AND PII: what kind of data lives here, which also determines which assets LINDDUN evaluates when you run it.
AUTHENTICATION AND PATCH STATUS: what protects access to it, and whether it's current, behind on patches, or past end-of-life — reported honestly, not optimistically.

Dataflows: where the attack surface actually lives#

A dataflow is the connection between two assets — who initiates it, what data it carries, and how it's protected. In a system diagram, dataflows are the arrows, and they matter more than the boxes: an attacker who compromises one component moves through the dataflows to reach the next one.

TRUST BOUNDARY CROSSINGS: the single most important thing a dataflow can flag. A flow that jumps straight from the internet to a restricted zone — skipping every zone in between — is exactly the kind of architecture threat modeling exists to catch.
PROTOCOL, ENCRYPTION, AUTHENTICATION: what the connection runs on, whether it's encrypted in transit, and what proves who's on the other end.

The canvas: assets as nodes, dataflows as the arrows between them. Drag to reposition, connect two nodes to add a flow.

The flags that shape what the AI looks for#

A handful of yes/no properties on each dataflow steer the analysis directly:

ENCRYPTED: unencrypted traffic reads as an open door for interception, regardless of how "internal" the network feels.
CROSSES TRUST BOUNDARY: flags the entry-validation and injection threats that live exactly at that seam.
RATE LIMITED: its absence reads as an opening for brute force and abuse at volume.
INPUT VALIDATED: its absence is where injection threats come from.
AUDIT LOGGED: without it, an incident on this flow would be effectively invisible after the fact.

Getting good results#

A few habits make a disproportionate difference: name things specifically enough that a teammate knows exactly what you mean; always mark what's actually internet-facing — this is one of the highest-impact fields in the whole model; be honest about legacy and end-of-life components instead of marking them current; and document outbound flows to third parties (payment processors, email, analytics), not just the ones coming in. A canvas full of assets with no dataflows between them is a diagram the AI can't really reason about — connect what you add.