Orchestration

Name every decoy using the naming conventions of the environment it is deployed into, resolved from configuration at deploy time. Templates and published guidance carry placeholders and patterns (<team>-<function>-role, /prod/<service>/<key>), never concrete names, and decoys do not share a prefix, suffix or numbering scheme that real resources lack.

Why: If decoys follow a shared pattern, an attacker who finds one can enumerate and avoid all of them. Concrete names in shared templates or public docs become attacker IOCs.

Not for: Decoys that only exist as a network address (a listener on an unused IP) have no resource name to blend. Their hostname, banner and service fingerprint still have to blend.

Do not put words or values that reveal a decoy (honey, decoy, fake, canary, trap, test, deception, expired, revoked) in names, tags, descriptions, seeded data, credential values, banners or comments. Use realistic values for tags and content, such as an environment of production and a plausible owning team.

Why: An attacker who enumerates resources reads tags and content as well as names. One marker word anywhere exposes the decoy and tells the attacker that deception is in use.

Not for: No decoy class is exempt. The only place a decoy may be labelled as a decoy is the private inventory, which lives outside the decoy environment.

Identify decoys internally by the private inventory first. Where the platform needs a queryable marker, use an ordinary-looking value reserved for the security team (for example a cost-centre or project code that looks like a real team's), never a tag that names the resource as a decoy.

Why: The security team needs to find and inventory decoys with native tooling, but an attacker who enumerates tags must see only routine metadata.

Not for: Platforms with no tagging (files on a host, many directory objects, network listeners, most SaaS objects). Use the private inventory only.

Where a technique uses more than one decoy, link them into a plausible chain: each decoy has a believable way to be found and points believably to the next (for example a secret that names a role that can read a data store).

Why: Isolated assets with no relationship to anything look planted. A believable chain draws the attacker further in, gives several tripwires, and shows how far the attacker has got.

Not for: Single-purpose tripwires: a lone honeytoken credential, a single decoy file, a network listener.

Give each decoy, and any identity it exposes, only the permissions its lure path needs, scoped to decoy resources. Grant write access only where the path requires it and only to decoy resources. A credential used as bait must authenticate only to an identity with no access to real data or workloads.

Why: A decoy that grants real access turns the detection control into the breach.

Not for: No decoy class is exempt. Interactive techniques (T3 Active Engage) still need a contained interaction surface.

Make decoys reachable only from inside the environment: block public access, and create no trust to or from outside accounts or tenants. Scope any exception to a defined source range and keep it inactive (stopped, disabled) until it is needed.

Why: Internal decoys target attackers and insiders who are already inside, where any touch is meaningful. Public exposure brings internet background noise and the risk of a decoy becoming a pivot point.

Not for: Internet-facing honeypots and external-exposure techniques, which are public by design and need their own containment. Active measures D053, D063 and D072 act on infrastructure the defender does not own: content for them must say so and require legal review before use.

Deploy and operate decoys with short-lived, role-based identities. Do not create long-lived users or keys for the deception system itself.

Why: Long-lived credentials in the deception tooling are a real attack path into the environment, and they are hard to audit and revoke.

Not for: Honeytoken techniques where a long-lived credential is the bait. That credential must belong to an identity with no real access (DP5) and must never be used for operations.

Before building a decoy, name the exact recorded event (log source, event or API name, the field that identifies the decoy) that its use produces, and confirm that log is enabled where the decoy lives.

Why: Decoys are sensors and the alert is what they produce. A decoy whose use is not recorded gives false confidence.

Not for: No decoy class is exempt.

Build decoys from the platform's own resource types and detect them with the platform's own logs. Add agents or extra infrastructure only when the platform cannot record the touch.

Why: Native resources blend in. Native logs need no extra agent that an attacker could spot or stop, and fewer moving parts means less silent rot.

Not for: Network listeners and host file decoys, which usually need a sensor. SaaS platforms with no usable audit log.

Run detection, alerting and the inventory in a separate, higher-trust boundary (account, subscription, project, tenant or host) from the decoys. Never deploy decoys into the monitoring boundary, and never host monitoring logic in a decoy boundary.

Why: An attacker who takes over a decoy environment gets worthless decoys but cannot disable, read or tune the detection that is watching them.

Not for: Single-host or very small deployments with no second boundary. There, at minimum, send events off the host immediately and keep the rules and inventory elsewhere.

The monitoring side may assume a deployment role in the decoy side, scoped only to creating, changing and deleting decoy resources. The decoy side may only send events to one named destination in the monitoring side. It cannot read rules, change processing, or reach notifications.

Why: If the forwarding identity is compromised, the worst outcome is junk events (noisy and detectable), not blinded detection. If the deployment identity is compromised, the attacker can touch only decoys, not real workloads.

Not for: Host and network decoys that write straight to a central collector. The same rule applies to the collector credential: send only.

Before any deploy or destroy, resolve which boundary the current credentials belong to, map it to monitoring, decoy or unknown, and refuse if it does not match the operation. Treat unknown as refuse.

Why: Running the right command with the wrong credentials is the most common dangerous mistake: decoys in the monitoring account, or forwarding pointed at itself.

Not for: Manual, single-boundary deployments. A written precondition still applies.

Deploy in dependency order: central processing and notification, then central rules, then permission for the decoy side to send, then forwarding, then decoys. Each step checks its prerequisite and refuses, or at least warns, if it is missing. Tear down in reverse so a decoy never outlives its alert path.

Why: A decoy with no working alert path is a silent false negative, the worst failure mode for deception.

Not for: No decoy class is exempt.

Keep a private inventory of every decoy (boundary, type, identifier, technique, deploy time, last verified, status). Generate detection filters from it rather than maintaining identifier lists by hand. Keep it in the monitoring boundary.

Why: Hand-kept lists go stale. The inventory is what reconciliation, proof-of-life and audit all check reality against.

Not for: No decoy class is exempt.

On a schedule, check every inventory entry across the whole chain: the decoy exists, its logging is on, it is forwarded, a central rule covers it, and the alert path works. Report 'deployed but not covered' (orphan) and 'in the inventory but gone' (phantom) states explicitly.

Why: Deception fails silently. Resources get deleted, rules get disabled, accounts get retired. Partly working is the most dangerous state because it looks fine.

Not for: No decoy class is exempt.

Keep each decoy unit's deployment state separate from the others and from the monitoring components, so that one unit can be created, changed or destroyed without risking the rest.

Why: Shared state means one corrupted state file or bad destroy can remove every decoy, or the monitoring itself.

Not for: Decoys that are not managed as infrastructure code (hand-placed files, directory objects). Track each one as its own inventory entry.

Every change can be previewed (names resolved, plan shown) before it is applied. Re-applying the same configuration changes nothing. Every deploy and destroy is recorded with operator, time, boundary and resources, in a record kept outside the decoy environment.

Why: Peer review catches naming and permission mistakes before they reach production. An independent record answers 'who deployed this, and when' even if the platform's own audit log was tampered with.

Not for: No decoy class is exempt.

Fetch decoy templates from a known source. Check a hash or signature against a trusted manifest before use, and apply only from a verified local copy.

Why: Templates are code. A tampered template can plant a real backdoor or a decoy that does not alert.

Not for: Decoys created by hand without templates.

Use an organisation-level guardrail so that only the security team's role can delete or change decoys, and alert on denied attempts. Do not let the guardrail itself expose the inventory: restrict who can read it, or scope it by the covert marker rather than by listing decoy names.

Why: An attacker with high privileges might delete decoys to cover their tracks, and other teams might remove them by accident. A guardrail that lists every decoy name is an inventory for anyone who can read it.

Not for: Platforms with no organisation-level deny policy (standalone hosts, many SaaS platforms). Use the platform's admin role separation and reconciliation (OP6) instead.

Keep two operations. A safe drill injects a synthetic, labelled event into the central path and notifies as a drill. A live simulation touches a real decoy and fires a real alert. It must target exactly one decoy, need explicit confirmation even in automation, be announced to responders beforehand, and be recorded with operator and time.

Why: Any decoy alert is meant to be a real attack. A live simulation breaks that on purpose, so it must be unmistakably intentional, and responders must be able to tell a scheduled exercise from a compromise.

Not for: No decoy class is exempt.