Zero-Trust Architecture Mastery - Expanded Project Guides
Zero-Trust Architecture Mastery - Expanded Project Guides
Goal: Master Zero-Trust Architecture from first principles—understand why perimeter security failed, how identity-based access works, and build production-grade security components that can protect modern distributed systems from both external attackers and insider threats.
Why Zero Trust Matters: The Death of the Perimeter
In 2009, Chinese hackers breached Google’s internal network through a targeted phishing attack (Operation Aurora). They moved laterally for months, accessing Gmail accounts of Chinese human rights activists. Google’s response? Rebuild their entire security architecture from scratch, creating what they called “BeyondCorp.”
The lesson was clear: being inside the network means nothing. An attacker who compromises a single employee laptop gains access to everything that laptop can reach. Traditional security assumed a hard outer shell (firewall) and soft interior (trusted network). Modern attackers proved this model catastrophically wrong.
Traditional Security Model ("Castle and Moat"):
===============================================
INTERNET (Untrusted)
│
┌──────┴──────┐
│ Firewall │ ◀── "If you're past this, you're trusted"
└──────┬──────┘
│
┌──────┴──────────────────────────────────────┐
│ CORPORATE NETWORK │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Laptop │ │ Server │ │ Database│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ▲ ▲ ▲ │
│ └────────────┴────────────┘ │
│ ALL TRUSTED │
│ (Anyone here can reach anything) │
└─────────────────────────────────────────────┘
PROBLEM: Once an attacker gets past the firewall (phishing,
compromised VPN, malicious insider), they can move ANYWHERE.
Zero Trust Model ("Never Trust, Always Verify"):
===============================================
INTERNET
│
│ (No inherent trust based on network location)
│
┌──────┴──────────────────────────────────────┐
│ ALL NETWORKS │
│ (Treated as untrusted) │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Laptop │ │ Server │ │ Database│ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ POLICY DECISION POINT (PDP) │ │
│ │ │ │
│ │ For EVERY request, verify: │ │
│ │ 1. WHO is requesting? (Identity) │ │
│ │ 2. WHAT device? (Device health) │ │
│ │ 3. FROM WHERE? (Context) │ │
│ │ 4. TO WHAT? (Resource sensitivity) │ │
│ │ 5. WHY? (Business justification) │ │
│ │ │ │
│ │ Only then: ALLOW or DENY │ │
│ └──────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
RESULT: Even if laptop is compromised, access to database
requires proving identity, device health, and policy approval
FOR EACH REQUEST.
The Financial Reality:
- Average cost of a data breach: $4.45 million (IBM, 2023)
- Average time to identify a breach: 204 days
- Average time to contain a breach: 73 days
- Organizations with Zero Trust architecture: $1.76 million lower breach costs
Zero Trust isn’t just a security improvement—it’s the only architecture that works in a world of:
- Remote work (employees connecting from anywhere)
- Cloud services (no physical perimeter to defend)
- Supply chain attacks (third-party software access)
- Advanced persistent threats (attackers who live in your network for months)
The Five Pillars of Zero Trust Architecture
NIST SP 800-207 defines Zero Trust around five core principles. Every project in this sprint maps to one or more of these pillars:
┌─────────────────────────────────────────────────────────────────────────┐
│ THE FIVE PILLARS OF ZERO TRUST │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. IDENTITY 2. DEVICE │
│ ───────────────── ───────────────── │
│ Who is this user/service? Is this device trusted? │
│ How strongly authenticated? Is it managed/healthy? │
│ What groups/roles? What's its security posture? │
│ │
│ → Project 1: Identity Proxy → Project 5: Device Attestation │
│ → Project 6: Continuous Auth → Project 5: Health Checks │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 3. NETWORK 4. APPLICATION │
│ ───────────────── ───────────────── │
│ Micro-segmentation App-level access control │
│ Encrypted channels API security │
│ No implicit trust by location Resource protection │
│ │
│ → Project 3: Micro-segmentation → Project 2: Policy Engine │
│ → Project 4: mTLS Mesh → Project 9: ZTNA Tunnel │
│ → Project 7: SDP Controller → Project 8: JIT Access │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 5. DATA │
│ ───────────────── │
│ Classify sensitive data │
│ Protect at rest and in transit │
│ Access based on classification │
│ │
│ → Cross-cutting concern in all projects │
│ → Project 10: Capstone integrates all │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Control Plane vs Data Plane: The Core Architectural Split
Every Zero Trust system separates two fundamental concerns:
┌─────────────────────────────────────────────────────────────────────────┐
│ CONTROL PLANE vs DATA PLANE │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ CONTROL PLANE DATA PLANE │
│ (The Brain) (The Enforcer) │
│ ═══════════════ ═══════════════ │
│ │
│ Makes decisions: Enforces decisions: │
│ - Should this access be allowed? - Permits/denies connections │
│ - What policy applies? - Routes traffic │
│ - What level of access? - Logs access │
│ │
│ Components: Components: │
│ ┌──────────────────────┐ ┌──────────────────────┐ │
│ │ Policy Decision Point│ │ Policy Enforcement │ │
│ │ (PDP) │ │ Point (PEP) │ │
│ │ │ │ │ │
│ │ - Policy Engine │◀──────────▶│ - Reverse Proxy │ │
│ │ - Identity Provider │ Decision │ - API Gateway │ │
│ │ - Risk Engine │ │ - Network Firewall │ │
│ │ - Context Evaluator │ │ - eBPF filters │ │
│ └──────────────────────┘ └──────────────────────┘ │
│ │
│ NEVER in the data path ALWAYS in the data path │
│ Can be slow (complex logic) Must be fast (every packet) │
│ Centralized decision making Distributed enforcement │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Request Flow: │
│ │
│ User ──▶ [PEP: "Is this allowed?"] ──▶ [PDP: "Let me check..."] │
│ │ │ │
│ │◀─── "Allow with conditions" ─┘ │
│ │ │
│ ▼ │
│ [PEP enforces: route to resource, log access, apply rate limits] │
│ │ │
│ ▼ │
│ Resource (Server, Database, API) │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Why This Separation Matters:
-
Scalability: PEPs are distributed (at every network edge), but they consult a centralized PDP. You can have thousands of PEPs with one PDP.
-
Flexibility: Changing policy in the PDP immediately affects all PEPs. No need to update every firewall rule individually.
-
Security: The PDP never handles actual data traffic. Compromising a PEP doesn’t give you the policy logic.
-
Performance: PEPs cache decisions. Simple requests don’t hit the PDP every time.
Authentication vs Authorization: The Critical Distinction
Many engineers conflate these concepts. In Zero Trust, the distinction is paramount:
┌─────────────────────────────────────────────────────────────────────────┐
│ AUTHENTICATION (AuthN) vs AUTHORIZATION (AuthZ) │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ AUTHENTICATION (AuthN) AUTHORIZATION (AuthZ) │
│ ══════════════════════ ═════════════════════ │
│ "WHO are you?" "WHAT can you do?" │
│ │
│ Verifies IDENTITY: Grants PERMISSIONS: │
│ - Username/password - Read file X │
│ - Certificate - Access API endpoint Y │
│ - Biometric - Delete database Z │
│ - MFA token - Admin role on service W │
│ │
│ Answers: Answers: │
│ "Is this really Alice?" "Can Alice do this action?" │
│ │
│ Technologies: Technologies: │
│ - OAuth 2.0 / OpenID Connect - RBAC (Role-Based) │
│ - SAML - ABAC (Attribute-Based) │
│ - mTLS certificates - PBAC (Policy-Based) │
│ - JWT tokens - ReBAC (Relationship-Based) │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ EXAMPLE: │
│ │
│ Alice presents JWT token PDP evaluates: │
│ │ - Alice's role: "engineer" │
│ ▼ - Resource: "production-db" │
│ [VERIFY SIGNATURE] ──────▶ OK - Action: "DELETE" │
│ [CHECK EXPIRY] ────────▶ OK - Context: "Friday 3pm" │
│ [VALIDATE CLAIMS] ─────▶ OK - Device: "unmanaged laptop" │
│ │ │ │
│ ▼ ▼ │
│ AuthN PASSED: This is Alice AuthZ DENIED: Engineers cannot │
│ DELETE production data from │
│ unmanaged devices │
│ │
│ Strong authentication does NOT imply authorization! │
│ │
└─────────────────────────────────────────────────────────────────────────┘
The Zero Trust Principle: Just because you can prove who you are (AuthN) doesn’t mean you can do what you’re asking (AuthZ). Every request must pass BOTH checks.
RBAC vs ABAC vs PBAC: Choosing Your Authorization Model
┌─────────────────────────────────────────────────────────────────────────┐
│ AUTHORIZATION MODEL COMPARISON │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ RBAC (Role-Based Access Control) │
│ ═══════════════════════════════ │
│ │
│ Users ──▶ Roles ──▶ Permissions │
│ │
│ Alice ──▶ "Engineer" ──▶ [read:code, write:code, read:docs] │
│ Bob ──▶ "Admin" ──▶ [read:*, write:*, delete:*] │
│ │
│ ✓ Simple to understand │
│ ✓ Easy to audit ("who has admin?") │
│ ✗ Role explosion in complex orgs │
│ ✗ Doesn't handle context (time, location) │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ABAC (Attribute-Based Access Control) │
│ ═════════════════════════════════════ │
│ │
│ Policy: IF user.department == resource.owner.department │
│ AND time.hour BETWEEN 9 AND 17 │
│ AND device.managed == true │
│ THEN allow │
│ │
│ ✓ Extremely flexible │
│ ✓ Handles context naturally │
│ ✓ Supports Zero Trust requirements │
│ ✗ Complex to write and debug │
│ ✗ Harder to audit ("why was this denied?") │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ PBAC (Policy-Based Access Control) │
│ ═══════════════════════════════════ │
│ │
│ Combines RBAC simplicity with ABAC flexibility: │
│ │
│ Policy "production-access": │
│ subjects: │
│ - role: "engineer" │
│ - group: "team-platform" │
│ resources: │
│ - type: "database" │
│ environment: "production" │
│ conditions: │
│ - device.trust_score >= 80 │
│ - user.mfa_verified == true │
│ - time.business_hours == true │
│ actions: ["read"] │
│ effect: "allow" │
│ │
│ ✓ Human-readable policies │
│ ✓ Composable (combine multiple policies) │
│ ✓ Auditable ("show me all production policies") │
│ ✓ Zero Trust ready │
│ │
│ This is what you'll build in Project 2. │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Lateral Movement: The Attack You’re Defending Against
Lateral movement is the primary attack pattern in modern breaches. Understanding it is essential:
┌─────────────────────────────────────────────────────────────────────────┐
│ ANATOMY OF LATERAL MOVEMENT │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ATTACK TIMELINE: │
│ │
│ Day 1: Initial Compromise │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Attacker sends phishing email to employee │ │
│ │ Employee clicks link, malware installed on laptop │ │
│ │ Attacker now has foothold: Alice's laptop │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Day 2-30: Reconnaissance │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ From Alice's laptop, attacker: │ │
│ │ - Scans internal network (what services are reachable?) │ │
│ │ - Dumps credentials from memory (Mimikatz) │ │
│ │ - Reads configuration files (passwords, API keys) │ │
│ │ - Identifies high-value targets (databases, admin systems) │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Day 31-60: Lateral Movement │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Alice's ──▶ File ──▶ Domain ──▶ Database ──▶ Crown │ │
│ │ Laptop Server Controller Server Jewels │ │
│ │ │ │ │ │ │ │ │
│ │ │ SSH │ RDP │ SQL │ ??? │ │ │
│ │ └──────────┴──────────┴──────────┴───────────┘ │ │
│ │ │ │
│ │ Each hop: Use credentials stolen from previous hop │ │
│ │ Each hop: Gain access to more systems and credentials │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Day 61+: Data Exfiltration │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Attacker reaches sensitive database │ │
│ │ Slowly exfiltrates data to avoid detection │ │
│ │ Or deploys ransomware for immediate impact │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ HOW ZERO TRUST STOPS THIS: │
│ │
│ At EVERY hop, the attacker would need to: │
│ ✗ Prove identity (stolen password isn't enough—need MFA) │
│ ✗ Prove device health (malware-infected laptop fails check) │
│ ✗ Match policy (Alice can't access Domain Controller) │
│ ✗ Justify access (no legitimate reason for this connection) │
│ │
│ RESULT: Attack stops at first hop. Even if Alice's laptop is │
│ compromised, it can only access what Alice is authorized for, │
│ from a healthy device, with proper context. │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Key Insight: Traditional security asks “Is this connection from the corporate network?” Zero Trust asks “Is this specific user, on this specific device, authorized for this specific action, right now?” The second question stops lateral movement.
Concept Summary Table
| Concept Cluster | What You Need to Internalize |
|---|---|
| Zero Trust Principles | “Never trust, always verify” isn’t a slogan—it’s an architectural requirement. Every request is untrusted until proven otherwise. Network location is NOT identity. |
| Control Plane / Data Plane | Separate the brain (policy decisions) from the muscles (enforcement). PDP makes decisions; PEP enforces them. This separation enables scale and flexibility. |
| AuthN vs AuthZ | Authentication proves identity; authorization grants permissions. Strong authentication doesn’t imply any authorization. Both must pass for every request. |
| Identity-Based Security | Replace “you’re on the VPN” with “you’ve proven you’re Alice, from a healthy device, for a specific purpose.” Identity is cryptographically verified. |
| Micro-segmentation | Don’t trust the network. Every host enforces its own policies. East-west traffic is treated like north-south. Use iptables, eBPF, mTLS. |
| Device Trust | A valid user on a compromised device is still a threat. Verify device health: encryption, firewall, patch level, no malware. |
| Continuous Verification | Authentication at login isn’t enough. Continuously monitor behavior, context, and device health. Revoke access when conditions change. |
| Least Privilege | Grant minimum access needed for the task. Time-bound access. Just-in-time provisioning. Never standing privileges. |
| Lateral Movement Defense | Every hop requires re-authentication and re-authorization. Compromise of one system doesn’t give access to others. |
| Policy as Code | Policies are version-controlled, testable, auditable. Not firewall rules scattered across devices. Central policy, distributed enforcement. |
Deep Dive Reading by Concept
This section maps each concept to specific book chapters for deeper understanding. Read these before or alongside the projects to build strong mental models.
Zero Trust Fundamentals (The Philosophy)
| Concept | Book & Chapter |
|---|---|
| Why perimeter security fails | “Zero Trust Networks” by Gilman & Barth — Ch. 1: “Zero Trust Fundamentals” |
| NIST Zero Trust definition | NIST SP 800-207 — Sections 2-3 (free PDF from NIST) |
| Google’s BeyondCorp | “BeyondCorp: A New Approach to Enterprise Security” — Google Research Papers (free online) |
| The threat landscape | “Security in Computing, 5th Edition” by Pfleeger — Ch. 1: “Introduction to Computer Security” |
Identity and Authentication
| Concept | Book & Chapter |
|---|---|
| Authentication fundamentals | “Security in Computing” by Pfleeger — Ch. 3: “Authentication” |
| OAuth 2.0 and OpenID Connect | “OAuth 2 in Action” by Richer & Sanso — Ch. 1-5 |
| JWT tokens in depth | “Serious Cryptography, 2nd Edition” by Aumasson — Ch. 14: “Authentication” |
| PKI and certificates | “Serious Cryptography” by Aumasson — Ch. 13: “TLS” |
| mTLS for service identity | “Zero Trust Networks” by Gilman & Barth — Ch. 6: “Network Security” |
Authorization and Policy
| Concept | Book & Chapter |
|---|---|
| RBAC vs ABAC | “Security in Computing” by Pfleeger — Ch. 4: “Access Control” |
| Policy languages (Rego, Cedar) | “Learning Open Policy Agent” by Lopes & Russo (for OPA) |
| XACML and policy architecture | NIST SP 800-162 — Guide to ABAC (free PDF) |
| Policy enforcement patterns | “Zero Trust Networks” by Gilman & Barth — Ch. 4: “Making Authorization Decisions” |
Network Security and Micro-segmentation
| Concept | Book & Chapter |
|---|---|
| iptables fundamentals | “The Linux Programming Interface” by Kerrisk — Appendix on networking |
| eBPF for security | “Learning eBPF” by Liz Rice — Ch. 1-6 |
| Network namespaces | “Linux Kernel Networking” by Benvenuti — Ch. 14: “Namespaces” |
| Service mesh concepts | “Istio in Action” by Posta & Maloku — Ch. 2-3 |
| WireGuard internals | “WireGuard: Next Generation Kernel Network Tunnel” — Jason Donenfeld’s whitepaper |
Device Trust and Endpoint Security
| Concept | Book & Chapter |
|---|---|
| Endpoint security architecture | “Zero Trust Networks” by Gilman & Barth — Ch. 7: “Endpoint Security” |
| TPM and hardware attestation | “TCG TPM 2.0 Specification” — Trusted Computing Group (reference) |
| OS security internals | “The Linux Programming Interface” by Kerrisk — Ch. 3-4 on permissions |
| macOS security | “macOS Internals” by Jonathan Levin — Security chapters |
Cryptography Essentials
| Concept | Book & Chapter |
|---|---|
| TLS handshake deep dive | “Serious Cryptography, 2nd Edition” by Aumasson — Ch. 13: “TLS” |
| Public key infrastructure | “Security in Computing” by Pfleeger — Ch. 7.2: “PKI” |
| Digital signatures | “Serious Cryptography” by Aumasson — Ch. 12: “RSA” & Ch. 11: “Digital Signatures” |
| Certificate management | “Bulletproof SSL and TLS” by Ristic — Ch. 4-6 |
Systems Programming for Security
| Concept | Book & Chapter |
|---|---|
| Linux system calls | “The Linux Programming Interface” by Kerrisk — Ch. 2-3 |
| Network programming | “TCP/IP Sockets in C” by Donahoo & Calvert — Full book |
| Process and permissions | “The Linux Programming Interface” by Kerrisk — Ch. 9: “Process Credentials” |
| Secure coding in C | “Effective C” by Seacord — Ch. 7: “Security” |
Essential Reading Order
For maximum comprehension, read in this order:
- Foundation (Week 1):
- Zero Trust Networks Ch. 1-3 (fundamentals)
- Security in Computing Ch. 3-4 (AuthN/AuthZ)
- NIST SP 800-207 Sections 2-3 (definitions)
- Identity & Crypto (Week 2):
- Serious Cryptography Ch. 11-13 (signatures, TLS)
- Zero Trust Networks Ch. 6 (network security)
- Systems (Week 3):
- The Linux Programming Interface Ch. 2-4, 9 (system programming)
- Zero Trust Networks Ch. 7 (endpoints)
- Advanced (Weeks 4+):
- Learning eBPF (for Project 3)
- Zero Trust Networks Ch. 4-5 (policy decisions)
- Google BeyondCorp papers (real-world implementation)
What You’ll Learn
By completing these projects, you will:
- Internalize the Control Plane vs Data Plane separation - The foundation of all modern security architecture
- Master Identity-based security over obsolete Network-based security
- Implement Least Privilege at the packet level using iptables, eBPF, and mTLS
- Build systems that resist Lateral Movement - The #1 attack pattern in modern breaches
- Create a portfolio demonstrating expert-level security engineering
Project Index
| # | Project | Difficulty | Time | Key Skills |
|---|---|---|---|---|
| 1 | Identity-Aware Reverse Proxy | Intermediate | Weekend | Go, HTTP, JWT, OAuth2 |
| 2 | Policy Decision Engine | Advanced | 1-2 Weeks | Rust/Go, ABAC, Rule Engines |
| 3 | Host-Level Micro-segmentation | Expert | 2 Weeks | C, iptables, eBPF |
| 4 | Mutual TLS Mesh | Advanced | 1 Week | Go, PKI, X.509, SPIFFE |
| 5 | Device Trust & Health Attestation | Intermediate | Weekend | Go/Python, OS APIs, TPM |
| 6 | Continuous Authentication Monitor | Expert | 2 Weeks | Python, UEBA, Analytics |
| 7 | Software Defined Perimeter Controller | Master | 1 Month | Go, WireGuard, SPA |
| 8 | Just-In-Time Access Broker | Advanced | 1 Week | Go, SQL, Credential Mgmt |
| 9 | ZTNA App Tunnel | Expert | 2 Weeks | Rust, SOCKS5, mTLS |
| 10 | The Secure Enclave (Capstone) | Master | 2 Weeks | All Previous |
Recommended Learning Paths
Path 1: Security Professional (Recommended)
Best for: Those with networking/security background
Project 1 → Project 2 → Project 5 → Project 6 → Advanced (7, 8, 9)
Path 2: Systems Programmer
Best for: Linux/C enthusiasts
Project 3 → Project 7 → Project 4 → Projects 1, 2, 5, 6
Path 3: Application Developer
Best for: Backend developers transitioning to security
Project 1 → Project 8 → Project 9 → Projects 2, 4, 5, 6
Path 4: The Completionist
Best for: Building a complete Zero Trust lab
Phase 1 (Weeks 1-2): Projects 1, 2
Phase 2 (Weeks 3-4): Projects 3, 4
Phase 3 (Weeks 5-6): Projects 5, 6
Phase 4 (Weeks 7-10): Projects 7, 8, 9
Phase 5 (Week 11): Project 10 (Capstone)
Prerequisites
Before starting, ensure you have:
Required Skills
- Proficiency in Go, Python, Rust, or C
- Understanding of HTTP/REST APIs
- Basic networking (TCP/IP, HTTP/HTTPS, DNS)
- Linux terminal proficiency
- Security basics (Authentication vs Authorization)
Required Tools
- Linux machine (Ubuntu 22.04 or Debian 12 recommended)
- Programming language runtime (Go 1.21+, Python 3.11+, or Rust 1.70+)
openssl,curl,docker
Self-Assessment
You’re ready if you can answer “yes” to:
- Can you write a simple HTTP server in your chosen language?
- Do you know what happens when you type a URL in your browser?
- Can you explain the difference between a password and a cryptographic key?
How Each Guide is Structured
Every expanded project guide contains:
- Learning Objectives - What you’ll master
- Deep Theoretical Foundation - Comprehensive concept education
- Complete Project Specification - What you’re building
- Solution Architecture - Design guidance without implementation
- Phased Implementation Guide - Structured approach to building
- Testing Strategy - How to verify your implementation
- Common Pitfalls - Mistakes to avoid
- Extensions & Challenges - Ways to deepen your learning
- Real-World Connections - How this applies in production
- Self-Assessment Checklist - Verify your understanding
Additional Resources
Standards & Specifications
- NIST SP 800-207: Zero Trust Architecture
- CISA Zero Trust Maturity Model
- CSA Software-Defined Perimeter Specification v2.0
Core Books
- “Zero Trust Networks” by Evan Gilman and Doug Barth
- “Security in Computing” by Charles Pfleeger
- “The Linux Programming Interface” by Michael Kerrisk
- “Serious Cryptography, 2nd Edition” by Jean-Philippe Aumasson
Get Started
Begin with Project 1: Identity-Aware Reverse Proxy for the recommended path, or choose based on your background using the learning paths above.
Remember: Zero Trust is not a product you buy—it’s an architecture you build. These projects will give you the skills to build it from first principles.