Six months after default-deny egress went live, exception turnaround is nine days and a department head is escalating. What do you fix?
answer
- the rule was never the deliverable
- follow the requester's incentive
- who grants the permit when you are bypassed
- fund it, shrink demand, or shrink scope
- escalation count and broad permits in force
basics
~20 sFix the queue, not the rule. A nine-day turnaround turns every deadline into an escalation, and escalations are granted by people who never read a rule base - which produces the permanent broad permit the policy existed to prevent.
solid answer
~50 sDefault-deny egress is a process with a rule attached, not a rule. What has failed here is the exception path: nine days means the fastest route to a working lab is a phone call to somebody senior, and that route produces wide permits granted by people who will never see the rule base - which is the open outbound path an intruder wants, and the reason the policy erodes rather than gets formally reversed. So do two things. Unblock the department today with the narrowest permit that works, with a named owner on it. Then treat the queue as the actual deliverable: fund reviewer time, or shrink demand with pre-agreed patterns that need no individual review, or reduce the number of segments under default-deny to the set you can genuinely service. Then put the turnaround and the escalation count in front of whoever owns the risk, because choosing between those options is their call, not yours.
go deeper
Know that a default-deny egress policy comes with a request path, and that somebody must be named to answer those requests. Recognise a long queue as a security problem rather than an inconvenience.
Be able to say what an exception request must capture and why a permit granted under escalation is almost always broader than one granted through review.
Show the operational judgment: unblock the requester with the narrowest thing that works today, then treat the queue itself as the defect and say who owns fixing it.
Own the trade you must put to an executive - fund review capacity, shrink demand with pre-agreed patterns, or narrow enforcement to what you can service. Holding an unserviceable policy is the worst of the three and it degrades while reporting green.
## The rule was never the deliverable A default-deny egress programme ships three things: a rule at the border, a list above it, and a way for the organisation to ask for a change to that list. Only the third one is ongoing, and it is the only one that decides whether the other two survive. A team that funds the rollout and not the request path has bought a policy with a shelf life. ## What a nine-day turnaround actually buys the adversary Follow the incentive. A researcher with a grant deadline and a blocked destination has two routes. The first is a nine-day queue. The second is an email to a head of department, who calls someone senior, who instructs the network team to "just unblock it". Route two takes an afternoon, so route two wins, and it keeps winning. Now look at what each route produces. A reviewed request produces a specific destination with a reason and an owner. An escalation produces the broadest thing that definitely works, granted in a hurry by somebody whose objective is to end the phone call - which in practice means a wide destination range, or the whole segment permitted outbound. Nobody ever decided to reverse the policy. It was eroded one urgent afternoon at a time, and the end state is a converged segment on paper with an unrestricted outbound path in the rule base. That is precisely the path an intruder inside that segment needs, and it is a path your own process installed. ## What to do in the room Unblock the department now, with the narrowest permit that unblocks them and a named owner attached to it. Arguing process at somebody with a deadline loses, and it also loses the argument you actually need to win. Then raise the real one. ## The three honest options, and only three **Fund the review capacity.** Someone's time, named, with a published turnaround the business has agreed to. It is a small number of hours a week on a converged estate and it is the option nobody wants to pay for because the cost is visible and the benefit is not. **Shrink the demand.** Most requests are not novel. Pre-agree patterns - a defined set of destination categories for a defined class of segment, reviewed once and then self-service - so the queue only sees genuinely new asks. This converts a review problem into a design problem, which is cheaper. **Shrink the scope.** Reduce the number of segments under default-deny to those you can actually service. This is the option people treat as defeat and it is often the correct engineering answer. A policy applied to twelve segments and serviced for three is not stricter than a policy applied to three - it is the same real coverage, plus a queue of angry owners, plus a growing set of broad permits granted under pressure. You have paid more and got less. What is not on the list: holding an unserviceable policy and hoping. That is the worst of the three because it degrades while reporting green. ## The organisational layer The part a purely technical answer cannot reach is that you do not own this decision. The exception process needs an owner with authority to say no - and to have that no stick when it is escalated. If nobody in the organisation will refuse a request, then the review is theatre and the policy will converge on permit-any no matter how good the queue is. So the thing to escalate is not the ticket; it is the choice between funding review capacity and narrowing scope, put to whoever owns the risk, with the numbers attached. ## The numbers to attach Three, and the third is the one that matters. 1. **Turnaround distribution, not the average.** An average of three days with a tail at nine is a different problem from a flat nine. 2. **Escalation count.** How many changes arrived outside the queue this quarter. This measures whether the process is being bypassed, which is the leading indicator of erosion. 3. **Broad permits in force.** How many live entries name an entire hosting or cloud provider's address range rather than a destination. This is the one that tells you the policy has already drifted back toward permit-any while the first two numbers still look acceptable. Reporting "segments enforced" instead of these is how a programme wins an award in year one and is meaningless by year three.
- The organisation refuses to fund any reviewer time. What is the honest recommendation?Reduce enforcement to the segments you can service, and put it in writing. Twelve segments enforced and three serviced gives the same real coverage as three enforced, plus a bypass culture and a growing pile of broad permits granted under pressure. Narrowing scope deliberately is a defensible security position; holding an unserviceable policy while reporting it as enforced is not.
- How would you tell whether the exception process is healthy without reading every ticket?Three numbers: the turnaround distribution rather than the mean, how many changes arrived as escalations instead of requests, and how many live permits name a whole provider's address range rather than a destination. The third is the one that reveals drift back toward permit-any while the first two still look fine.
- A department wants standing authority to approve its own egress destinations. Is that ever acceptable?Approving arbitrary destinations for yourself is not a control at all. A pre-agreed pattern is different: a defined category of destinations for a defined class of segment, reviewed once, then self-service inside those bounds. The distinction is whether the review happened at all, not who clicks the button afterwards.
saying these in an interview costs you the question
- Treats the escalation as a discipline problem rather than a queue problem
- Answers only grant it narrowly and never fixes the process
- Assumes a written policy survives without funded turnaround
- Reports segments enforced instead of exceptions serviced
- Refuses to unblock the requester while arguing process