A payroll vendor holds a standing tunnel into your HR database for a nightly sync — where does the trust boundary go?

## The shape of the integration A nightly bidirectional sync with a payroll and benefits provider looks administratively boring and is one of the most privileged paths in a company. Employee personal data flows out; benefit elections, tax data and bank-account details flow back in. The connection is usually a standing tunnel — always up, terminated on both sides, and openable by the vendor's support staff when a customer reports a problem. ## Drawing it honestly A data-flow diagram for this has four things in it: ``` [Payroll vendor] --(nightly sync, both directions)--> || boundary || --> (Sync process) --> [HR database] external entity drawn where traffic (their staff too) enters YOUR systems ``` Two placements are wrong and both are common. The first puts the boundary at the vendor's perimeter, on the reasoning that they terminate the tunnel and have their own controls — that draws their controls as if they were yours. The second omits the boundary altogether because the link is private and encrypted, which quietly promotes the vendor to an internal system. The correct placement is at the point where their traffic becomes your input: a trust boundary marks a change in who controls what is on either side, and control changes hands at your tunnel endpoint, not at theirs. The arrow matters as much as the box. Draw it in **both** directions, because the sync is bidirectional, and label who can initiate it. "Vendor support can open the tunnel on request" turns an automated nightly flow into an interactive one with a human actor, and that belongs on the diagram — otherwise every threat you enumerate assumes a batch job that runs at 02:00 and nothing else. ## What the threats look like per category Using STRIDE against that flow and the store behind it: - **Spoofing** (violates authentication): the tunnel authenticates endpoints, not actors. If the sync service account and the support engineer arrive through the same channel with the same credential, you cannot tell them apart, and neither can your logs. - **Tampering** (violates integrity): the inbound leg writes. Bank-account and tax fields written back into the HR record are the path from a vendor-side compromise to redirected salary payments — money, not just data. - **Repudiation** (violates non-repudiation): if writes land as "the sync user", nobody can later establish which side originated a change. That matters most in exactly the disputes this data creates. - **Information disclosure** (violates confidentiality): the account can typically read every employee row, not the delta it needs. - **Denial of service** (violates availability): a wedged or flooded sync blocks payroll; a deadline-driven process has a real availability requirement. - **Elevation of privilege** (violates authorization): a database credential with schema-wide rights is a standing privilege escalation for anyone who reaches the vendor's side. Notice how many of these come from one design choice — a broad, long-lived, shared credential over an always-open path — rather than from six independent flaws. ## What the model tells you to change The threats above point at a small number of structural moves: - **Narrow the reach.** Replace direct database access with an interface you own that exposes exactly the fields the sync needs, in the direction it needs them. The database is then no longer an element the vendor touches at all, and several threats leave the diagram. - **Split the identities.** Automated sync and human support sessions get different credentials, different paths and different logs, so attribution is possible. - **Make reach on-demand.** A tunnel that exists only during an approved window, with short-lived credentials, converts a standing capability into an event you can see and refuse. - **Constrain the writes.** Treat inbound banking-detail changes as proposals: validate, apply out-of-band confirmation, and reconcile. This is the control that stands between a vendor compromise and payroll fraud. - **Log at your boundary, not theirs.** Records of what crossed have to be produced by a system you run; otherwise your evidence depends on the party you are modeling as potentially compromised. ## The judgment being tested Interviewers use this scenario because it separates people who model networks from people who model trust. The tunnel is a transport decision; the trust boundary is a design statement about who you are relying on. Encryption, a private link, a signed contract and a vendor's certification report all change your confidence, and none of them change where control passes from them to you. Draw the boundary at that point, and the rest of the analysis falls out.