Where do you actually place deception?

RBI tells Indian banks to run deception. Nobody tells them where to put it. That's a placement problem in three dimensions, and only one of them is the decoys themselves.

The Reserve Bank of India's Cyber Security Framework in Banks (June 2016, refined since) is one of the clearest sector-specific cybersecurity directives any regulator has issued. Three annexes do most of the work: Annex 1 sets baseline resilience requirements, Annex 2 mandates a Cyber Security Operations Centre (C-SOC) with continuous surveillance, Annex 3 defines incident reporting into the IDRBT / CERT-Fin ecosystem. Inside Annex 2's reference architecture, alongside SIEM tooling and threat feeds, sits a quiet line item that has shaped a decade of Indian BFSI security spending: HoneyPots / Deception Technologies.

ReBIT (Reserve Bank Information Technology) and Smokescreen co-hosted an Operational Excellence webinar walking the sector through how deception fits the framework. The webinar made the case beautifully. It also, like every public deception talk we have ever seen, stopped one step short of the question that matters most operationally: given that I am a bank with 40,000 internal hosts and a regulatory obligation to run deception, where do I actually put it?

We wrote a first version of this post a week ago framed around decoys specifically. A reviewer with operating experience in the deception product space pushed back, hard, on the framing. The pushback was right. What follows is the corrected, sharper version. The unsolved half of deception is broader than "where do I put my decoys" and the substrate needed to solve it is bigger than what any deception vendor ships today.

Deception is a palette, not a decoy

The first thing to get out of the way is that "deception" is a category, not a product shape. A serious deployment uses at least four distinct artefact types, and each has different placement physics. Conflating them — as marketing material routinely does, and as our v1 draft did — produces guidance that works for one and fails for the others.

Two important things follow from this table.

First, the marketing promise of "no false positives" lives cleanly in the tripwire and token rows. By construction, no legitimate process touches a canary AD object or fires a honey-doc beacon. Those artefacts genuinely are zero-FP detectors. Engagement decoys are not in the same category — they can fire on misconfigured vulnerability scans, on a curious new admin, on a misdirected backup job. The framing "deception is no-FP" is true of one row of the palette and overclaimed of the others. The v1 of this post let the overclaim through.

Second, the job a given artefact is doing changes which row of the palette you reach for. Which brings us to the second framing correction.

Three jobs, not one

A deception artefact can do any of three things, and the right palette item depends on which one you need.

1. Detect. Fire an alarm when an attacker touches it; hand the alert to the SOC, full stop. The artefact's value is the signal, not the interaction. Tripwires and tokens are purpose-built for this. Cheap to deploy, cheap to maintain, no engagement infrastructure required.

2. Engage. Hold the attacker's attention long enough to extract TTPs — the malware they drop, the lateral-movement tools they pull down, the credentials they target. This is what high-interaction decoys are for, and it is genuinely hard engineering: convincing service emulation, neighbourhood-aware naming, plausible login history, traffic that looks lived-in.

