FortiDeceptor builds deception environments from decoy virtual machines, deception operating systems, lure resources, tokens/breadcrumbs, deployment networks, incidents, events, and campaigns. The approved title uses “deception policies” as an operating concept: decide which decoys and lures should appear in each network segment, which real endpoints receive tokens, what attacker behaviors matter, and how interaction with deception assets is routed into incident response.
Within Fortinet Security Operations, deception should produce high-confidence signals because legitimate users and applications should have little reason to interact with decoy assets. The design challenge is making decoys believable enough to attract attackers while isolated enough that they cannot become infrastructure for attacking production.
The current FortiDeceptor 6.2 documentation describes decoy VMs, lures, token packages, events, incidents, and campaigns as the main building blocks.
Place decoys where attackers would expect real assets
A deception environment should mirror network segments and technologies that exist in production: Windows/Linux servers, OT/IoT where relevant, application/database services, remote access, or other supported decoy operating systems.
Do not deploy one generic decoy subnet far away from real workloads and expect lateral-movement attackers to find it naturally.
Use network topology and threat models to place believable decoys near high-value attack paths without exposing real secrets.
Deployment networks should be isolated but reachable
FortiDeceptor deployment networks define where decoy VMs live and are monitored.
Allow the attacker path needed to interact with the decoy while restricting the decoy’s ability to reach sensitive production systems.
Firewalls and routing should prevent a compromised decoy from becoming a pivot platform if an attacker attempts to use it operationally.
Lures make decoys look like real user environments
FortiDeceptor lures can add services, applications, users, documents, and other artifacts to a decoy.
The current Deception module supports lure resources and automatically generated lure content from uploaded Word/PDF resources.
Use believable but synthetic names and business context; never put actual passwords, customer data, or production keys into lure content.
Tokens extend deception onto real endpoints
FortiDeceptor token packages place breadcrumbs on real Windows, Linux, or macOS systems that point attackers toward decoys.
Examples include cached-looking credentials, RDP/SSH/SMB references, network shares, database connections, data files, or configuration-like artifacts.
Tokens should be invisible to ordinary users and harmless if discovered; treat every token value as intentionally fake and incapable of authenticating to production.
Decoy customization should follow the target environment
FortiDeceptor supports standard and custom decoy images depending on licensing.
Customize banners, users, services, file structures, hostnames, and application clues so an attacker cannot recognize the decoy immediately from obvious defaults.
Keep enough standardization that operations can patch, rebuild, and audit decoys without maintaining dozens of bespoke fake systems manually.
Events, incidents, and campaigns represent different scopes
Current FortiDeceptor terminology distinguishes an Event as one action, an Incident as actions on one decoy/victim host, and a Campaign as related incidents representing lateral movement.
Use the campaign view when an attacker touches several deception assets or follows tokens between hosts.
This can reveal attacker intent, tools, credentials tested, and movement sequence more clearly than isolated alert records.
Deception alerts should be high-priority but still verified
Interaction with a well-placed decoy is unusual and should receive rapid investigation.
But vulnerability scanners, IT inventory, backup, monitoring, or red-team tools can touch decoys legitimately.
Baseline these known systems and create narrow exclusions so genuine attacker engagement stays low-noise rather than normalizing constant benign alarms.
Tokens and lures should have lifecycle ownership
A token deployed on a real endpoint can outlive the project or application it imitates.
Inventory token package version, endpoint scope, lure target, owner, and removal plan.
Review after workstation rebuilds, network migrations, or decoy replacement so endpoints do not contain dead breadcrumbs pointing to nonexistent infrastructure.
Deception should feed broader investigation
When a deception alert fires, pivot into identity logs, EDR/XDR, DNS, firewall, email, cloud audit, and vulnerability context.
Threat Detection and Incident Workflows is the useful companion model: a deception interaction is a strong signal, but responders still need to establish entry point, scope, persistence, and impact.
Preserve the decoy’s recorded actions before rebuilding or resetting it.
Red-team exercises should validate the deception strategy
Give an authorized tester a foothold in a segment and see whether realistic enumeration discovers lure breadcrumbs and decoys.
Measure time to interaction, event fidelity, SOC response, and whether decoy isolation holds.
If testers consistently bypass the deception because assets are obviously fake, adjust placement and realism rather than increasing alert severity.
FortiDeceptor succeeds when attackers reveal themselves by choosing the fake path
The mature program places realistic decoys near credible attack paths, distributes synthetic tokens carefully, isolates decoys, monitors events/incidents/campaigns, tunes known scanners, and integrates every interaction with broader response.
Deception is strongest when legitimate operations almost never touch the environment and attacker exploration naturally does.
Decoy density should be proportional to the attack paths that matter. A flat environment with hundreds of identical fake hosts can look artificial and create management overhead. Prioritize identity infrastructure, file shares, database/admin networks, remote-access zones, OT/IoT segments, and other places where lateral movement toward valuable systems is plausible. The goal is not the maximum number of decoys; it is the highest probability that attacker discovery touches one.
Decoy naming should look realistic without colliding with production. Use patterns consistent with business naming conventions, but reserve a namespace or inventory marker known to defenders so operations never mistakes a decoy for a real system. Avoid names such as HONEYPOT01 that teach attackers immediately, and avoid cloning a real hostname/IP that can create network or incident confusion.
Credentials used in lures must be synthetic and scoped only to deception assets. Never embed an actual service account or production password as bait. If the attacker uses the fake credential, the authentication attempt itself should become high-confidence evidence. Rotate or retire lure credentials with the decoy lifecycle so old values do not appear in unrelated systems.
Endpoint token deployment should be change-managed with EDR, antivirus, and application teams. Breadcrumb files or connection artifacts can be flagged, cleaned, or copied by endpoint-management tooling. Pilot token packages on representative workstations/servers and verify they remain invisible to users while still discoverable to attacker tools and enumeration behavior.
Deception incidents should include network context beyond the decoy. Capture the source host, user, source IP, process or protocol, attempted credentials, commands, files touched, and follow-on connections. Correlate immediately with real-asset telemetry because the source endpoint may already be compromised even though the attacker touched only fake data on the decoy.
Campaign analysis can reveal lateral-movement strategy. When one actor engages several decoys or uses a lure from a real endpoint to reach a decoy, preserve the sequence. That sequence can show reconnaissance style, credential usage, preferred protocols, and command-and-control behavior that normal alerts would fragment across systems.
Deception infrastructure itself should be patched and monitored even though it is fake. Decoys intentionally expose services and may be attacked deeply. Isolation limits risk, but do not let a deliberately vulnerable service become a real foothold into management networks, logging systems, or the FortiDeceptor appliance. Separate management interfaces and credentials from deception traffic.
Red teams should test whether defenders can distinguish a real compromise from automated scanning. Run both scenarios: a scanner touching one decoy port and an operator following lure credentials across several steps. Validate that event, incident, and campaign views produce enough evidence for the SOC to prioritize the second path without ignoring the first.
Deception policy should have a retirement process. When an application, subnet, operating system, or protocol disappears from the real environment, remove or redesign corresponding decoys. Stale fake assets can train analysts on attack paths that no longer exist and make the deception environment increasingly unlike the network it is meant to mirror.
Decoy telemetry should be time-synchronized and forwarded centrally. Campaign reconstruction becomes difficult when deception events, endpoint logs, firewall sessions, and identity events disagree on time. Use trusted NTP and retain FortiDeceptor logs long enough to correlate slow reconnaissance that spans days or weeks.
Credential lure use should trigger rapid rotation checks on real credentials with similar names or roles. Even though lure credentials are fake, an attacker who tests them may also be trying password spraying or credential stuffing elsewhere. Hunt for related authentication attempts from the same source, host, or time window.
Deception should not create compliance surprises. If decoy systems imitate sensitive databases or regulated applications, use synthetic content and confirm that monitoring tools, backup systems, and audit reports clearly distinguish them from real records. Fake data should never be mistaken for production evidence.
Deception alerts should be included in after-hours escalation because attacker interaction with a well-designed decoy is inherently unusual. Define who gets paged, what evidence to collect first, and when to isolate the source endpoint. Delay erodes the main advantage of deception: detecting lateral movement earlier than conventional controls.
Keep management access to FortiDeceptor separate from deception networks. Administrative interfaces, backups, update services, and log forwarding should use trusted management paths that attackers interacting with decoys cannot reach. The deception plane should never provide a route toward the system that controls it.
