A managed-service provider reports a breach and their tunnel into your extranet is still up — what do you do first, and what can you establish?

## The first ten minutes are a business decision, not a technical one The technical action is trivial: the tunnel can be disabled immediately. That is exactly why the interesting part is who authorises it. A managed-service provider is, by definition, doing work you depend on — running a platform, monitoring a system, processing a batch. Cutting them off stops that work, and the outage lands on you rather than on them. So the sequence is: get the accountable business owner into the conversation with a stated set of options and their consequences, and record the decision. The options are usually three: 1. **Full disable.** Fastest and most complete for the tunnel path. Maximum business impact. 2. **Narrow.** Reduce the extranet policy to the minimum flows the relationship genuinely cannot survive without, deny everything else, log the denies. Keeps the provider working at a fraction of the reach. 3. **Watch.** Leave it and increase logging. Almost never right with an unbounded compromise on the other end, but it is the option people reach for by default when nobody wants to own the outage, so name it and reject it explicitly. A good answer offers option two, because it is the one that a business owner can say yes to inside the first hour. ## The tunnel is not the only reach, and this is where candidates lose the question A provider relationship almost always has more than one path in. Alongside the tunnel there are typically named accounts in your directory, service accounts used by their tooling, jump-host access, sometimes remote-access accounts on the concentrator, sometimes an API credential. **Disabling the tunnel revokes none of these.** If their engineers can also reach you over the internet with a credential, the tunnel was never the control that mattered. So the containment list runs wider than the network: suspend the provider's directory accounts, rotate or disable the service credentials their integration uses, and check whether any of their access is via a path that is not the tunnel at all. Note also that revoking a password does not by itself invalidate an already-issued session or token, so the credential action has to include killing live sessions. One more mechanical detail worth stating: a firewall's connection table holds established sessions. Disabling a tunnel or tightening a policy may leave existing connections running until they are explicitly cleared or the entries expire. If you mean to cut, verify the cut rather than assuming the rule change did it. ## What you can actually establish Be precise about the direction of every claim, because a provider breach produces enormous pressure to say more than you know. - **You have records of what came out of your terminator.** Flow records for traffic on the inside of the tunnel carry the five-tuple, byte and packet counts and timestamps — enough to show *that* bytes moved between the partner's range and your hosts, and how many. They carry no payload, so they can never show *what* moved. - **Outside the terminator you have less.** Traffic on the outer path is encapsulated between the two gateway addresses; there are no inner addresses or ports to see there. Flow records from the outside interface tell you the tunnel was busy and nothing about who talked to whom. - **Where the traffic hit an application, proxy, authentication system or database, those logs are richer** than anything the network holds, and that is usually where the real answer is. - **You can establish nothing about their estate.** You have their statement. Containment on your side is yours; eradication of the intruder's persistence inside their network is theirs, and the two are different phases owned by different organisations. Your posture after they declare it clean is to watch for re-entry, not to take the declaration as proof. ## The bill Everything above has a price you should name unprompted: the outage that the narrowing or the cut causes and who signed for it; the analyst time to reconstruct which of your hosts the provider's range touched over the retention window you happen to have; the fact that your retention window, not the incident, decides how far back you can look; and the report you will owe your own customers or regulator if the provider's compromise touched data you are accountable for. The relationship also does not end here — you will be asked when to bring the tunnel back, and the honest answer is that you bring it back narrower than it was, with the flow enumeration you should have had all along now written down. ## Interview framing Lead with the containment options and who owns the decision. Then the wider reach beyond the tunnel. Then, unprompted, the limit: your records show that traffic moved, not what it was, and you can make no statement about their estate.