3. Hand off to response. A decoy or tripwire fires; what happens next is a response decision — quarantine the source host, rotate the credentials the attacker grabbed, open a ticket scoped to the blast radius of the touched artefact. Most deception products treat this as a checkbox SOAR integration. Doing it well requires the same substrate the placement question requires (which path did the attacker take to get here? what was their next likely hop? what's in their blast radius?), because a response that only handles the touched artefact and not the path that led to it is response-theatre.

A serious deployment runs all three jobs. Most deployments overweight (2) — because (2) is what the product was sold on — and underspend on (1) and (3). The reviewer's framing is exactly this: a deception solution is not a TTP-capture tool with an alert as a side-effect. Detection-only and response-handoff are first-class. The placement substrate has to serve all three.

The three dimensions of the placement problem

Placement, then, is not a one-dimensional question. It is a fit problem in three dimensions, and every deployment has to solve all three simultaneously:

• The environment dimension. What assets, identities, networks, and access paths actually exist in this bank? Where do users come from, where do contractors land, how is the branch-office network actually wired? This is the substrate — the ground truth of the estate as it exists today.

• The threat-vector dimension. What are the kill-chain stages an attacker plausibly executes here? Initial access via phished UPI-ops mailbox, lateral movement via stolen service-account ticket, privilege escalation via a misconfigured Group Policy, data staging in a forgotten S3 bucket. The vectors are not generic — a tier-1 bank with public-facing UPI rails has a different vector mix than a co-operative bank with a 100-branch legacy core.

• The palette dimension. Which deception artefact is the right tool for the part of the kill chain you want to catch? A decoy is the wrong answer for "attacker is doing LDAP enum"; a canary AD account is the right answer. A canary credential is the wrong answer for "attacker is exfiltrating staged data"; a beacon-bearing honey-doc is the right answer.

The first two dimensions, taken together, are often called the attack surface. They define the space deception has to cover. The third — the palette — defines what you put into that space. A placement plan is a function that maps {environment × vector} → {palette item, location, configuration}.

Most placement guidance in the market today addresses one dimension at a time and assumes the others. Templates pick a palette item for you and assume your environment looks like every other bank. Services engagements walk your environment and pick palette items by intuition, then go stale the moment the environment changes. Neither produces a function over the full three-dimensional space.

What an event graph is — and is not — for

Here is where we need to be honest about what we have and what we don't.

The substrate Setu builds is a continuously-rebuilt event graph: identity × asset × time-decayed activity, fused from OCSF-normalised events the C-SOC already collects under the Annex 2 mandate. It is a posterior — it captures what has actually been traversed, by whom, at what cadence, in the recent past.

A full attack surface is a forward concept. It includes:

• Permitted-and-traversed paths (visible to the event graph).
• Permitted-but-never-traversed paths (visible to access graphs, invisible to event graphs).
• Latent paths that no one has discovered yet (visible to neither — invisible until somebody runs the scanner or compromises the asset).
• Adversary-creatable paths — edges that don't exist today but that an attacker creates by compromising an identity or a host (invisible to all three until they happen).

A continuously-rebuilt event graph cannot see the last three classes on its own. This is a real and load-bearing limitation. It is also one we should not paper over with a confident-sounding paragraph.

What follows from this limit is not "the event graph is the wrong substrate" — it's "the event graph is one of two substrates a placement plan needs, and the other one comes from somewhere else."

For decoy placement specifically, the event graph is overwhelmingly the right substrate. Decoys are expensive and you want a small number of them, sitting on high-probability paths an attacker would actually traverse. Targeting the high-probability traversed-edge set is the whole point; partial coverage of the latent surface is a feature, not a bug. A decoy on an edge no attacker has ever taken is a decoy nobody trips.

For tripwire and breadcrumb seeding, the event-graph posterior is incomplete. You want broad enumeration surface — every plausible LDAP query an attacker might run should turn up at least one canary; every credential dump on a compromised endpoint should contain at least one bait. Coverage matters more than path-probability. Here, the event graph wants a companion: an external attack surface manager for what's exposed and discoverable on the outside, an identity attack surface manager for what's enumerable in AD. The event graph tells you which neighbourhoods are alive; the ASM layer tells you which neighbourhoods exist at all.

The honest framing of Setu's position, then, is this: the event graph is the placement-optimization layer; an ASM product is the coverage layer. They compose. We are not your attack surface management. We are the layer that, given a surface, decides where in it the deception budget gets spent.

If you already run an ASM today — and most Annex 2-mature banks do, in some shape — the composition is the headline. If you don't, deception placement at the coverage end of the palette (tripwires, tokens) is going to be brittle no matter whose product you buy, and the right first investment is ASM, not more decoys.

What the graph contributes, palette by palette

With the framing fixed, here is the per-palette breakdown of what the event graph actually contributes.

Decoy placement. Personalised PageRank with event-biased restart, seeded from each plausible perimeter foothold (internet-facing service, contractor VPN endpoint, recently phished mailbox), produces a stationary distribution ranking every internal node by how likely an attacker landing at that foothold is to traverse it. Top decile → Threat-Intelligence-style decoys. Betweenness-centrality chokepoints — the few nodes almost every lateral-movement path passes through — → Zero-Trust-style decoys. Spectral clustering identifies the natural neighbourhoods (the AV-FST-STORE cluster, the NEFT-gateway cluster, the HSM cluster) so each decoy inherits its neighbours' service fingerprint, naming convention, owner CMDB tag, and login cadence. Per-node activity scoring tracks the heartbeat of the live twins so the decoy is rotated before the believability gap widens.

Breadcrumb seeding. Endpoint lures only fire when an attacker on a compromised endpoint searches for and uses the bait. The bait should be seeded on endpoints whose users sit high on the identity-graph adjacency to service accounts, domain admins, or sensitive shares. The graph identifies these endpoints; the bait artefact is then chosen to match the post-compromise tradecraft the bank's threat-intel feed says local adversaries actually run (RDP creds for ransomware crews, mapped drives for data-staging crews, browser-saved passwords for cred-harvest crews).

Tripwire targeting. Canary AD accounts, decoy DNS records, dormant service bindings. The graph identifies the neighbourhood structure (which OU clusters are routinely enumerated, which DNS zones are queried by reconnaissance-shaped traffic, which service names appear in lateral-movement paths). The ASM layer identifies the exposure surface (what's externally discoverable, what's enumerable in AD by an authenticated user). The intersection — neighbourhoods that are both alive and enumerable — is where tripwires earn their keep.

Token distribution. Canary keys, honey-docs, beaconed binaries. Placement targets the locations attackers loot during post-compromise: file shares that contain real credentials, S3 buckets used for backups, document repositories holding genuine sensitive material, code repos with secrets. The graph contributes the which-shares-are-actually-walked-by-lateral-movement signal; the artefacts themselves are off-the-shelf from the canary-token ecosystem.

None of the underlying math is novel. PPR is from 2003. Spectral clustering is older. Brandes-algorithm betweenness is from 2001. Co-occurrence matrices predate computers. What is new is the production engineering: applying these well-understood operators to a continuously-rebuilt security event graph at sub-hourly cadence, and exposing the outputs as a placement-plan API a deception vendor's deployment automation can consume.

What this means for the Indian BFSI buyer

If you are a CISO at an Indian bank or NBFC running deception today, you almost certainly bought it through a Smokescreen, TrapX, Acalvio, Illusive, or comparable engagement — or as a module bundled into a SASE or XDR stack. Setu is not asking you to rip any of that out. The substrate sits underneath whatever palette items you have already deployed.

The operational shape:

1. The C-SOC you already run under Annex 2 produces OCSF-normalised event flow. If it doesn't yet, that is a separate (and arguably more foundational) conversation. Setu's agent + collector are deployable on-prem and air-gapped to meet DPDP and sectoral isolation requirements.

2. An attack surface management product — yours or one we recommend — produces the coverage map. If you already have an EASM and an identity-ASM, the substrate composes with what you have. If you don't, deception placement is the second investment, not the first.

3. Setu's graph engine builds the event-side substrate continuously. No additional sensors, no additional licensing of the existing telemetry sources. The graph is yours; it never leaves your environment.

4. The placement-plan API exposes per-palette outputs. Decoy locations with neighbourhood metadata. Breadcrumb seeding lists scored by endpoint compromise probability. Tripwire neighbourhood targets. Token-distribution locations. Each is consumable by the deployment automation of whatever deception product you run.

5. When an artefact fires, the vendor's product calls back to Setu, which uses that confirmation to upweight the path that led there for the next plan. Placement gets more accurate with each fire. That is the living-system loop.

6. CERT-Fin intelligence sharing continues unchanged. The artefact IOCs feed the sectoral threat exchange at whatever cadence your incident-reporting obligations require. The placement substrate adds no new data-sharing surface; it computes locally, recommends locally, learns locally. Placements stay private and tenant-local; intelligence stays shared.

What the buyer gets, against the same deception licence they were already paying for: a measurably better hit rate across the full palette, artefacts that don't go stale silently, an exit from per-environment services dependency, response handoffs scoped by graph blast radius rather than by the touched artefact alone, and a placement methodology that can be audited and defended in a way "the vendor's template" never can.

The structural reason no vendor built this

It's worth stating directly. Deception companies are organised around the artefact as the product: the lures, the breadcrumbs, the high-interaction services that fool fingerprinting, the management plane that operates them. That is genuinely hard, and the companies that do it well — Indian and international — have earned their positions.

Building a continuously-rebuilt, OCSF-normalised, on-prem-capable event graph that fuses network, identity, endpoint, and access telemetry is a different category of engineering work. It belongs to a security-telemetry platform, not to a deception product. Composing that platform's outputs with an ASM product's coverage map and a deception product's palette is what produces a placement plan; no single vendor in any of the three categories has historically had reason to ship the composition. That shape — the composition contract, not a new product category — is what Setu is publishing.

Deception is one application of the graph, not a Setu product

We want to be precise about Setu's posture. Setu is not entering the deception product market. We do not build, host, or operate lures of any kind. The substrate underneath deception is one of several downstream capabilities the same event graph enables — detection narration, vulnerability prioritisation, blast-radius attestation, and others — and those are described elsewhere. We surface deception placement specifically because RBI's framework names it explicitly, the unsolved half of it is a graph problem, and the buyers in the Indian BFSI sector are actively asking the question.

If you run a deception product today, or are evaluating one against your Annex 2 obligations, the placement plan is the substrate you've been asked to bring without anyone telling you where to get it. The honest version of that conversation has three layers — coverage (your ASM), optimization (our graph), and palette (your deception vendor) — and we'd like to talk about how the layers compose for your specific estate.

---

Setu builds the continuously-learning event graph that sits under detection, attestation, and (today's topic) deception placement. Air-gapped and on-prem deployment options are designed for DPDP-bound and sectorally-isolated Indian estates. Reach us at samyoga.ai.