skip to content

You hold two policy sets for one application — a rented edge you do not operate plus your own firewall — so which policy does an attacker actually face?

level: middleimportance: should knowfreq 44%

answer

  1. neither box sees the other's traffic
  2. permits combine across paths
  3. union, not intersection
  4. two vocabularies, no automatic diff
  5. demote one path to transport

basics

~20 s

The union of what the two permit, chosen by the attacker. Neither box evaluates the other's decision, so a deny added at one is not a deny for the application. Holding both costs two reviews and two incomplete evidence sets.

solid answer

~50 s

Neither is authoritative, because neither sees the other's traffic. The rented edge judges brokered sessions by user, device and application; the border firewall judges packets on the circuit by source address and port. Whatever either one permits is permitted for the application, so the effective policy is the union, and an attacker picks the half with the older admission test. The practical trap is that the two are written in different vocabularies — identity and posture on one side, subnets and ports on the other — so you cannot mechanically diff them or prove they agree. Removing a contractor from a group at the broker leaves the branch-subnet permit untouched. The way out is to collapse the union: name one authoritative decision point per application and rewrite the other path so it can only carry traffic to the broker, never to the application.

go deeper

for a junior

Know that two controls sitting in front of the same application do not add up: whatever either one allows is allowed. Be able to say that neither one's logs show the other's traffic.

for a middle

Be ready to explain the mechanics — each control only evaluates what reaches it, so grants combine — and to give a concrete case such as a user removed at one side who is still permitted by an address-based rule on the other.

for a senior

Demonstrate the collapse: one authoritative decision point per application, the legacy path rewritten so it can only carry traffic to the broker, and the review burden that ends when you do it.

for a principal

Own the consequence for assurance and for suppliers: two policy sets mean two change processes, two evidence sets and a claim you cannot substantiate to an auditor or a customer until one path is demoted.

## Two front doors, neither in charge A migrated application in a branch estate ends up with two things in front of it. One is a rented edge — an identity-aware broker operated by somebody else, which admits a session after checking who the user is, what device they are on and which application they asked for. The other is the border firewall you have run for a decade, which admits a packet arriving over the private circuit based on where it came from and which port it wants. Asked which is authoritative, the tempting answers are "the broker, it is the new model" or "the firewall, it is closest to the asset". Both are wrong, and the correct answer is structural: **neither, because neither evaluates traffic the other handled.** ## The effective policy is a union For any principal-and-path pair, access is granted if *either* control grants it. A permit at the firewall is a grant. A grant at the broker is a grant. There is no component anywhere in the estate that computes the intersection, because there is no component that sees both flows. The consequences follow immediately: - **Revocation is per-path.** A leaver removed from the broker's application group can still reach the application from a shop, because the branch-subnet permit was never keyed to a person. - **A tightening is not a tightening.** Raising device-posture requirements at the broker changes what strict users experience and changes nothing an attacker experiences, if the attacker is standing on the circuit side. - **Neither log is a record of access.** The broker's session log names users and applications and knows nothing of the circuit. The firewall's log carries a five-tuple, byte counts and a rule decision, and knows nothing of users. Asked "who reached this application last month", you must produce two answers in two vocabularies and admit that neither is complete. ## Why you cannot just diff them The deeper problem is that the two policies do not describe the same kind of thing. One is written over identities, device state, application names and time. The other is written over address ranges, ports and interfaces. There is no total mapping between them: a subnet is not a set of users, and a user is not a subnet. So "prove the two policies agree" is not a task you can automate; it is an argument you make per application, by hand, and it decays every time either side changes. That is the review burden, and it is the price of the interim state. Two change processes, two exception lists that drift apart, two sets of evidence at audit time, and one of the two operated by a supplier whose change window is not yours. ## What the attacker does with the disagreement An attacker does not need to find the disagreement analytically. They probe both front doors and take the one that answers with less. In a branch estate that is almost always the circuit side, because its admission test is a property of *position*, and position is exactly what an attacker acquires first: a shop PC, an unmanaged device on the shop network, a supplier's laptop in the stockroom. The disagreement is also an *evidence* problem during an incident. If you can only show that the broker denied them, you have not shown they did not get in. ## Collapsing the union The fix is not to make the two policies agree. It is to make only one of them reachable for that application: 1. Name one authoritative decision point per application — for a migrated app, the broker. 2. Rewrite the legacy path's policy for that application from "branches may reach the app" to "nothing may reach the app except the broker's egress". The circuit becomes transport, not an admission decision. 3. Retire the name and the route for the legacy front door once step 2 has been proven quiet. After step 2 the union has one member again, and the firewall policy for that application becomes trivially reviewable — a single permit whose meaning you can state in a sentence. That is the state worth reaching even when you cannot yet afford to remove the circuit itself. ## How to answer well Say "union, not intersection" and say why — no component sees both paths. Then give one concrete consequence, ideally revocation, and one about evidence. Finish with the collapse: one authoritative decision point per application, the other path demoted to transport.

  • How would you answer an auditor asking who accessed that application last quarter?
    Honestly, and in two parts. The broker's session records name users, devices and applications for brokered sessions only. The firewall's records carry source and destination addresses, ports and byte counts for the circuit path, with no user identity at all. Neither is a complete access record, and there is no key that joins them. Say so, and give the date by which the legacy path will be demoted so a single record exists.
  • The rented edge is operated by a supplier. What does that change about holding two policy sets?
    Change control and evidence. Their policy moves on their release schedule and their change window, not yours, and you see their decisions only through whatever log export they offer. So you cannot assume symmetry of speed: an urgent tightening you can make in minutes on your own firewall may take a supplier ticket. That asymmetry is an argument for making your own path the one that carries no admission decision.

saying these in an interview costs you the question

  • Says the stricter of the two policies wins
  • Believes removing a user at the broker revokes their access
  • Treats the broker log as a complete access record
  • Assumes the two policies can be diffed automatically
  • Calls the newer control authoritative because it is newer

context