Engineered for adversarial environments.
This page covers the engineering depth behind four parts of the platform that most security vendors keep shallow: how decoys avoid getting burned, how the detection pipeline produces decisions in seconds without dropping signal, how SIEM exports are verified instead of fire-and-forget, and how every incident is scored on what the business actually loses.
Decoys that don't get burned.
The fastest way to break a deception program is to deploy honeypots adversaries can identify in seconds. Default banners, empty filesystems, suspicious uptime, generic hostnames — every serious adversary runs preflight checks before committing, and most honeypots fail them. The Realism Engine is the part of the platform that defeats those checks. What's described here is a slice; the techniques tailored to specific host types — domain controllers vs. file servers vs. industrial controllers vs. network gear — stay out of public view because that's the part adversaries can't read in a brochure.
Examples of tells we actively defeat
| Adversary check | What gives most honeypots away | What the Realism Engine does |
|---|---|---|
| Hostname inspection | Names like “honey-srv-01” or “decoy-c2f9eead” are pattern-matchable in seconds | Hostname generator rejects burned patterns at deploy time; per-tenant naming templates apply industry-appropriate conventions |
| Service banner inspection | Stock SSH banners, default web server headers, mismatched OS strings | Per-industry banner overrides ship distro-appropriate version strings instead of vendor defaults |
| System inventory checks | Empty process list, missing OS metadata, default uptime values | Per-host-type system state populated to match the role being emulated |
| Filesystem reconnaissance | Empty home directories, missing logs, no documents | Content packs populate file shares, home directories, system logs, and database schemas with realistic synthetic data |
| Endpoint security checks | A “corporate workstation” with no EDR signatures present | Simulated EDR/agent presence per claimed environment, tunable per deployment |
| Network fingerprint scans | TCP/IP fingerprint reveals an OS that doesn’t match the claimed banner | Fingerprint profiles align low-level network characteristics with the OS being emulated |
| Activity heuristics | Decoy is silent — no logins, no scheduled jobs, no AD chatter | Synthetic activity engine generates traffic patterns matched to the host’s role and business hours |
This table covers surface checks. Several additional check classes are handled but not enumerated here.
How realism is organized
Five components, each addressing a different class of adversary check. Realism is applied per-host-type — a Windows domain controller, a Linux file server, a network switch, and an industrial controller all get materially different treatment, because they answer differently to the same adversary probe.
Naming Convention Templates
Auto-generate hostnames, FQDNs, and account names that match your organization’s patterns. Industry presets ship for corporate, healthcare, financial, and OEM environments; tenants can author custom templates with per-protocol patterns. The hostname engine refuses to deploy any decoy that would match an obvious deception pattern.
Fingerprint Profiles
A library of OS profiles spanning Windows Server and Workstation, multiple Linux distributions, and major network gear (Cisco, Juniper, Palo Alto, Fortinet, F5). Each profile aligns network-layer fingerprint, service banners, and certificate metadata so adversary scanning tools agree with the claimed identity.
Content Packs
Pre-built realistic content per decoy class. File-share packs ship with departmental directory trees populated with backdated documents. Database packs ship table schemas matching common enterprise applications with realistic record counts. SSH packs include per-user home directories, command history, scheduled jobs, and backdated system logs.
Synthetic Activity Engine
Generates traffic patterns so decoys don’t appear dormant. Configurable per business hours and time zone: simulated user logins, file access, DNS queries, directory-service beacons, application logs, scheduled patch checks. Activity profiles bind to decoys at deploy time and run independently per asset.
Breadcrumb Generator
Produces deployable scripts that plant trails on real machines so adversaries find decoys naturally. Multiple breadcrumb types ship today, spanning credential planting in scripts and config files, desktop shortcuts, system file references, and cloud-credential placement. Each script is generated with proper escaping for the target shell, includes realistic aging metadata, and ships with a paired cleanup script.
The realism techniques specific to particular host types — what makes domain-controller emulation different from file-server emulation different from PLC emulation, and the unpublished checks we defeat that aren't in the table above — stay private by design. If a defender can read the technique on our marketing page, so can the adversary. Detail at that level lives in the engagement, not the brochure.
Eight workers, one decision in seconds.
A raw detection event is not yet an incident. It needs classification, correlation, scoring, profiling, enrichment, and the right surface — fast, in order, and without dropping signal under load. Most platforms run this as a single async pipeline that backs up under burst load and produces inconsistent ordering. Ours runs as eight independent workers, each with its own cadence, instrumentation, and failure surface.
| Stage | Cadence | What it decides |
|---|---|---|
| Mapper | 2s | MITRE ATT&CK technique classification — the same event observed at SSH, RDP, or SMB resolves to a different technique mapping per protocol |
| Incidentizer | 5s | Deduplication and correlation — multiple detections from the same source within a window collapse into a single incident |
| Consequence | 30s | CRM-based risk scoring (see Consequence Risk Model below) |
| Profiler | 30s | Adversary session building — groups detections by source IP into sessions with TTPs, dwell time, and persistence scoring; produces SOC advisories per actor |
| Scoring | 5min | Coverage scoring across the MITRE matrix and detection effectiveness recalibration |
| Deployer | 10s | Decoy deployment orchestration, configuration updates, and per-asset health checks across the collector fleet |
| Inventory | 60s | Asset inventory synchronization and network topology mapping |
| Threat Intel | 5min | IOC correlation across multiple commercial and community sources with result caching |
Why we split it this way
Independent failure surfaces
A slow MITRE classification doesn’t block a containment decision waiting on the consequence scorer. Each worker degrades alone instead of taking the pipeline with it.
Per-stage instrumentation
Every worker emits per-iteration Prometheus metrics — cadence, duration, error count. Degradation is visible per stage, not buried in an aggregate latency curve.
Never fail silently
When a stage degrades, an alert fires automatically with severity tied to whether the degradation is silent or visible to users. Silent failure modes are architecturally prevented, not hoped against.
Per-stage failure-mode handling, worker-level adaptive cadence under burst load, and the cross-worker write-through cache that keeps shared enrichment state warm stay out of the public description. The pipeline is engineered to degrade visibly, not to silently lose signal.
Push, then verify. Then verify again.
Most security platforms export a detection rule to your SIEM and stop there. The rule's lifecycle becomes invisible. If a SIEM admin disables it during a busy week, you find out at the next audit. If the SIEM swallows the rule under a query budget, you find out when the breach surfaces. Closed-loop verification treats the export as the start, not the end.
What we verify per export
| Check | What it answers | Where the data comes from |
|---|---|---|
| Existence | Does the rule still exist in the SIEM under the ID we assigned? | Adapter-specific REST endpoint per SIEM |
| Enabled state | Is the rule active, or has it been disabled? | Per-SIEM disabled flag (Splunk’s saved-search disabled, Sentinel’s enabled, Elastic’s enabled) |
| Fire count | Has the rule produced any alerts since last check? | Per-SIEM history endpoint or signals index |
| Drift | Has the query body been modified by a SIEM operator? | Hash-compare against the version we exported |
Each verification produces one of four outcomes — active, disabled, not_found, or error. Drift becomes visible in the dashboard within 24 hours, not at audit time.
Adapters supported today
Adapter-specific quirks (how Splunk versions return the disabled flag, the Sentinel KQL-translation rules, the Elastic API rate-limiting strategy) live in adapter implementations. The point that matters: every export becomes a tracked artifact with a measurable lifecycle, not a fire-and-forget push.
Score what the business actually loses.
Most security platforms score incidents on technical severity — high, medium, low — and let humans translate to business impact. That translation is where alerts become noise. CRM v1.0 scores every incident on the four dimensions that drive containment urgency, with explainable per-factor breakdown so the score can be defended in a board room.
Four dimensions
| Dimension | Weight | What it measures |
|---|---|---|
| Impact | 35% | Composite of detection severity, asset criticality, data classification, and consequence category (Safety / Regulatory / Financial / Operational / Reputational / Informational) |
| Likelihood | 30% | Detection confidence, retrigger persistence (how many times the same actor returned), and dwell time |
| Exposure | 20% | Network zone (DMZ / internal / management / external / isolated), environment (production / staging / dev / lab), and decoy-vs-production context |
| Confidence | 15% | Mapping quality (how cleanly the detection mapped to MITRE) and source diversity (independent corroboration across sensors) |
How the dimensions interact
High-confidence intrusion, production asset, restricted data
Internal-zone production asset with a high-confidence detection and restricted data classification scores in the 90s — board-relevant, immediate containment.
Low-confidence brushing of a DMZ decoy
External decoy with a single low-confidence interaction and no persistence scores in the 20s — informational, no SOC pager.
Internal decoy in a coverage blind spot
An internal decoy hit by a technique your production sensors don’t cover scores HIGHER than an external decoy with full coverage — because the former signals an in-environment intrusion in a blind spot.
Every score ships with the per-factor breakdown so a CISO or auditor can ask “why did this incident score 87?” and get an answer.
Per-tenant calibration weights, asset-criticality scoring inputs, and the decoy/coverage interaction rules stay out of the public description. CRM v1.0 is the published doctrine; the calibration that adapts it to a specific environment lives in the engagement.
We measure whether each of these is working.
Realism tracks per-protocol adversary preflight outcomes. The pipeline emits per-stage iteration metrics. SIEM verification produces fire-count and drift data per export. CRM scores ship with full factor breakdown. None of these components are evaluated on whether they shipped — they're evaluated on whether they move the metric they're supposed to move.
Platform security controls live on the Security page.
Tenant isolation, encryption, audit logging, and SOC 2 compliance evidence are documented separately. This page covers detection engineering; that one covers platform security.
Want to go deeper?
The per-host-type tuning, calibration knobs, and unpublished techniques that make these components actually work in a specific environment live in the engagement, not on a marketing page. Get in touch and we'll walk through the parts that matter for yours.