Description
Design the overall architecture of the deception environment, including network topology, asset types and quantities, integration points with production infrastructure, and monitoring coverage requirements.
Rationale
An architecture blueprint prevents ad-hoc deployments that create coverage gaps and maintenance burdens. It ensures that the deception environment is coherent, maintainable, and aligned with the objectives and threat profiles developed earlier in the planning phase.
Supporting Basis
Direct antecedentThe sources describe designing the deception story, engagement environment, network, collection points, and resources before deployment.
- Almeshekah, M.H.; Spafford, E.H. Planning and Integrating Deception into Computer Security Defenses. NSPW 2014.Peer reviewed
- The MITRE Corporation. A Practical Guide to Adversary Engagement, version 1.0. 2022.Technical guide
These sources establish design lineage and scope. They do not validate this record's operational effectiveness, planning estimates, environment labels, or ATT&CK relationships.
Implementation Steps
Map production reference architecture
Document the production environment architecture that the deception environment needs to mirror or complement. Include network topology, service inventory, and authentication infrastructure.
Design deception network topology
Design the shadow network segments, subnets, and routing that will host deception assets. Ensure isolation from production while maintaining believable connectivity.
Specify asset requirements
Define the types and quantities of deception assets needed: honeypots, decoy services, canary token placements, and credential traps.
Define integration boundaries
Specify exactly where and how the deception environment connects to production infrastructure, monitoring systems, and incident response workflows.
Create the blueprint document
Produce a comprehensive architecture blueprint that serves as the build specification for the preparation phase.
Technical Implementation Examples(1)
Deception Network Architecture - Terraform Scaffold
High-level Terraform structure for planning a deception network architecture alongside production
# deception-architecture/main.tf
# Architecture blueprint: deception VPC deployed alongside production
# This scaffold defines the high-level structure for planning purposes
terraform {
required_providers {
aws = { source = "hashicorp/aws", version = "~> 5.0" }
}
}
variable "production_vpc_id" {
description = "ID of the existing production VPC"
type = string
}
variable "production_vpc_cidr" {
description = "CIDR block of the production VPC"
type = string
default = "10.0.0.0/16"
}
# --- Deception VPC ---
# Separate VPC for deception assets with controlled peering
resource "aws_vpc" "deception" {
cidr_block = "10.200.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
tags = {
Name = "shadow-cdf-deception-vpc"
Environment = "deception"
ManagedBy = "shadow-cdf-matrix"
}
}
# Subnets mirror production naming to appear legitimate
resource "aws_subnet" "deception_web_tier" {
vpc_id = aws_vpc.deception.id
cidr_block = "10.200.10.0/24"
availability_zone = "us-east-1a"
tags = { Name = "prod-web-tier-02" } # Blends with production naming
}
resource "aws_subnet" "deception_db_tier" {
vpc_id = aws_vpc.deception.id
cidr_block = "10.200.20.0/24"
availability_zone = "us-east-1a"
tags = { Name = "prod-db-tier-02" }
}
resource "aws_subnet" "deception_mgmt" {
vpc_id = aws_vpc.deception.id
cidr_block = "10.200.99.0/24"
availability_zone = "us-east-1a"
tags = { Name = "shadow-mgmt" } # Management subnet - not visible to adversaries
}
# Controlled peering: production can route TO deception, but deception
# cannot initiate connections BACK to production
resource "aws_vpc_peering_connection" "prod_to_deception" {
vpc_id = var.production_vpc_id
peer_vpc_id = aws_vpc.deception.id
auto_accept = true
tags = { Name = "prod-deception-peering" }
}
# Security group: allow inbound from production, deny outbound to production
resource "aws_security_group" "deception_isolation" {
name = "deception-asset-isolation"
description = "Allow inbound from prod, block outbound to prod"
vpc_id = aws_vpc.deception.id
# Allow all inbound from production VPC (adversary needs to reach decoys)
ingress {
from_port = 0
to_port = 65535
protocol = "tcp"
cidr_blocks = [var.production_vpc_cidr]
}
# Allow outbound to management subnet only (for log shipping)
egress {
from_port = 0
to_port = 65535
protocol = "tcp"
cidr_blocks = ["10.200.99.0/24"]
description = "Log shipping to management subnet only"
}
tags = { Name = "deception-isolation-sg" }
}
output "deception_vpc_id" { value = aws_vpc.deception.id }
output "deception_web_subnet_id" { value = aws_subnet.deception_web_tier.id }
output "deception_db_subnet_id" { value = aws_subnet.deception_db_tier.id }MITRE ATT&CK Mappings
| Technique | Tactic | Relationship |
|---|---|---|
| T1046Network Service Discovery | Discovery | counters |
| T1018Remote System Discovery | Discovery | counters |
Considerations
- The deception environment does not need to perfectly replicate production. It needs to be convincing enough for the adversary profile you are targeting.
- Plan for scalability. The initial deployment should be achievable with current resources, but the architecture should accommodate growth.
- Document maintenance requirements upfront. Every asset in the blueprint needs an owner and a refresh cycle.
Supported Environments
Tools & Resources
- Network diagramming tools (draw.io, Lucidchart)
- Infrastructure-as-code templates for reference
- Cloud architecture design tools (AWS Architecture Center, Azure Architecture Center)
Related Techniques
Quick Stats
- Phase
- Plan
- Difficulty
- advanced
- Detection Value
- low
- Cost
- minimal
- Time
- 1-2 weeks
- ATT&CK Mappings
- 2