Threat Modeling a File Transfer Workflow, Step by Step

"Threat modeling" sounds like something that requires a security team, a methodology certification, and a week of workshops. Strip away the ceremony and it is something much smaller: a structured way of looking at one system and asking, before an attacker does, "where would I break this?" It is a habit of thought, and like most habits of thought, it is learned fastest by doing it once on something real.

That is what this article is: one complete threat modeling pass, performed on the most ordinary system imaginable — a nightly job that sends a file to a business partner. You will draw the flow, mark where trust changes hands, list what can go wrong at each hop, rank the list, and fix the top of it. No tools are required beyond a whiteboard or a sheet of paper, and the whole exercise fits in about ninety minutes. This is part of our File Transfer Threat Modeling series; if you have not read what attackers actually want from your file transfers, it makes a useful warm-up, because knowing the motives makes the "what can go wrong" step much easier.

What Threat Modeling Is — and Isn't

A threat model is a description of a system from an attacker's point of view: what it contains that is worth taking, where it can be touched, and what would happen if each touchable point failed. Building one comes down to answering four plain questions, in order:

1. What are we working on? — describe the system honestly, including the unglamorous parts.
2. What can go wrong? — enumerate threats, hop by hop.
3. What are we going to do about it? — pick fixes for the worst, accept the rest deliberately.
4. Did we do a good job? — revisit when the system changes and see whether reality agreed.

Just as important is what threat modeling is not. It is not penetration testing — nobody attacks anything; you only think. It is not paperwork for its own sake — the output is one page, and its value is the decisions it records. And it is not a prediction of the future — a threat model is a list of possibilities ranked by judgment, and judgment improves with every pass. A junior administrator's first model will miss things. It will still catch the two or three exposures that matter most, which is the entire point.

The Method on One Page

Here is the whole method, in a form you can copy into your notes and reuse on any flow you own:

THREAT MODELING A TRANSFER FLOW — THE SIX STEPS

1. DRAW the flow.
   Every system, folder, hop, and trigger, origin to destination.
   Include credentials: where each one is stored, what it unlocks.

2. MARK the trust boundaries.
   A line wherever control changes hands: your network to the
   internet, your team to another team, you to the partner.

3. LIST what can go wrong at each hop. Six prompts per hop:
   - Could someone PRETEND to be a party here?      (spoofing)
   - Could the file or job be ALTERED here?          (tampering)
   - Could we fail to PROVE what happened here?      (repudiation)
   - Could someone READ what they shouldn't here?    (disclosure)
   - Could this hop be made to FAIL?                 (denial of service)
   - Could access here grant MORE access?            (elevation)

4. RANK each threat: likelihood (1-3) x impact (1-3) = score.

5. FIX from the top of the list.
   Write down, with a name and a date, anything you accept instead.

6. REVISIT when the flow changes — new partner, new protocol,
   new server — or at a scheduled interval, whichever comes first.

The six prompts in step 3 are a translation of STRIDE, a checklist security professionals use so that brainstorming does not depend on inspiration: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. You do not need to memorize the acronym. You need the six questions, asked at every hop, because each one catches a category the others miss.

The Worked Example: A Nightly Partner Job

Our subject is a flow that exists, in some form, in almost every organization. Each night, an ERP system (the software that runs orders and finance) exports a file of the day's orders — call it orders_daily.csv — into a staging folder on an internal file server. At 2 a.m., a scheduled job on a transfer host picks the file up and uploads it over SFTP (file transfer running inside an encrypted SSH session) to the partner's server on the internet. The partner's system imports it into their fulfillment process before the morning shift. The job logs in with a username and password stored in its connection profile. One administrator set it up; it has run untouched for a long time, which is exactly the kind of flow that deserves a modeling pass — the ones nobody looks at are the ones nobody has looked at.

Notice what we just did: described the system plainly, including where the credential lives. That was step 1 beginning already. Honesty in the description is what makes the rest of the exercise work — a threat model of the system as you wish it were protects nobody.

Step 1: Draw the Flow

Draw a box for every system the file touches and an arrow for every movement: ERP server, staging folder, transfer host, partner endpoint. Then add the things that are not files but matter just as much: the schedule that triggers the job, the credential the job uses, and the person who owns it. The drawing rule is simple — if data or authority moves, it gets an arrow; if something can be stolen, it gets written on the diagram. Whether the job pushes or the partner pulls changes the picture too, since it decides who holds credentials to whom; our fundamentals article on push versus pull unpacks that choice.

The diagram below shows the finished drawing for our nightly job, with the trust boundaries from step 2 already marked as dashed vertical lines.

Three boxes, three arrows, one credential, one schedule. If your drawing of a "simple" flow ends up more complicated than this — more hops, more copies, more credentials — that is not a drawing problem. That is the threat model already telling you something.

Step 2: Mark the Trust Boundaries

A trust boundary is any line in the diagram where control changes hands — where the people, machines, or rules on one side are different from the other. Crossing one means your assumptions stop being enforceable. Our nightly job has three:

