You inherit a 4,000-entry MAC bypass list where any entry is spoofable from a ward socket: how do you shrink it without downing a device?
answer
- narrow before you delete
- the logs already know who authenticated
- log-only first, long enough for seasonal devices
- dormant entries are the best forged identity
- rank by reach, not by age
basics
~20 sNarrow before you delete. Tighten the authorisation on every entry first, run the removal decision in log-only mode against real traffic, attribute each surviving entry to an owner and a device record, and retire the rest through agreed change windows.
solid answer
~50 sDeleting is the last step, not the first, because a wrong deletion on a hospital network is a clinical incident. Start with the data the policy server already has: every bypass accept is logged with address, port and time, so you can see which entries have authenticated recently, from where, and which have never appeared. Then work in three passes. First, narrow the authorisation attached to each entry — that reduces what a spoofed address is worth without any risk of denying a device. Second, evaluate the tighter policy in log-only mode so you can read what would have been denied while everything still works. Third, retire entries with owners in the loop and in agreed windows. Prioritise by blast radius, not by dust: the entry that never appears is the attacker's favourite identity — no collision, nobody notices — while the entry that lands in a wide segment is the one that pays out.
go deeper
Know that a bypass list is an exception register, that every accept is logged with address, port and time, and that those logs are where any clean-up starts.
Explain why removal is sequenced last: narrowing an accept cannot deny a working device, while deleting an entry can, and log-only evaluation turns a guess about what would break into evidence.
Demonstrate the ranking judgment — reach first, dormancy second — and the operational care a clinical estate needs: a log-only period long enough for seasonal equipment, small reversible batches, and owners awake during the window.
Own the reason the list reached four thousand: entry was free and exit belonged to nobody. Argue for expiry at creation and a required owner as the change that stops it regrowing after your project ends.
## Why the obvious plan is wrong The instinctive plan is: find entries that have not been seen in ninety days, delete them, watch for complaints. On a ward that plan denies a mobile ultrasound cart used quarterly, a spare pump that comes out of the store when the census spikes, or a device that has been in for repair. The complaint arrives as a clinician unable to work, and the second attempt at the project never gets approved. Interviewers ask this question because the technical part is easy and the sequencing is not. ## Step 0: get the evidence you already have A bypass accept is a logged event. For each address you can usually recover: when it last authenticated, which ports and locations it has appeared on, and how often. That gives you three buckets — regularly present, seasonally present, never seen — and the buckets are not equally risky in the way people assume. ## The counter-intuitive risk ranking Rank by what an attacker gains, not by how stale the entry looks. - **A dormant entry is the most attractive identity on the list.** The device is not there, so presenting its address collides with nothing, causes no duplicate-address symptom, and nobody notices the real device behaving oddly. It is a permitted identity with no owner watching it. - **A live entry with a wide authorisation is the biggest payout.** Even if the spoof is noticed eventually, the attacker reaches everything the real device reaches. - **A live entry with a narrow authorisation is the least interesting.** Someone would notice, and the reach is one destination. So the work is ordered by *authorisation width first, dormancy second* — not by the age column. ## Pass one: narrow, do not delete Tightening the accept attached to an entry cannot deny a device that is behaving normally; it only removes reach the device was not using. So it carries almost no outage risk and it is the fastest reduction in what the whole list is worth to an attacker. Use the flow the device already generates to decide what it needs. This pass is also the political win you take back to the device owners: you reduced risk without touching a single device. ## Pass two: log-only enforcement Before any entry is removed, run the decision you intend to make and record it while still admitting the device. You want a list that says: *if this policy were enforced, these forty-one devices would have been denied, on these ports, at these times.* That converts a guess into evidence, and it catches the quarterly ultrasound cart before it costs you anything. Give the log-only period long enough to cover the estate's real duty cycle — a month is often too short in a hospital, where a seasonal device is genuinely seasonal. ## Pass three: retirement with owners Now removal, and it is a conversation rather than a config change: - Every surviving entry gets a named owner and a device record. An entry whose requester left the company is not an entry, it is an artefact. - Entries with no owner get a deadline and a scheduled expiry, agreed in advance, landing inside a change window with the department awake and reachable. - Removal happens in small batches so a mistake is attributable and reversible in minutes, not a mass deletion whose blast radius you cannot bound. ## What you also fix while you are in there A list this size grew because entry was free and exit was nobody's job. If you leave that intact, the list is 4,000 again in three years. The durable changes are: entries carry an expiry from creation, entry creation records an owner and a device record as a required field, and a device class has a pre-approved narrow authorisation so a new entry is only ever an address rather than a design decision. ## What a strong answer sounds like Sequencing, evidence and blast radius. Say that you narrow before you delete because narrowing cannot cause an outage; that you run the deny decision in log-only mode long enough to catch seasonal devices; that you rank the work by how much reach an entry grants rather than how old it looks; that the dormant entry is the attacker's best identity precisely because nobody is watching it; and that the last step is an owner and an expiry, so the list cannot silently regrow.
- How long should the log-only period run before you remove anything?Long enough to cover the estate's real duty cycle rather than a calendar convenience. In a hospital that means covering seasonal and loaned equipment — a quarterly cart, spares that come out of the store during a surge, devices away for repair. A month usually is not enough; a quarter, plus a check with the department about anything they know is dormant right now, is a defensible baseline.
- Why start with narrowing the authorisation rather than removing obviously dead entries?Because narrowing cannot deny a device that is behaving normally, so it carries almost no outage risk, while removal can and does. Narrowing also reduces what the whole list is worth to an attacker immediately, including all the entries you have not yet analysed. And it gives you something to show device owners that cost them nothing, which is what buys cooperation for the removal phase.
- An entry has not authenticated in two years. Is deleting it safe?Safer than most, but not automatic. Confirm with the owning department whether the device is in a store, away for repair, or genuinely retired, and schedule the removal in a window rather than doing it silently. Note the flip side: a two-year dormant entry is the one an attacker would most like to use, because presenting it collides with nothing and no owner is watching, so it is also urgent.
saying these in an interview costs you the question
- Deletes stale entries first and waits for complaints
- Assumes dormant entries are low risk because nothing uses them
- Skips log-only evaluation and enforces straight away
- Sorts the work by entry age rather than by granted reach
- Ends the project without owners or expiry, so the list regrows