Security Architecture: Frameworks, Patterns and Practical Implementation

Security architecture is the disciplined practice of translating security principles into technical and organizational structures. Good security architecture systematically makes attacks more difficult—rather than implementing individual measures in isolation, it creates a coherent framework of protection that remains effective even if individual controls fail.

The Most Important Security Architecture Principles

Basic Principles (timeless, technology-independent):

1. Defense in Depth:
   → Multiple layers of protection: if one fails, the next one protects
   → Not: "The firewall is secure; no protection is needed behind it"
   → Layers: Perimeter → Network → Endpoint → Application → Data
   → An attacker must overcome EVERY layer

2. Least Privilege:
   → Each component is granted ONLY the privileges it needs
   → Service account for DB: SELECT access only on specific tables
   → Admin accounts: separate from user accounts
   → Time-limited privileges (Just-in-Time Access)

3. Separation of Duties:
   → Critical actions require multiple actors
   → No single person can compromise critical systems alone
   → Example: dual-control principle for production deployments

4. Fail Secure:
   → In case of error/failure: deny access instead of granting it
   → Firewall failure: no traffic through (not all traffic!)
   → IPS Fail-Closed: better downtime than unprotected traffic

5. Zero Trust (no implicit trust):
   → "Never trust, always verify"
   → No trust based on network position
   → Every access is verified: identity + device + context

6. Economy of Mechanism (Simplicity):
   → Complex systems have a larger attack surface
   → Prefer simple, verifiable mechanisms
   → Remove every unnecessary component

7. Complete Mediation:
   → EVERY access to EVERY resource is checked
   → No caching of authorization decisions
   → May impact performance—but critical for security

Network Segmentation - Architectural Foundation

Traditional (flat) network architecture - DANGEROUS:

Internet → Firewall → [ Everything on the same /16 network ]
                        → Workstations
                        → Servers
                        → Databases
                        → Printers
                        → IoT devices

Problem: one compromised computer → access to everything!

---

Modern segmented network architecture:

Internet
    │
    ▼
[Perimeter firewall / UTM]
    │
    ├── DMZ (10.0.1.0/24) - publicly accessible services
    │     ├── Web server (10.0.1.10)
    │     ├── Mail gateway (10.0.1.20)
    │     └── VPN gateway (10.0.1.30)
    │
    ├── Server zone (10.0.2.0/24) - internal servers
    │     ├── Application servers (10.0.2.10-50)
    │     ├── File Server (10.0.2.60)
    │     └── AD Controller (10.0.2.70-71)
    │
    ├── Database Zone (10.0.3.0/24) - accessible only from the App Zone
    │     ├── SQL Server (10.0.3.10)
    │     └── ERP DB (10.0.3.20)
    │
    ├── Client Zone (10.0.10.0/23) - Workstations
    │     ├── Management VLAN (10.0.10.0/24)
    │     └── User VLAN (10.0.11.0/24)
    │
    ├── Management Zone (10.0.100.0/24) - Out-of-Band Management
    │     ├── IPMI/iDRAC (Server Management)
    │     ├── SIEM (10.0.100.10)
    │     └── Jump Host (10.0.100.20) - sole gateway to the Server Zone
    │
    └── IoT/OT Zone (10.0.200.0/24) - no connection to the office network
          ├── Printers, cameras
          └── Production equipment (OT)

Firewall rules between zones:
  Client → Server:     only specific ports (HTTP/HTTPS, SMB for file servers)
  Server → DB:         only DB ports from defined app servers
  IoT → All:        NO outbound traffic (only Internet updates via proxy)
  DMZ → internal:       NO direct access (DMZ must be breached first)
  Management:          accessible only from the jump host

Zero Trust Architecture (ZTA)

Zero Trust Architecture according to NIST SP 800-207:

Core Components:

Policy Engine (PE):
  → Decides: Access granted or denied?
  → Considers: Identity, device state, context, risk
  → Example: Microsoft Entra Conditional Access

Policy Administrator (PA):
  → Enforces the PE’s decision
  → Creates/deletes communication paths
  → Manages session tokens

Policy Enforcement Point (PEP):
  → Sits between the resource and the subject
  → Blocks traffic until the PE grants permission
  → Example: ZTNA gateway, API gateway

Zero Trust evaluation for every access attempt:

Request: User → Application
    │
    ▼
[Identity Broker (e.g., Entra ID)]
    → Is the user known?
    → Is MFA fulfilled?
    → Is the account not compromised? (UEBA signal)
    │
    ▼
[Device Compliance (e.g., Intune)]
    → Is the device registered in MDM?
    → Is the OS currently patched?
    → Is EDR active?
    → No jailbreak/rooting?
    │
    ▼
