Security Architecture — Defence in Depth and Zero Trust

Security architecture is the discipline of designing systems so that when one control fails — and eventually one will — the attacker is still contained. The offensive modules taught you how attackers move from a foothold to domain admin. Security architecture is the discipline of making each of those steps harder, slower, more detectable, or impossible.

The shift from security as a checkbox to security as an architectural property is the inflection point in a security career. A security architect does not just add a firewall — they ask: "If an attacker gets through the firewall, what do they find? If they compromise that application server, what can they reach from there? If they steal credentials, what can they do with them?" The answers determine which controls to build and where.

Defence in Depth — Layered Controls

Defence in depth means deploying multiple independent security controls so that an attacker must defeat several layers to achieve their objective. No single control is assumed to be reliable. The layers slow attackers, generate detection signals, and limit blast radius.

The bypass column is as important as the controls column. Every layer has weaknesses. The architecture question is not "does this control work?" but "if this control fails, what does the attacker find next, and does the next layer detect or contain them?"

Zero Trust Architecture

Traditional network security assumed that traffic inside the corporate network perimeter was trustworthy. Zero Trust (ZT) rejects this assumption entirely: no user, device, or network segment is trusted by default — all access is verified explicitly, every time.

The driver for Zero Trust adoption is the collapse of the perimeter: remote work, cloud services, contractor access, and mobile devices mean most enterprise traffic now flows outside the traditional corporate network. The old model of "trust inside, verify outside" is structurally broken.

NIST SP 800-207 defines Zero Trust through seven tenets:

In practice, Zero Trust is implemented progressively — it is a journey, not a switch. Most organisations start with identity (strong MFA everywhere), then add device compliance checks, then micro-segment applications, and eventually reach continuous monitoring with automated access revocation.

Zero Trust implementation priority order (most impact first):

1. Identity — Deploy MFA everywhere, especially for admin access.
   Tools: Okta, Microsoft Entra ID, Duo Security, CrowdStrike Identity

2. Device compliance — Only allow devices that meet baseline health requirements.
   Checks: EDR installed, OS patched, disk encrypted, screen lock active
   Tools: Microsoft Intune, Jamf, CrowdStrike Falcon Device Control

3. Application access — Replace VPN with identity-aware proxies.
   Users access specific applications, not network segments.
   Tools: Cloudflare Access, Zscaler Private Access, Google BeyondCorp

4. Micro-segmentation — Prevent lateral movement between workloads.
   East-west traffic filtered; services only communicate with named peers.
   Tools: Illumio, Guardicore, AWS Security Groups, Kubernetes NetworkPolicy

5. Data classification — Know what data you have and where it lives.
   Apply access controls at the data level, not just the application level.
   Tools: Microsoft Purview, Varonis, BigID

Network Segmentation Architecture

Network segmentation limits lateral movement: if an attacker compromises a web server, they should not be able to directly reach the database server, the domain controller, or the backup infrastructure. Segmentation is one of the most effective compensating controls for the inevitability of some level of compromise.

Enterprise network segmentation model:

                    INTERNET
                        │
              ┌─────────┴─────────┐
              │    PERIMETER      │
              │  Firewall + WAF   │
              └─────────┬─────────┘
                        │
              ┌─────────┴─────────┐
              │       DMZ         │  ← Internet-facing services only
              │  Web, API, CDN    │  ← No access to internal from here
              └─────────┬─────────┘
                        │ (explicit allow rules only)
              ┌─────────┴─────────┐
              │   APPLICATION     │  ← App servers talk only to DB segment
              │   SEGMENT         │  ← No access to management segment
              └─────────┬─────────┘
                        │ (port 5432 / 3306 only, to specific IPs)
              ┌─────────┴─────────┐
              │    DATA SEGMENT   │  ← DB servers, storage
              │                   │  ← No outbound internet access
              └───────────────────┘

              ┌───────────────────┐
              │  MANAGEMENT       │  ← Separate, jump server access only
              │  SEGMENT          │  ← AD, SIEM, backup, monitoring
              │  (Tier 0 AD)      │  ← Physical/VPN access from Tier 0 PAW only
              └───────────────────┘

Rules between segments:
  DMZ → Application:      Allowed: TCP 443 (API), TCP 8080 (internal API)
  Application → Data:     Allowed: TCP 5432 to db01.internal only
  Application → Internet: Denied (no direct internet access from app servers)
  Management → All:       Allowed from jump servers only (specific IPs)
  All → Management:       Denied except monitoring agents (UDP 514 syslog, TCP 9200 SIEM)

