Decide whether FMC-specific inert persona coverage adds value beyond existing ASA and HTTP decoys

[Xore]

Follow-up to #3180. Research proposal, not implemented or live-validated.

F3 — P2 decision, not exploit emulation

Title: Decide whether FMC-specific inert persona coverage adds value beyond existing ASA and HTTP decoys

Labels: security, honeypot, decision, enhancement

Proposal: Document the fidelity, isolation, provenance and maintenance requirements for an optional non-vulnerable management persona. Start with a static design/coverage decision; do not implement exploit-specific authentication bypass, object deserialization, command execution, network callbacks or a vulnerable FMC image. Preserve Conpot/Dionaea/ASA behavior and distinguish the product identity explicitly. Scope any future synthetic management actions as simulations with no firewall side effects. A negative decision is an acceptable result.

Safe synthetic-event acceptance criteria:

• A static surface inventory separates internal listening ports, host publications and intended public routing, with no live probes.
• A fixture for an ASA event stays ASA; sharing a management port or Cisco branding never changes it to FMC.
• A proposed FMC event has explicit persona and simulation provenance and uses no real credentials, certificate keys or production names.
• The decision states which coverage gaps a persona addresses (attraction/context) and which it cannot (real bypass success, actual policy changes).
• The design prohibits outbound request-following, execution and deserialization, keeps resource limits, and requires separate deployment authorization before exposure.

Snapshot assessed: 00593d1d693cc7fe792beb7d24724dca5f55b2b8. Evidence paths are relative to APIARY. All acceptance tests must be offline and use inert fixtures; no exploitation, credentials, appliance access or deployment is authorized.