• Your network to the internet. The obvious one. Inside, you control the switches and the machines; beyond the firewall, anyone can be on the path. Everything crossing this line must assume a hostile audience.
• The internet to the partner's network. You do not run the partner's server, vet their staff, or read their logs. Their security is invisible to you, yet your data lives there after every run. Trust here rests on the agreement between companies, not on anything you can configure.
• The application team to the infrastructure team. The subtle one, and entirely internal: the ERP (run by the application team) hands the file to a staging folder (run by IT). Whoever can write to that folder can inject or alter content that the rest of the flow will faithfully deliver — which makes the folder's permissions part of the flow's security whether anyone planned it or not.

Boundaries earn their place on the diagram because threats cluster at them. Inside a zone, one owner can notice and fix problems; at a boundary, each side assumes the other is doing the checking, and attacks live in the gap between those assumptions.

Step 3: List What Can Go Wrong at Each Hop

Now walk the diagram hop by hop, asking the six prompts at each stop. Do this as a defender cataloging possibilities, not as a how-to — the goal is a list of things to prevent and detect. Here is what the exercise surfaces for our nightly job:

Two observations from doing this honestly. First, the six prompts pull out threats a free-form brainstorm misses — repudiation ("could we prove what was sent?") almost never comes up unprompted, yet it decides whether a future dispute with the partner is a five-minute log lookup or a standoff. Second, most of what surfaced is not exotic. World-writable folders, passwords readable in job configs, unverified host keys, silent failures: ordinary findings, which is exactly why attackers rely on them. The concrete attack techniques behind these prompts — credential guessing, interception, malicious content — are covered defensively in the attacks file transfer services actually see.

Step 4: Rank What You Found

Not everything on the list deserves action, and pretending otherwise guarantees nothing gets done. Score each threat on two axes, each from 1 to 3: likelihood (how plausibly this happens to you — 3 for things automation attempts daily, 1 for things requiring a capable, motivated attacker) and impact (how bad the day is if it happens — 3 for breach-notification territory or serious business harm, 1 for an annoyance). Multiply them. The arithmetic is not science; it is a forcing function that makes you compare threats instead of fearing all of them equally.

For our nightly job, the top of the ranked list comes out like this: the readable stored password scores 6 (likelihood 2 — it requires internal access or a compromised host, but is trivial once there; impact 3 — it is remote impersonation of the flow from anywhere). Silent job failure scores 6 (likelihood 3 — every long-running job eventually fails; impact 2 — missed orders and an unhappy partner). The world-writable staging folder scores 6 (likelihood 2, impact 3 — tampered order data flows straight into the partner's systems under your name). The unverified host key scores 3 (likelihood 1 — interception in the path is genuinely hard; impact 3). The partner-retention question scores 3. Everything else scored lower. A fuller treatment of scoring — including anchoring the scales so two admins produce similar numbers — is in a practical risk assessment for your transfer estate, which applies this same arithmetic across every flow you own.

Step 5: Fix the Top of the List

Fixes for the top three, in order — note how each one is a configuration change, not a purchase:

1. Replace the stored password with a key, and verify the host. Switch the job to SSH key authentication: the private key stays on the transfer host with file permissions only the job's account can read, and it cannot be casually copied out of a config screen the way a password can. At the same time, record the partner's host key fingerprint so the job connects only to the genuine endpoint. Both moves are walked through in our SFTP authentication article, and the wider discipline — inventory, rotation, retirement — in the SSH key management series.
2. Make failure loud. Configure the job to retry transient errors and to alert a human on final failure — a mailbox someone reads, not a log nobody opens. A scheduling tool with built-in retry and error handling, such as Sysax FTP Automation, turns this from scripting work into a checkbox. Then make sure the transfer itself leaves a trail you can query later; that is the subject of our transfer logging and audit series, and it converts the repudiation finding from step 3 into a solved problem.
3. Close the staging folder. Two identities need access: the ERP export account (write) and the transfer job's account (read). Remove everyone else. Directory permission design for exactly this situation is covered in the file server permissions series.

The remaining findings — partner-side retention, the background guessing noise against your own endpoints — get decisions, not silence. Ask the partner what their retention policy is and record the answer; point your inbound endpoints at the lockout and throttling guidance in brute-force protection; and for anything you consciously choose not to fix, write the acceptance down with a name and a date. "We accept X because Y, reviewed by Z" is one sentence, and it is the difference between a decision and an oversight discovered during an incident.

Step 6: Write It Down and Revisit

The final output is one page: the diagram, the threat list with scores, the fixes chosen, the acceptances signed. Store it next to the job's own documentation, because the two decay together. Then set the revisit rule — the model gets reopened when the flow changes (new partner endpoint, protocol change, new server, new data in the file) or at a scheduled interval, whichever comes first. A threat model of the flow as it used to be gives false comfort about the flow as it is; ninety minutes bought this insight, and ten minutes a year keeps it true.

Where to Go from Here

You have now done the whole discipline once: draw, mark, list, rank, fix, revisit. The same six steps work on an inbound partner drop, a web-based upload portal, an internal sync job — anything where data moves. Each pass gets faster, because the prompts become reflex and the fixes become familiar.

From here, the series widens the lens. The attack surface of a file transfer service applies the same thinking to the service as a whole rather than one flow — every port, interface, and stored credential an attacker can touch, including the threats that originate on the trusted side of the boundaries step 2 taught you to notice. And when you are ready to run the ranking across your entire estate instead of one job, the practical risk assessment is the scaled-up version of steps 4 and 5. Model one real flow this week — the one nobody has looked at in years is the right choice.

Frequently Asked Questions