Study notes - Zero Trust Architecture

Foundations

  • “Never trust, always verify”. Assume the network is hostile and already compromised. Malicious actors are inside and out
  • De-perimiterisation. Move awar from a static network perimeter (“fortress model”) to focus on protecting individual resources

Logical model (NIST reference model)

  • Defined in NIST SP-800-207 (standard reference model)
  • Separate the Control plane where decisions are made from the Data plane where service traffic flows
  • Core components,
    • Policy Decision Point (PDP): which contains the Policy Engine (PE) and the Policy Administrator (PA). This makes the policy decisions
    • Policy Enforcement Point (PEP): The gateway or agent that enforces the decision, allowing or blocking traffic
    • Policy Information Points (PIP): The sources of data (logs, IAM, threat intel) that inform the decision

NIST ZTA model NIST ZTA model - diagram source (mermaid)

Software Defined Perimeter model (CSA SDP)

SDP is a specific ZT implementation specification developed by CSA. Its components and terminology are distinct from general ZTA terms

  • Architecture components

    • SDP Controller: Acts as the PDP / Control plane. It authenticates users/devices and issues tokens
    • SDP Gateway: Acts as the PEP / Data plane. It sits in front of resources and drops all unauthorised traffic
    • Initiating Host (IH): The client/device seeking access
    • Accepting Host (AH): The server/resource being accessed

  • Main technologies

    • Single Packet Authorization (SPA): A mechanism where the first packet identifies the user. If validation fails, the packet is dropped, making the infrastructure “black” (invisible) to attackers
    • mTLS (Mutual TLS): Ensures bidirectional encrypted trust between the client and the gateway

CSA SDP model CSA SDP model - diagram source (mermaid)

CSA SDP deployment models

Label IH (Initiating) AH (Accepting) Scenario
Client-to-Gateway Client Gateway Enterprise VPN Replacement. The most common enterprise model. Connects users to legacy applications in the data centre where agents cannot be installed on the servers themselves.
Client-to-Server Client Server High Security / Cloud Workloads. Provides end-to-end encryption. Ideal for virtualised environments where the organisation has full control to install agents on the specific server OS.
Server-to-Server Server Server IoT & Microservices. Used for backend API communication. Prevents lateral movement by ensuring servers are invisible to unauthorised devices within the cloud or data centre.
Client-to-Server-to-Client Client Server VoIP & Chat. A trusted, centralised server acts as a broker between two clients to manage signalling
Client-to-Gateway-to-Client Client Gateway P2P Collaboration. Similar to the VoIP model, but uses a generic Gateway to hide client IP addresses for anonymised file sharing or video conferencing.
Gateway-to-Gateway Gateway Gateway IoT & Site-to-Site. Connects entire networks, such as a grid of industrial sensors (which cannot host agents) connecting back to a corporate network.

Five-step implementation methodology

  1. Define the Protect Surface Identify the specific Data, Applications, Assets, and Services (DAAS) to protect. This is the opposite of the Attack Surface
  2. Map transaction flows Determine how data moves across the network to understand where to place controls
  3. Build the architecture Design the ZTA (using SDP or micro-segmentation) tailored to the protect surface
  4. Create Zero Trust policy Use the Kipling Method : Who, What, When, Where, Why, How to write granular access policies.
  5. Monitor and maintain Continuously inspect and log traffic to improve security posture over time

Five pillars of Zero Trust (CISA model)

Implementation is categorised into five pillars and three cross-cutting capabilities, measured at different levels of maturity.

Pillars

Category Component Focus
Pillar 1 Identity Focuses on using identity as the primary factor for access decisions. Ensures that the right users (and non-person entities) have the right access at the right time.
Pillar 2 Devices Focuses on securing the hardware accessing resources. Ensures devices are known, managed, patched, and health-checked before granting access.
Pillar 3 Networks Focuses on segmenting networks and controlling traffic flows. shifts away from a flat trusted internal network to micro-segmentation and encryption.
Pillar 4 Applications & Workloads Focuses on securing the application layer itself (on-prem or cloud). Involves code security, container security, and direct app-to-app access controls.
Pillar 5 Data Focuses on protecting the data at rest and in transit. Involves classification, encryption, and strict access controls based on data sensitivity.

Cross-cutting concerns

Component Focus
Visibility & Analytics The ability to observe traffic and activity across all pillars to detect anomalies and make informed security decisions (SIEM)
Automation & Orchestration The use of tools to automate security responses and policy enforcement across the pillars, reducing manual effort and reaction time (SOAR)
Governance The definition and enforcement of security policies, compliance requirements, and risk management strategies across the entire organisation.

Maturity stages

Maturity Stage Description Characteristics
Traditional Manual and static Reliance on perimeter defences (VPNs, Firewalls). Manual configurations, static policies, and limited visibility. Trust but verify mentality.
Advanced Semi-automated Some cross-pillar coordination and centralized policy enforcement. Introduction of basic automated response and identity-centric controls.
Optimal Automated and dynamic Fully automated, self-healing systems. Continuous validation of identity and device health. Real-time risk analysis drives access decisions. Never trust, always verify.
zta design