Security Architecture: Frameworks, Patterns and Implementation Guide

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

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 gives 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 is 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:

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:

Azure equivalents:

NIST Cybersecurity Framework 2.0

The NIST CSF 2.0 (2024) defines 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.

Relevance 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)
• Architecture must serve all 5 functions