Cloud-native segmentation uses security groups, network policies, and service meshes instead of physical VLANs:

# AWS Security Groups — micro-segmentation example
# Allow web servers to only receive traffic from the ALB
resource "aws_security_group" "web" {
  ingress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]  # only from ALB
  }
  egress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.database.id]  # only to DB
  }
}

# Kubernetes NetworkPolicy — deny all, then allow explicitly
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}       # applies to all pods in namespace
  policyTypes:
  - Ingress
  - Egress
  # No rules = deny all ingress and egress
---
# Allow specific communication:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-server
    ports:
    - port: 5432

Security Control Frameworks

Rather than inventing security controls from scratch, architects use established frameworks that map controls to threat categories. These frameworks also serve as audit baselines for compliance.

For a US-market security architect, knowing CIS Controls and NIST CSF is baseline. MITRE ATT&CK is increasingly used in job descriptions because it provides a common language for discussing specific threat techniques and their mitigations.

Secure Architecture Patterns

Certain architectural patterns appear repeatedly in well-secured systems. These are not vendor products — they are structural decisions that reduce attack surface regardless of what software is deployed.

Bastion Host / Jump Server

All administrative access to production systems routes through a single, highly hardened jump server with MFA, session recording, and full audit logging. Direct SSH/RDP to production from developer workstations is prohibited.

Jump server architecture:
  Developer laptop → MFA → Jump server (session recorded) → Production server

  Jump server controls:
  - MFA required for every session
  - All keystrokes logged and stored for 1+ year
  - No internet access from jump server
  - Privileged Access Workstation (PAW) for Tier 0 (AD, backup, SIEM management)
  - Jump server itself is Tier 0 — managed identically to the DC

  Tools: CyberArk, Delinea (Thycotic), AWS Systems Manager Session Manager,
         HashiCorp Vault SSH secrets engine, BeyondTrust

Immutable Infrastructure

Production servers are never patched or configured in place — they are replaced. When a new version is ready, a new server image is built, tested, and swapped in. The old server is terminated. Attackers cannot persist on a server that is replaced every deployment cycle.

Immutable infrastructure security properties:
  - No SSH access to running production instances (nothing to log into)
  - Attackers cannot persist across deployments (15-minute TTL with frequent deploys)
  - Configuration drift is impossible — every server matches the golden image
  - Secrets injected at runtime from secrets manager, not baked into image
  - All config changes via version-controlled IaC (Terraform, Pulumi)
    → every change has a PR, review, and audit trail

  Implementation:
  - Docker/Kubernetes: rolling updates replace containers with new image builds
  - EC2: Auto Scaling Group + Launch Template, terminate on config change
  - Golden image pipeline: Packer builds → AMI → staging test → production rollout

Secrets Management Architecture

Every service authenticates to a centralised secrets manager using its platform identity (IAM role, Kubernetes service account) — no static credentials anywhere.

Secrets management architecture:
  ┌──────────────────────────────────────────────────────────┐
  │ Service (on EC2/ECS/Lambda)                              │
  │   → Has IAM role (no static credentials)                │
  │   → Role has policy: secretsmanager:GetSecretValue      │
  │     for arn:aws:secretsmanager:us-east-1:123:secret:    │
  │     prod/myapp/database only                            │
  └──────────────┬───────────────────────────────────────────┘
                 │ (uses instance metadata service v2)
  ┌──────────────┴───────────────────────────────────────────┐
  │ AWS Secrets Manager                                      │
  │   → Stores encrypted database credentials               │
  │   → Rotation: Lambda rotates DB password every 30 days  │
  │   → Audit: CloudTrail logs every GetSecretValue call    │
  │   → Access log: "which service accessed which secret    │
  │     at what time" — detect anomalous access             │
  └──────────────────────────────────────────────────────────┘

Security properties:
  - Credentials never stored in environment variables, config files, or source code
  - If service is compromised: attacker gets temporary IAM credentials that expire
  - If credentials are rotated: old credentials become invalid within minutes
  - Audit trail: every secret access is logged in CloudTrail with caller identity

Architectural Anti-Patterns — What Not to Build

As important as knowing what to build is recognising patterns that create structural vulnerabilities:

Interview Questions — Security Architecture

Common Mistakes — Security Architecture