[Context Engine]
    → Normal work location? (Geo-IP)
    → Normal time of day?
    → Normal behavior pattern?
    → Risk score from UEBA?
    │
    ▼
[Policy Decision]
    → All checks OK → Access to THIS app granted
    → Check failed → Step-up auth (MFA) or denial
    → High risk → Quarantine, SOC alert

Result: User can use THIS app
          BUT NOT the entire network!

Identity-Centric Security Architecture

IAM as the foundation of modern security architecture:

Identity Provider (IdP):
  → Single Source of Truth for all identities
  → On-premises: Active Directory, LDAP
  → Cloud: Microsoft Entra ID, Okta, Google Workspace
  → Hybrid: AD + Azure AD Sync

Privileged Access Management (PAM):
  → All admin accounts in PAM vault (CyberArk, BeyondTrust, Hashicorp Vault)
  → Just-in-Time (JIT): Admin privileges granted for only 30 minutes
  → Session recording: All admin sessions recorded
  → Credential checkout: Automatically rotating passwords

Service Account Management:
  → No one knows the service account password
  → Secrets Manager (Vault, AWS Secrets Manager) manages credentials
  → Automatic rotation: every 90 days or upon suspicion
  → Least privilege: Service accounts have only the access they need

Conditional Access Matrix Example:

User Type      App              Device          Location    Result
Admin         AD Console       Managed PC      Office        Allowed
Admin         AD Console       Unmanaged       External      Denied
User          Office365        Managed PC      Anywhere     Allowed
User          Office365        Unmanaged       External      MFA required + browser-only
User          SAP ERP          Unmanaged       External      Denied

Cloud Security Architecture

AWS Multi-Account Strategy (Landing Zone):

┌─────────────────────────────────────────────────────────────────┐
│ AWS Organizations                                               │
│                                                                 │
│  ┌─────────────┐  ┌──────────────┐  ┌──────────────────────┐  │
│  │ Management  │  │   Security   │  │      Workload        │  │
│  │  Account    │  │   Account    │  │    OU                │  │
│  │ (Billing,   │  │ (GuardDuty,  │  │  ┌────┐ ┌────┐     │  │
│  │  Org SCPs)  │  │  SecurityHub,│  │  │Dev │ │Prod│     │  │
│  └─────────────┘  │  CloudTrail) │  │  │    │ │    │     │  │
│                   └──────────────┘  │  └────┘ └────┘     │  │
│                                     └──────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘

Consolidated Security Account:
  → GuardDuty: all accounts → Security Account
  → CloudTrail: all accounts → central S3 (immutable)
  → SecurityHub: all findings aggregated
  → Config: compliance rules for all accounts

Key AWS security services:
  GuardDuty:       Threat detection (ML-based)
  SecurityHub:     Compliance + finding aggregation
  Macie:           S3 data protection (PII detection)
  IAM Access Analyzer: external access to resources
  CloudTrail:      API audit log (IMMUTABLE!)
  VPC Flow Logs:   Network traffic in AWS
  Config:          Resource change tracking

Azure equivalents:
  GuardDuty   → Microsoft Defender for Cloud
  CloudTrail  → Azure Activity Log + Diagnostic Settings
  SecurityHub → Microsoft Sentinel
  IAM         → Azure AD + Azure RBAC
  VPC Logs    → NSG Flow Logs

NIST Cybersecurity Framework 2.0

NIST CSF 2.0 (2024) - 6 Functions:

GOVERN (new in 2.0):
  → Cybersecurity Risk Management Strategy
  → Roles and Responsibilities
  → Policies, Processes, Procedures

IDENTIFY:
  → Asset Management: Inventory all assets
  → Risk Assessment: What are our risks?
  → Supply Chain Risk Management
  → Vulnerability Management

PROTECT:
  → Identity Management and Access Control
  → Awareness Training
  → Data Security (Encryption, DLP)
  → Platform Security (Patches, Hardening)
  → Technology Infrastructure Resilience

DETECT:
  → Continuous Monitoring
  → Adverse Event Analysis
  → SIEM/NDR/EDR

RESPOND:
  → Incident Response Plan
  → Incident Analysis
  → Incident Mitigation
  → Improvements

RECOVER:
  → Disaster Recovery
  → Backup and Restore
  → Communication During Recovery

Relevant to Security Architecture:
  → IDENTIFY: No architecture without a complete asset inventory
  → PROTECT: The technical controls (what we build)
  → DETECT: The monitoring layer (what we can see)
  → Context: Architecture must serve all 5 functions