skip to content

The Asset Nobody Listed

Policy is written per known entity, so anything absent from the catalogue is governed by a default. Interviewers ask which default you chose, because both answers are bad.

on this pageshow

questions

4

Which rule decides access for an internal service in no asset catalogue, and what does each default cost when an attacker finds it?

level: juniorimportance: must knowfreq 62%

answer

  1. nothing above it matched
  2. the last line of an ordered rule list
  3. no rule means no review and no expiry
  4. one default is silent, the other is loud
  5. the set you could not enumerate is the set that breaks

basics

~10 s

The catch-all at the bottom of the policy decides it, because nothing above it matches. Allow-by-default hands an adversary a path no reviewer ever looks at; deny-by-default breaks integrations nobody can name in advance.

solid answer

~50 s

An access policy is an ordered list of rules ending in a catch-all, and an entity that appears in no catalogue is never named by a rule above it, so the catch-all is its entire policy. If that catch-all allows, the unlisted service is reachable and nobody reviews it, because reviews walk the rules that exist — the adversary gets a path with no owner, no expiry and no alert. If it denies, everything unlisted stops at once, and "unlisted" is exactly the set you could not enumerate before flipping the switch: an integration appliance nobody owns, a file-transfer service account created years ago, a partner's automation that runs quarterly. The cost is not symmetric in time either: allow-by-default costs you silently and continuously, deny-by-default costs you loudly on one night. Both are real; only one is visible on a dashboard.

go deeper

for a junior

Be ready to say that the bottom rule of a policy decides everything no other rule names, and to state one concrete cost on each side: an unreviewed path for an intruder, or a broken integration you could not have listed.

for a middle

An interviewer expects you to explain why an unlisted entity is invisible to access reviews and change tickets, and why its only trace is traffic the enforcement point happened to observe.

for a senior

Show that you treat the default as a failure posture rather than a setting: sequence denials by how defensible the destination is, and pair any denial with a fast, expiring way to grant access when you are wrong.

for a principal

Own the framing that neither default is free and that the choice needs a named accepter with a date on it. Be able to put the silent, continuous cost of allow next to the loud, one-night cost of deny in terms the budget holder recognises.

