1. Introduction to Zero Trust
Traditional security relied on the "Castle and Moat" concept: once you logged into the VPN, you were trusted. Zero Trust breaks this model. It assumes that the network is always hostile and that threats exist both outside and inside the network. Therefore, trust is never implicit; it must be earned for every single request.
Why Zero Trust Emerged:
The Old Model is Broken:
Traditional Perimeter Security:
Outside Network (Untrusted)
β
Firewall/VPN
β
Inside Network (TRUSTED)
β
All systems accessibleProblems:
- Once inside = full access (castle breach = total compromise)
- VPN = broad network access (not granular)
- Lateral movement easy (from one server to all servers)
- Insider threats invisible (trusted employees can steal data)
Modern Threat Landscape:
Statistics (2026):
- 80% of breaches involve insider threats or compromised credentials
- Remote work: 58% of employees work from home (perimeter dissolved)
- Cloud adoption: 94% of enterprises use cloud (data outside perimeter)
- IoT devices: 27 billion connected devices (can't trust network)
Famous Breaches:
- β Target (2013): HVAC vendor credentials β 40M cards stolen
- β SolarWinds (2020): Trusted software update β 18,000 orgs compromised
- β Uber (2022): Contractor credentials β full network access
2Zero Trust Principles (The NIST Standard)
According to NIST SP 800-207, Zero Trust is built on three core tenets:
.svg)
Pillar 1: Verify Explicitly Γ°ΕΈβΒ
Always authenticate and authorize based on all available data points:
Identity Verification:
- Username/password (baseline)
- Multi-Factor Authentication (MFA) - required
- Biometrics (fingerprint, Face ID)
- Behavioral analysis (typing patterns, mouse movements)
Device Health:
- Is device managed by organization?
- Latest OS patches installed?
- Antivirus up to date?
- Disk encrypted?
- Jailbroken/rooted? (block if yes)
Location Context:
- Geographic location (GPS, IP geolocation)
- Expected location? (employee in office vs sudden login from Russia)
- Impossible travel (login from NY, then Tokyo 1 hour later = suspicious)
Time Context:
- Access during business hours? (9-5 vs 2 AM)
- Deviation from normal pattern? (accountant suddenly accessing HR database)
Data Classification:
- Public data β lower verification
- Confidential data β higher verification (MFA + manager approval)
Risk Score Calculation:
Risk Score = f(Identity, Device, Location, Time, Behavior) Low Risk (Score 0-30): Allow access Medium Risk (31-70): Require MFA High Risk (71-100): Block + alert security team
Example:
User: [email protected] Device: Company laptop (managed β) Location: Office Wi-Fi (expected β) Time: 10 AM (normal β) MFA: Approved (β) Risk Score: 15 β ALLOW
Pillar 2: Use Least Privilege Access Γ°ΕΈβΒ
Limit user access with Just-In-Time (JIT) and Just-Enough-Access (JEA) policies.
Principle:
If a user only needs to read a file, do NOT give them "Admin" rights.
Implementation:
Role-Based Access Control (RBAC):
Role: HR_Analyst Permissions: - READ: employee_database - WRITE: performance_reviews - DENY: payroll_database
Just-In-Time (JIT) Access:
User needs admin access for server maintenance β Request temporary elevation (1 hour) β Manager approves β Access granted (expires after 1 hour) β All actions logged
Just-Enough-Access (JEA):
Instead of: "Full admin rights" Grant: "Restart IIS service only" (specific command)
Attribute-Based Access Control (ABAC):
IF (user.department == "Finance" AND
user.clearance >= "Secret" AND
time.hour BETWEEN 9 AND 17 AND
data.classification <= user.clearance)
THEN allow_accessSession Management:
- Time-limited sessions: Re-authenticate every 4 hours
- Idle timeout: 15 minutes inactivity β logout
- Step-up authentication: Accessing sensitive data β require fresh MFA
Benefits:
- β Limits blast radius (compromised account can't access everything)
- β Reduces insider threat (employees can't steal data they can't access)
- β Compliance (SOX, HIPAA require least privilege)
Pillar 3: Assume Breach π¨
Minimize the blast radius. Assume the firewall has failed and the attacker is already on the network. Design the system so they cannot move laterally to other servers.
Mindset Shift:
Old: "We prevented the breach" (breach = failure) New: "We contained the breach" (breach = inevitable, containment = success)
Implementation:
1. Microsegmentation:
Traditional Network: βββββββββββββββββββββββββββββββββββββββΓ’βΒ β All servers can talk to each other β Γ’β Β Single breach = total compromise ββββββββββββββββββββββββββββββββββββββββ Zero Trust Network: βββββββΓ’βΒ βββββββΓ’βΒ βββββββΓ’βΒ β Web ββ³ β App ββ³ β DB β Γ’β Β Firewalls between EVERY segment ββββββββ ββββββββ ββββββββ Each segment isolated (breach of Web server β access to DB)
2. Lateral Movement Prevention:
- Default deny all traffic
- Allow only specific application flows
- Monitor for anomalous connections
3. Continuous Monitoring:
- Log everything: All access attempts (success + failures)
- Behavioral analytics: Detect unusual activity
- Automated response: Block suspicious accounts immediately
4. Encryption Everywhere:
- Data in transit: TLS 1.3 for all internal traffic (not just external)
- Data at rest: Encrypt all storage
- End-to-end: Even if attacker intercepts traffic, can't read it
5. Honeypots/Canaries:
- Fake servers with fake data
- Any access = confirmed breach (legitimate users never touch)
- Trigger immediate alert
Example Breach Containment:
Scenario: Phishing email compromises marketing employee account Without Zero Trust: β Attacker logs in with stolen password β Has VPN access to entire network β Discovers database server β Exfiltrates 10M customer records β Damage: CRITICAL With Zero Trust: β Attacker logs in with stolen password β MFA blocks initial access (no second factor) β IF bypassed: Access limited to marketing apps only β Database requires separate authentication (blocked) β Unusual behavior detected (downloading 10M records) β Access revoked, account frozen, security alerted β Damage: CONTAINED (no data loss)
3Zero Trust Architecture Model
How does it actually work? It separates the Control Plane (Decision maker) from the Data Plane (Traffic mover).
.svg)
Components Explained:
1. Subject (User/Device):
- Person or machine requesting access
- Examples: Employee laptop, IoT sensor, API client
2. Policy Engine (PE) - The Brain π§ :
- Evaluates all access requests
- Combines multiple data sources:
- Identity provider (who is this?)
- Device compliance (is device secure?)
- Threat intelligence (known malicious IP?)
- Data classification (how sensitive?)
- Outputs: Allow/Deny decision
3. Policy Administrator (PA) - The Manager π:
- Executes PE decisions
- Configures Policy Enforcement Points (PEPs)
- Establishes/revokes sessions
- Logs all decisions
4. Policy Enforcement Point (PEP) - The Gate πͺ:
- Enforces decisions
- Examples:
- Next-gen firewall (NGFW)
- Reverse proxy
- API gateway
- Cloud Access Security Broker (CASB)
- Actions: Block traffic, allow traffic, route to secondary authentication
5. Resource:
- The protected asset
- Examples: Database, application, file server, API endpoint
6. Supporting Systems:
Identity Provider (IdP):
- Azure AD, Okta, Google Workspace
- Stores user identities, authenticates
Device Management:
- Microsoft Intune, Jamf
- Verifies device health
Threat Intelligence:
- Known bad IPs, malware signatures
- Real-time threat feeds
SIEM/Analytics:
- Log aggregation, correlation
- Behavioral analysis
Request Flow Example:
1. User ([email protected]) on laptop tries to access Salesforce 2. Request intercepted by PEP (Proxy) 3. PEP forwards to Policy Engine: "Can [email protected] from device ABC123 at IP 203.0.113.5 access Salesforce?" 4. Policy Engine queries: - IdP: "Is alice authenticated?" β YES (MFA passed) - Device Mgmt: "Is device ABC123 compliant?" β YES (encrypted, patched) - Threat Intel: "Is IP 203.0.113.5 malicious?" β NO (clean) - Data Policy: "Does alice have Salesforce permission?" β YES (Sales role) 5. Policy Engine calculates risk score: 20 (LOW) 6. Policy Engine β Policy Administrator: "ALLOW" 7. Policy Administrator β PEP: "Establish session, log traffic" 8. PEP allows connection, user accesses Salesforce 9. Continuous monitoring: - After 30 minutes, alice downloads 10GB data (unusual) - Risk score jumps to 85 (HIGH) - Policy Engine: "REVOKE session, require re-auth" - Session terminated, alert sent to security team
4Microsegmentation
In a traditional network, if you hack one server, you can talk to all other servers (Lateral Movement).
Definition:
Microsegmentation divides the network into tiny, isolated zonesβsometimes down to a single workload or container.
Benefit:
If a hacker breaches the "Web Server" zone, they cannot jump to the "Database" zone because the Zero Trust policy blocks that specific connection.
Traditional Network (Flat):
ββββββββββββββββββββββββββββββββββββββββββββββΓ’βΒ β Internal Network (10.0.0.0/8) β β β β Web Server Γ’β Ββ App Server Γ’β Ββ DB Server β β β β β β β HR Server Γ’β Ββ Finance Γ’β Ββ Backup β β β β All systems can communicate freely β βββββββββββββββββββββββββββββββββββββββββββββββ Problem: Breach web server β access ALL servers
Microsegmented Network:
ββββββββββΓ’βΒ ββββββββββΓ’βΒ ββββββββββΓ’βΒ
β Web βββββββ β App βββββββ β DB β
β Server β β Server β β Server β
βββββββββββ βββββββββββ βββββββββββ
β β β
β³ β³ β³
β β β
ββββββββββΓ’βΒ ββββββββββΓ’βΒ ββββββββββΓ’βΒ
β HR β β Finance β β Backup β
β Server β β Server β β Server β
βββββββββββ βββββββββββ βββββββββββ
β = Allowed (explicit policy)
β³ = Blocked (default deny)
Benefit: Breach web server β access to HR/Finance/DBImplementation Levels:
1. Network Microsegmentation:
- VLANs, subnets
- East-West firewall rules
- Software-Defined Networking (SDN)
2. Application Microsegmentation:
- Service mesh (Istio, Linkerd)
- API-level policies
- Container network policies (Kubernetes)
3. Workload Microsegmentation:
- Per-container policies
- Process-level isolation
- Zero Trust for microservices
Policy Example:
Segment: Web_Server_Zone Allowed Outbound: β App_Server_Zone: Port 443 (HTTPS API calls) β DNS_Server: Port 53 (name resolution) Denied Outbound: β Database_Zone: * (no direct DB access) β HR_Zone: * (no business need) β Internet: * (except via proxy)
Benefits:
Security:
- β Limits lateral movement (80% reduction)
- β Reduces attack surface
- β Contains malware
Compliance:
- β PCI DSS: Isolate cardholder data
- β HIPAA: Separate PHI
- β GDPR: Demonstrate controls
Operations:
- β Network visibility
- β Policy enforcement
- β Change management
5Continuous Verification
Authentication is not a one-time event.
Traditional:
9:00 AM: User logs in (username + password) 9:00 AM - 5:00 PM: Trusted (stay logged in all day) 5:00 PM: User logs out
Zero Trust:
9:00 AM: User logs in (MFA) 9:05 AM: Accesses email (verify device health) 10:30 AM: Accesses financial report (risk score increases, require MFA again) 11:00 AM: Downloads 5GB data (unusual behavior β session revoked) 11:01 AM: Require fresh authentication + manager approval
Continuous Verification Triggers:
1. Time-Based:
- Re-authenticate every 4 hours
- Idle timeout (15 minutes β logout)
2. Behavior-Based:
- Data exfiltration: Downloading >1GB data
- Unusual access: Accountant accessing source code repository
- Velocity anomaly: 100 failed login attempts in 5 minutes
3. Context Change:
- Location shift: Login from NY, then Moscow 2 hours later
- Device switch: Desktop β mobile β unknown laptop
- Network change: Office Wi-Fi β public Wi-Fi
4. Risk Score Escalation:
Initial login: Risk Score 20 (low) β Allow 30 min later: User accesses admin panel β Risk Score 50 (medium) β Require MFA 1 hour later: Unusual SQL queries detected β Risk Score 90 (critical) β Revoke + alert
Implementation:
User & Entity Behavior Analytics (UEBA):
- Machine learning baselines normal behavior
- Detects anomalies in real-time
- Examples: Microsoft Defender for Identity, Splunk UBA
Adaptive Authentication:
IF risk_score < 30:
allow_access()
ELIF 30 <= risk_score < 70:
require_mfa()
ELIF risk_score >= 70:
block_access()
notify_security_team()Session Monitoring:
- Track all user actions during session
- Keyboard/mouse activity (detect bot vs human)
- Data transfer volume
- Application usage patterns
Critical Comparison
β οΈ Perimeter Security vs. Zero Trust (Exam Focus)
| Feature | Traditional (Perimeter) | Zero Trust Architecture |
|---|---|---|
| Trust Model | "Trust but Verify" | "Never Trust, Always Verify" |
| Location | Inside = Trusted, Outside = Untrusted | Location is irrelevant (trust is identity-based) |
| Access | VPN gives full network access | Access granted per-app only (granular) |
| Focus | Securing the Network perimeter | Securing the Data/Identity |
| Authentication | One-time (login once) | Continuous (verify every request) |
| Lateral Movement | Easy (open internal network) | Blocked (microsegmentation) |
| Device Trust | Any device inside network trusted | Device health verified (managed, patched) |
| Failure Point | Single (firewall breach = total compromise) | Multiple (breach contained by segmentation) |
| Cloud Compatible | Poor (perimeter dissolves) | Excellent (identity follows anywhere) |
| Remote Work | VPN required (slow, complex) | Seamless (same security anywhere) |
Key Insight:
Perimeter security assumes: "Inside = safe, outside = dangerous"
Zero Trust assumes: "Everywhere = dangerous, verify everything"
6Implementation Strategy
You cannot buy "Zero Trust" in a box. It is a journey, not a product.
Phase 1: Identify Protect Surface π―
Goal: What are your most critical assets?
DAAS Framework:
- β Data: Customer records, financial data, IP
- β Assets: Servers, databases, SaaS apps
- β Applications: ERP, CRM, custom apps
- β Services: APIs, microservices
Questions:
- What data would hurt most if stolen?
- What systems are business-critical?
- What compliance requirements apply? (HIPAA, PCI-DSS)
Output: Priority list of assets to protect first
Phase 2: Map Transaction Flows πΊοΈ
Goal: How does data move across the network?
Process:
- 1. Document user journeys (employee logs in β accesses CRM β pulls customer report)
- 2. Map application dependencies (CRM calls database, authentication service, email server)
- 3. Identify data flows (where does customer data travel?)
Tools:
- Network traffic analysis (Wireshark, NetFlow)
- Application dependency mapping (ServiceNow, Dynatrace)
- Cloud access logs (AWS CloudTrail, Azure Monitor)
Output: Network diagram showing who/what talks to whom
Phase 3: Build Zero Trust Architecture Γ°ΕΈβοΈ
Goal: Deploy technology components
Core Technologies:
Identity & Access Management (IAM):
- Okta, Azure AD, Ping Identity
- SSO, MFA, passwordless authentication
Device Management:
- Microsoft Intune, Jamf, VMware Workspace ONE
- Verify device health, enforce compliance
Next-Gen Firewall (NGFW):
- Palo Alto, Fortinet, Cisco
- Microsegmentation, application-aware filtering
Zero Trust Network Access (ZTNA):
- Zscaler, Cloudflare Access, Akamai
- Replace VPN with app-specific access
Cloud Access Security Broker (CASB):
- McAfee MVISION, Netskope
- Monitor/control cloud app usage
SIEM/Analytics:
- Splunk, Microsoft Sentinel
- Aggregate logs, detect anomalies
Phase 4: Create Zero Trust Policy π
Goal: Define access rules
Policy Questions (5W1H):
- β WHO: Which users/devices?
- β WHAT: Which resources (apps, data)?
- β WHEN: Time restrictions (business hours only)?
- β WHERE: Location restrictions (office only)?
- β WHY: Business justification (legitimate need)?
- β HOW: Authentication method (MFA, biometrics)?
Policy Example:
Policy: Access_Salesforce Who: Sales_Department users What: Salesforce CRM When: Monday-Friday, 8 AM - 6 PM Where: Office network OR managed devices with VPN Why: Sales operations How: SSO with MFA, device compliance check Action: ALLOW Logging: Full session logs
Phase 5: Monitor and Maintain π
Goal: Inspect and log all traffic
Continuous Activities:
- Log everything: All access requests (success + denied)
- Analyze patterns: UEBA for anomaly detection
- Update policies: As business needs change
- Test regularly: Penetration testing, red team exercises
- Train users: Security awareness (phishing, social engineering)
Metrics:
- Authentication success/failure rates
- Policy violation attempts
- Mean time to detect (MTTD)
- Mean time to respond (MTTR)
7Case Study: Google BeyondCorp
Google BeyondCorp is the most famous implementation of Zero Trust.
Background:
- β 2009: Google used traditional VPN for remote access
- β 2010: Operation Aurora - Chinese hackers breached Google via compromised VPN credentials
- β 2011: Google decided to eliminate VPN entirely
The Shift:
Before (Perimeter Model):
Employee β VPN β Inside Google network β Full access Problem: VPN credential theft = network breach
After (BeyondCorp):
Employee β Internet β BeyondCorp Proxy β Specific app only Verification: Identity + Device + Context β Allow/Deny per app
Key Changes:
1. Eliminated VPN:
- No more corporate network "inside"
- All applications accessed via internet (like external users)
2. Device Inventory:
- Every device must be managed by Google
- Device certificates issued
- Continuous health monitoring (OS version, patches, encryption)
3. Access Control:
- Identity-based: Who you are (employee account)
- Device-based: What you're using (managed laptop)
- Context-based: Where you are, what you're accessing
4. Application-Level Access:
Employee needs Gmail: Check (identity + device) β Allow Gmail only Employee needs source code: Check (developer role + managed device + office location) β Allow Employee needs payroll: Check (HR role) β Deny (wrong department)
The Result:
Productivity:
- β Work from anywhere
- β No VPN slowdowns
- β Same security everywhere
Security:
- β 80% fewer credential attacks
- β Breached device β network breach
- β Real-time monitoring
Architecture:
- β 135,000 employees
- β Zero trust for billions of requests
Lessons Learned:
1. Start Small:
Google began with low-risk apps (corporate wiki). Gradually migrated critical apps (source code, finance).
2. User Experience Matters:
If security is too annoying, users circumvent it. Single Sign-On (SSO) made access seamless.
3. Device Management is Key:
Unmanaged device = no access (strict enforcement). BYOD complicated (requires compromise).
4. Culture Shift:
Train employees ("no more VPN" was confusing initially). Security team becomes enabler, not blocker.