Why does a data flow on a threat-modeling DFD need protocol, direction and data class on it?

## The arrow is the cheapest place to lie to yourself Boxes get scrutiny in design reviews. Arrows get drawn last, fast, and unlabelled. But the arrow is where the asset actually travels, where it leaves one operator's control and enters another's, and where the majority of the interesting exposure lives. Three annotations turn a decorative line into an analysable one. ## Protocol: what the channel already does for you Writing the protocol on the flow answers a question you would otherwise assume: does this hop already have confidentiality, integrity and peer authentication, or not? A flow marked as mutually authenticated TLS is a different threat surface from the same arrow carrying an unauthenticated plaintext file transfer, a message on an internal queue with no transport encryption, or a signed webhook over the public internet. The protocol annotation also exposes asymmetries that architecture diagrams smooth over. A hop can be encrypted in transit but terminate at an intermediary that sees plaintext. A file drop can be encrypted at the transport layer while the file itself is readable by anyone with access to the destination directory. Naming the protocol on the arrow is what makes someone ask which of those is true. ## Direction: data movement, not call direction This is the annotation people get backwards. A DFD arrow shows the direction the **data** moves, not the direction the **call** goes. A service reading a file from a bucket initiates the call, but the file flows from the store to the service, so the arrow points at the service. The convention matters because the two directions of an exchange carry different payloads, cross the boundary in different directions, and attract different threats: - Outbound from you: exposure of data you hold. Who can see it, where does it end up, is it more than the receiver needs? - Inbound to you: untrusted input. Who can inject into it, what does your code do with it, what happens if it is malformed or attacker-chosen? That is why a two-way exchange is normally drawn as two arrows rather than one double-headed one. A single bidirectional arrow silently merges an exposure question and an input-validation question into one line that answers neither. ## Data class: what is at stake on this hop The data class is the annotation that lets you prioritise. Write what is genuinely on the wire: session tokens, salary amounts, national identifiers, pupil names, unwatermarked master files, firmware images, aggregate counters. Two arrows between the same two boxes can differ by orders of magnitude in what a compromise costs, and only the data class shows it. It also catches over-collection. A flow annotated as carrying a full employee record when the receiver needs an account number and an amount is a design defect visible on the diagram, before anyone enumerates a single threat. ## A worked example: the monthly payroll run Draw a payroll run as elements. An HR data store holds employee records. A payment-file process reads from it, builds a bank payment file, and drops that file to the bank over an outbound file transfer. Unannotated, this is three shapes and two arrows, and it looks boring. Annotate the edges: | Flow | Direction | Protocol | Data class | | --- | --- | --- | --- | | HR store to payment-file process | store to process | database session over the internal network | full employee records: names, bank details, salary amounts | | Payment-file process to bank | outbound, to a third party | scheduled file transfer over SFTP | payment instructions: account numbers and amounts, signed or not | | Bank to payment-file process | inbound acknowledgement | file fetched from the bank drop | settlement results parsed and trusted by your process | Now the analysis writes itself, and note who the adversary is: not an anonymous internet attacker, but the payroll clerk who is *supposed* to operate this run. The first flow says the process pulls far more of the record than a payment file needs. The second says the money instructions are protected by the transport only, so whether the file itself is signed decides whether an operator who can reach the drop directory can add a line to it. The third says an inbound file from outside is parsed by your code, which is untrusted input arriving on a path nobody thinks of as an input path because the bank is a trusted party. None of that was visible when the arrows were unlabelled. All of it is visible in one table. ## How much annotation is enough Enough that the diagram answers the questions you would otherwise have to ask a person. In practice: protocol and whether it authenticates both ends, direction as separate arrows when the two directions differ, and a data class named in the domain's own words rather than a classification tier nobody can decode. Annotating every arrow with a full schema is waste; annotating none of them is why the diagram gets ignored.