## The last line of a policy is a policy Any access policy — a firewall rule base, an identity-aware proxy's rule set, a ZTNA policy engine, a segmentation policy between zones — is an **ordered list of rules terminated by a catch-all**. The catch-all is the rule that matches when nothing above it did. It has no subject, no owner and usually no ticket behind it, and it is the complete access policy for every entity your organisation does not know it has. That is the whole point of this problem. Rules are written about things people know about. An entity in no catalogue is, by construction, never the subject of a rule. So the question "what is our policy for the integration appliance nobody owns?" has exactly one answer, and it was set years ago by whoever wrote the last line. ## The two defaults, and what each actually buys **Allow by default ("default permit").** Anything not explicitly denied gets through. The cost is invisible and continuous: - The unlisted entity is reachable, and nobody reviews it. Access reviews and rule-base audits walk the rules that exist; there is no rule to review. - An adversary who gets a foothold on an unlisted appliance, or who replays an old service credential belonging to one, inherits its reachability. Nothing in the policy distinguishes that traffic from the appliance's normal traffic, because the policy never described the appliance's normal traffic. - There is no expiry. A rule has a change ticket and often a review date. A catch-all has neither. **Deny by default ("default deny").** Anything not explicitly allowed is dropped. This is the posture every zero-trust programme is funded to reach — NIST SP 800-207 describes access as granted per-request to a named subject for a named resource, which only means anything if unnamed subjects get nothing. The cost is loud and concentrated: - Everything unlisted stops **at the same moment**, and "unlisted" is precisely the set you could not enumerate in advance. If you could have listed it, it would have had a rule. - The breakage is biased toward the oldest and least-understood things: the file-transfer account created in 2014, the internal app one partner's automation still calls, the appliance whose vendor contract lapsed. These are frequently the revenue-bearing ones, because they have been quietly working for a decade. - The failure is often at an unhelpful hour. Batch integrations run overnight; a partner's quarterly reconciliation runs on a date nobody in the room remembers. ## Why "just deny, obviously" is the answer that fails an interview A candidate who says "default deny, always" has stated the destination and skipped the problem. The interviewer is testing whether you understand that the default is not a technical preference — it is a **failure posture somebody has to accept**. Turning the catch-all to deny means telling a business that an unknown number of unknown integrations will fail on a known date. Turning it to allow means telling a security programme that the hole it was funded to close stays open. In many estates neither answer gets a signature, and the catch-all keeps whatever it had by inertia. The useful answer names both costs and then narrows the gap between them, rather than picking a side: | Move | What it buys | What it still costs | | --- | --- | --- | | Deny only the destinations you can defend | The most sensitive resources stop accepting unnamed subjects immediately | The rest of the estate is still default-allow | | Deny by default with a fast, expiring break-glass | Being wrong costs minutes, not a quarter | Somebody must staff the break-glass at 02:00 | | Record what the enforcement point sees before flipping | You learn some of the unlisted set | The recording window is itself an allow window | | Time-box allow as a dated, signed exception | The default now has a name and an expiry on it | Somebody has to sign, and may refuse | ## The direction of the claim Be careful what each fact proves. That an entity has never appeared in a deny log **does not prove it does not exist** — it may reach its destination on a path that never passes your enforcement point. That an entity appears in the allowed traffic **does not prove it is legitimate or owned**; it proves a request arrived and the catch-all matched. And a policy with no rule about a subject is not a policy of neutrality toward that subject: it is whichever default the last line carries, applied silently, to an entity nobody is watching.

  • Why does an access review never surface an entity that only the catch-all decides?
    Reviews iterate over the rules that exist and ask who owns each one and whether it is still needed. An unlisted entity is the subject of no rule, so it appears nowhere in the review's input. The only place it shows up is in traffic the enforcement point actually observed, which is a different artefact and usually a different team's.
  • Does an entity that never appears in your deny logs prove it does not exist?
    No. It proves nothing arrived at that enforcement point and matched a deny rule. The entity may reach its destination on a path that bypasses the enforcement point entirely — an east-west route inside the same segment, a legacy circuit, or a second access path left running during the migration. Absence of a record is evidence about your vantage point, not about the estate.
  • If deny by default is the goal, why not simply schedule the change for a quiet weekend?
    A quiet weekend reduces the number of humans watching, not the number of integrations. Overnight batch and quarterly partner jobs are exactly what runs then, and they are the least documented flows you have. Scheduling helps only when paired with a way to grant access quickly while the change is in effect; otherwise you have chosen the hour with the fewest people able to fix it.

A building where the only door policy is what the night guard does with people whose names are not on the list. Whatever he does by habit is the policy for every visitor nobody wrote down.

saying these in an interview costs you the question

  • Says default deny is obviously correct without naming what breaks
  • Assumes an unlisted service is not reachable because nobody documented it
  • Thinks an access review would have caught the entity
  • Treats allow-by-default as costing nothing until a breach happens
  • Believes absence from deny logs proves the entity does not exist

context

open as a page

An access proxy's first-seen records are your only asset list — how long do you watch, and which attacker paths never appear there?

level: middleimportance: should knowfreq 45%

basics

~20 s

Watch a full business cycle: quarterly and year-end callers are the undocumented ones. The records cover only subjects that reached that enforcement point, so a path bypassing it, or reuse of an already-enrolled subject, leaves no new entry.

open as a page

You run a new deny-by-default catch-all in log-only mode for 90 days first — what does that window hand an adversary?

level: seniorimportance: should knowfreq 48%

basics

~20 s

Ninety more days of allow-by-default on every unlisted subject, plus the risk that whatever an intruder does during the window becomes part of the baseline you promote into permanent exceptions. Log-only defers the denial; it does not de-risk it.

open as a page

Nobody will sign for denying unclaimed extranet subjects an adversary may already be using — how do you force that decision to an owner?

level: principalimportance: nice to knowfreq 33%

basics

~10 s

Stop asking for a signature on a setting; put a dated, named risk acceptance under the current allow instead. Once staying open needs an owner and an expiry, the decision makes itself.

open as a page