Matrix/Plan/SDF-PL05

SDF-PL05

Deception Architecture Blueprint

advancedDetection Value: lowCost: minimalTime: 1-2 weeks🔗 Network Infrastructure

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 antecedent

The sources describe designing the deception story, engagement environment, network, collection points, and resources before deployment.

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

1

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.

2

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.

3

Specify asset requirements

Define the types and quantities of deception assets needed: honeypots, decoy services, canary token placements, and credential traps.

4

Define integration boundaries

Specify exactly where and how the deception environment connects to production infrastructure, monitoring systems, and incident response workflows.

5

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

cloud-awshcl
# 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

TechniqueTacticRelationship
T1046Network Service DiscoveryDiscoverycounters
T1018Remote System DiscoveryDiscoverycounters

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

🏢On-Premise
☁Amazon Web Services
☁Microsoft Azure
☁Google Cloud Platform
🔄Hybrid Environment
🏭OT/ICS Environment

Tools & Resources

  • Network diagramming tools (draw.io, Lucidchart)
  • Infrastructure-as-code templates for reference
  • Cloud architecture design tools (AWS Architecture Center, Azure Architecture Center)

Quick Stats

Phase
Plan
Difficulty
advanced
Detection Value
low
Cost
minimal
Time
1-2 weeks
ATT&CK Mappings
2