How do you stop IT from deleting your decoy accounts without letting an adversary discover the list?

## The tension, stated plainly A decoy's value depends on the adversary treating it as real. Its survival depends on your own staff not deleting, documenting, scanning or investigating it into uselessness. Those pull in opposite directions, and there is no setting of the dial that satisfies both, so the lead's job is to choose which risks to carry and to make the choice explicit. The failure this question is really about is mundane. Nobody burns the deception programme by leaking it to an adversary; an administrator runs a stale-account report, sees an account with no recent logon and no owner they recognise, and cleans it up. Your hygiene programme worked and your tripwire is gone — and you may not notice for months, because a decoy's normal output is silence. ## Prefer controls over knowledge Every person who must be told is a person who can tell someone else, put it in a ticket, or paste it into a wiki page. So push as much of the protection as possible into mechanisms that need nobody informed: - **Object-level protection.** Directory permissions that deny delete and deny modification of the decoy objects, so the cleanup attempt fails rather than succeeds. The administrator raises a ticket, which routes to the owner, which is exactly the conversation you want and it happens at the right moment. - **Change alerting on the container.** Any modification within the decoy organisational unit alerts, so a tidy-up or a permission change is visible immediately rather than discovered by its absence. - **Attribute shaping.** Cleanup policies select on criteria — no recent logon, no owner, no group membership, a password older than some bound. Give the decoys a populated owner and membership and keep their attributes outside the policy's selection window, so the sweep never proposes them. - **Existence checks.** Because silence is a decoy's normal state, verify periodically that the objects still exist with the intended attributes and that the detection path still fires when the bait is touched deliberately. Do not infer health from the absence of alerts. ## Then keep the circle small and named A few people genuinely must know: - a **deception owner** accountable for the bait's existence, believability and lifecycle; - the **identity or directory lead**, because the objects live in their estate and their team's automation is the main thing that will collide with them; - the **SOC lead**, and this is the one teams forget. If nobody in the SOC knows bait exists, the first fire triggers a full intrusion response against an administrator or a scanner, at real cost and real reputational damage inside the organisation. The SOC needs to know that decoys exist and how a decoy fire is recognised; it does not need the full inventory of which objects are decoys. Everything else follows from need: the red team's scope, whether HR and legal have agreed a process in advance for the case where the toucher turns out to be an employee, and who signs off a bait class before it goes live. ## Where the record lives Write it down — undocumented deception dies with the person who built it — but choose the location adversarially. An intruder inside the estate reads the same systems your staff read: the password vault, the configuration management database, the monitoring configuration, the ticket queue, and an authenticated wiki are all enumerated early and are all the wrong home. Keep a minimal record in a separately controlled place, with the object names, their owner, why each exists, and any exception attached to them. Small enough that reading it takes a minute; separate enough that reaching it is a distinct step for an intruder. ## Assume it leaks anyway Plan for partial burn rather than betting on secrecy holding: - **rotate**, so a list that leaked a year ago is stale; - **diversify the classes** — a decoy account, a decoy share, a document token, a decoy DNS record, a seeded credential — because burning one class does not burn the others; - **never single-thread a path**, so no route through the estate has exactly one tripwire on it; - **watch for the tell**: an adversary who checks and skips is itself information, and enumeration that reads the decoys and never touches them says something about their tradecraft. ## The people cost, and who owns it One more decision belongs at this level: the bait may catch an employee. A fire naming a person, generated by a trap you planted, is a different conversation from a fire generated by their laptop's telemetry, and the process for it — who is told, what evidence is retained, who decides it goes to HR — should be agreed before the first fire rather than in the hour after it. Deciding it in advance is what separates a deception programme from a set of clever tricks. ## What a strong answer sounds like "I would not solve it by telling more people. I would deny delete and modify on the objects, alert on changes to their container, and shape their attributes so the stale-account sweep never selects them. Then a small named circle — deception owner, directory lead, SOC lead — with a minimal record kept outside the vault, the CMDB and the wiki. And I would assume the list leaks: rotate the bait, keep several classes of it, and make sure no path depends on a single decoy."