Inheriting a Partner's Posture

## What the tunnel actually authenticates A site-to-site tunnel — IPsec with ESP, or any of the modern equivalents — establishes a mutually authenticated, encrypted association between **two gateway devices**. Authentication happens once, between those devices, using a pre-shared key or a certificate. Once the association is up, every packet the far gateway encapsulates is accepted as authentic, because it was: the *gateway* really did send it. That is the whole claim. It is a claim about a box. It is not a claim about the laptop, the jump host, the build server or the contractor sitting behind that box. Read the direction of the claim carefully, because this is the misconception the question exists to break: **an authenticated tunnel proves the peer device holds the key, not that the traffic inside it is legitimate.** ## What arrives after decryption At your terminator the outer header is stripped and what falls out is an ordinary IP packet with an inner source and destination. From that moment on it is indistinguishable from any other packet on your network except by where you chose to put it. If it lands in a zone whose policy was written on go-live day as a permit for the whole partner range to the whole data centre — which is how these get built under a deadline — then the intruder inside the partner has exactly the reach that policy grants. This is why the tunnel is an inheritance. You did not assess that estate, you cannot audit it, and you will not be told about a compromise until they choose to tell you. Their patching, their remote-access hygiene, their own suppliers: all of it now sits one decryption away from your extranet zone. ## The control you own versus the control you have a PDF about The questionnaire the partner returned says they run a firewall, segment their network and log access. Assume every word is true. It is still not a control you can exercise: you cannot read the rule base, you cannot see whether an exception was added last quarter, and you cannot revoke it. In a third-party arrangement the only enforcement you can rely on is enforcement you operate. So the defensive posture is: - terminate partner tunnels into a **dedicated extranet zone**, never straight into a general internal zone; - **default-deny** out of that zone, permitting only enumerated destination addresses and ports in the required direction; - filter **inbound source addresses** as well, so the tunnel can only present the source ranges you agreed, not arbitrary ones; - log the permits, so you have a record of what the relationship actually used rather than what it was scoped for. ## What the filter costs This is the part candidates skip, and it is the reason such filters end up permissive. To write a default-deny policy for a partner you must enumerate flows that nobody documented: which of your hosts the supplier's engineers actually reach, on which ports, in which direction, and which of those are batch jobs that only run at quarter end. Nobody in the room knows. So the shortcuts appear — a broad permit for the whole partner range, a permit to a whole subnet rather than three hosts, an exception added to unblock a Friday deployment and never reviewed. Each is bought with real operational relief and paid for later. The honest accounting is: a tight extranet policy costs a discovery exercise up front, a per-partner review burden forever, a change-request path for every legitimate new flow, and the occasional business-hours outage when you deny something that turned out to be load-bearing. The alternative costs nothing today and gives an intruder in someone else's estate a routed path into yours. ## What this does *not* give you Even a tight filter is a **reach** limit, not a content check. It stops the partner's compromised host from reaching your database server; it does not tell you whether the file the partner legitimately uploaded to the one permitted destination is malicious. Nor does the filter see anything if you never enumerated the flows and permitted broadly. And a firewall's connection table means an established session may survive a policy change — deny alone does not necessarily tear down what is already open. ## Interview framing Say the sentence plainly: the tunnel authenticates a device, so the trust boundary is *at your terminator*, not at the far gateway. Then show that you know the price of enforcing it — the flow enumeration nobody has done, and the exception list that grows once you do.