Table of Contents

Zero Trust is not a product but an architecture philosophy: "Never trust, always verify." This lab guides you through implementing Zero Trust across all five pillars—Identity, Devices, Networks, Applications, and Data—using the technologies from previous labs. You'll learn to design, implement, and validate a comprehensive Zero Trust architecture for enterprise environments.

Lab Overview & Zero Trust Principles

Zero Trust assumes breach and verifies every request as if it originated from an untrusted network. The goal is to minimize the blast radius of any compromise by eliminating implicit trust.

Core Zero Trust Principles (NIST 800-207)

  1. All resources are accessed securely regardless of network location
  2. Access is granted on a per-session basis and dynamically evaluated
  3. Access is determined by policy including behavioral and environmental attributes
  4. All resource access requests are authenticated and authorized before access
  5. The enterprise monitors and measures integrity of all assets
  6. All authentication and authorization are dynamic and strictly enforced
  7. Enterprise collects information about assets, network, and communications

The Five Pillars of Zero Trust

Identity

Strong authentication, MFA, least privilege, JIT access

Devices

Device health, compliance, endpoint security

Networks

Micro-segmentation, encrypted traffic, ZTNA

Applications

App-level auth, secure APIs, shadow IT control

Data

Classification, encryption, DLP, access controls

ZERO TRUST ARCHITECTURE

Policy Decision Point (PDP)

Evaluates requests against policy | Entra ID CA, AWS IAM, GCP IAM

Policy Enforcement Point (PEP)

Enforces access decisions | Proxy, Gateway, API Gateway

Policy Information Point (PIP)

Provides context | Device compliance, Risk score, User attributes

Policy Administration Point (PAP)

Manages policies | Admin console, IaC, Policy repository

Traditional vs Zero Trust

Traditional (Perimeter)Zero Trust
Trust users inside networkTrust no one by default
One-time authenticationContinuous verification
Network-based accessIdentity-based access
Flat internal networkMicro-segmented network
VPN for remote accessZTNA per-app access
Implicit trust after authLeast privilege always

Module 1: Identity as the New Perimeter

Module 1: Implement Strong Identity Foundation

Identity is the foundation of Zero Trust—verify every user, every time.

60-90 minutes6 steps
1

Identity Zero Trust Requirements

Identity
Identity Zero Trust Checklist: AUTHENTICATION: ✓ MFA for ALL users (no exceptions) ✓ Phishing-resistant MFA (FIDO2, passkeys) ✓ Risk-based authentication ✓ Passwordless where possible ✓ Session timeout enforcement AUTHORIZATION: ✓ Least privilege by default ✓ Just-in-Time (JIT) access for privileged roles ✓ Role-based access control (RBAC) ✓ Attribute-based access control (ABAC) for fine-grained ✓ Regular access reviews IDENTITY GOVERNANCE: ✓ Automated lifecycle management (JML) ✓ Access certification campaigns ✓ Segregation of duties (SoD) ✓ Privileged access management (PAM) ✓ Identity analytics and risk scoring
2

Implement Phishing-Resistant MFA

Entra ID
Navigate to: Entra ID Security Authentication methods FIDO2 Security Keys (Strongest): Enable FIDO2 security keys Allow self-service registration Require attestation: Yes Enforce key restrictions (if needed) Passkeys (Passwordless): Enable Microsoft Authenticator (passwordless) Configure for all users Enable cross-platform passkeys Windows Hello for Business: Enable for hybrid/cloud deployments Require TPM 2.0 Configure biometric requirements Disable Weak Methods: Disable SMS authentication (SIM swap risk) Disable Voice calls Disable Email OTP Configure Authentication Strengths: Security Conditional Access Authentication strengths Create: "Phishing-Resistant MFA" - FIDO2 security key - Windows Hello for Business - Microsoft Authenticator (passkey)
3

Enforce MFA via Conditional Access

Entra ID
Create Zero Trust Baseline Policy: Navigate to: Security Conditional Access New policy Policy 1: Require MFA for All Users Name: ZT-Baseline-RequireMFA Assignments: - Users: All users - Exclude: Break-glass accounts (emergency) Target Resources: - Cloud apps: All cloud apps Conditions: - (None - applies to all conditions) Access Controls: - Grant: Require authentication strength - Select: "Phishing-Resistant MFA" Session: - Sign-in frequency: 4 hours - Persistent browser session: No Enable policy: On --- Policy 2: Block Legacy Authentication Name: ZT-Block-LegacyAuth Users: All users Cloud apps: All cloud apps Conditions: - Client apps: Exchange ActiveSync, Other clients Access Controls: - Block This blocks protocols that don't support MFA!
4

Implement Just-in-Time Privileged Access

Entra ID PIM
Navigate to: Entra ID Identity Governance Privileged Identity Management Configure PIM for Entra ID Roles: Entra ID roles Settings For Global Administrator: Edit Activation Activation settings: - Maximum activation duration: 2 hours (not 8!) - Require justification: Yes - Require ticket information: Yes - Require approval: Yes - Approvers: Security team members Assignment settings: - Allow permanent eligible: No - Expire eligible after: 90 days - Require MFA on active assignment: Yes Notification settings: - Send notifications when eligible assigned - Send notifications when activated - Alert when admins activate Zero Trust PIM Principles: 1. No standing privileged access 2. Maximum 2-4 hour activation windows 3. Require approval for high-risk roles 4. Full audit trail 5. Regular eligibility reviews
5

Risk-Based Conditional Access

Identity Protection
Enable Identity Protection: Security Identity Protection Configure Risk Policies: User Risk Policy: User risk remediation policy - User risk level: Medium and above - Access: Allow with password change required - Enforcement: On Sign-in Risk Policy: Sign-in risk remediation policy - Sign-in risk level: Medium and above - Access: Allow with MFA required - Enforcement: On Create CA Policy for High Risk: Name: ZT-BlockHighRisk Conditions: - Sign-in risk: High - User risk: High Access Controls: - Block access --- Risk Signals Evaluated: - Impossible travel - Anonymous IP address - Malware-linked IP - Unfamiliar sign-in properties - Password spray detection - Leaked credentials
6

AWS Zero Trust Identity

AWS IAM
# AWS Identity Zero Trust Best Practices # 1. Require MFA for all console access # SCP to deny actions without MFA { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAllExceptListedIfNoMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "sts:GetSessionToken" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } ] } # 2. Use IAM Identity Center (not IAM users) # 3. Short session durations (4 hours max) # 4. Use roles, not long-term credentials # 5. Enable CloudTrail for all regions # 6. Use Permission Boundaries for delegation

Module 2: Device Trust & Compliance

Module 2: Only Healthy Devices Access Resources

Verify device health and compliance before granting access.

60-90 minutes5 steps
7

Device Trust Requirements

Device
Device Zero Trust Requirements: DEVICE IDENTITY: ✓ All devices enrolled in MDM/UEM ✓ Device certificates for authentication ✓ Hardware attestation (TPM) ✓ Device inventory maintained DEVICE HEALTH: ✓ Operating system up to date ✓ Antivirus/EDR running and updated ✓ Firewall enabled ✓ Disk encryption enabled ✓ No jailbreak/root detected (mobile) DEVICE COMPLIANCE: ✓ Compliance policies enforced ✓ Non-compliant devices blocked ✓ Real-time compliance monitoring ✓ Automated remediation DEVICE TYPES: Corporate-managed (Full trust) BYOD with MDM (Conditional trust) BYOD without MDM (Limited trust) Unknown devices (No trust)
8

Intune Compliance Policies

Intune
Navigate to: Microsoft Intune Devices Compliance policies Create Windows Compliance Policy: Create policy Windows 10 and later Device Health: Require BitLocker: Yes Require Secure Boot: Yes Require code integrity: Yes Device Properties: Minimum OS version: 10.0.19044 (21H2) Maximum OS version: (leave blank) System Security: Require password: Yes Minimum password length: 12 Password expiration: 90 days Require encryption: Yes Firewall: Required Antivirus: Required Antispyware: Required Real-time protection: Required Microsoft Defender for Endpoint: Require device to be at or under risk score: Medium Actions for non-compliance: - Mark device non-compliant: Immediately - Send email to user: After 1 day - Retire device: After 30 days (optional)
9

Require Compliant Device in Conditional Access

Entra ID
Create CA Policy for Device Compliance: Navigate to: Security Conditional Access New policy Policy: ZT-RequireCompliantDevice Assignments: - Users: All users - Exclude: Guest users (handle separately) Target Resources: - Cloud apps: Office 365, Salesforce, Critical Apps Conditions: - Device platforms: Windows, macOS, iOS, Android - Filter for devices: (optional - corporate only) Access Controls: - Grant: Require device to be marked as compliant - OR: Require Hybrid Azure AD joined device Session: - Continuous access evaluation: Enabled --- For BYOD/Unmanaged: Create separate policy with: - Require approved client app - Require app protection policy - Block download/copy (session controls)
10

Endpoint Detection & Response (EDR)

Defender
Microsoft Defender for Endpoint Integration: Navigate to: security.microsoft.com Settings Endpoints Key Features for Zero Trust: 1. Real-Time Risk Scoring - Device risk score: Low/Medium/High - Feeds into Conditional Access 2. Threat & Vulnerability Management - Identifies unpatched software - Security recommendations - Feeds into compliance 3. Attack Surface Reduction - Block Office macros from child processes - Block credential stealing from LSASS - Block unsigned executables from USB 4. Automated Investigation & Response - Auto-quarantine malware - Isolate compromised devices - Collect forensic data Integration with Conditional Access: Settings Advanced features Microsoft Intune connection: On Now Conditional Access can: - Block devices with high risk score - Require remediation before access
11

Device Trust for Cloud Workloads

AWS/GCP
# AWS: Instance Identity for Workloads # EC2 instances have instance identity documents # Validate instance identity curl http://169.254.169.254/latest/dynamic/instance-identity/document # Use IAM roles attached to instances # Avoid storing credentials on instances # GCP: Confidential Computing # Enable Confidential VMs for sensitive workloads gcloud compute instances create secure-vm \ --confidential-compute \ --machine-type=n2d-standard-4 \ --min-cpu-platform="AMD Milan" \ --image-family=ubuntu-2204-lts \ --image-project=ubuntu-os-cloud # GCP: Shielded VMs gcloud compute instances create shielded-vm \ --shielded-secure-boot \ --shielded-vtpm \ --shielded-integrity-monitoring # Key principles: # 1. Workloads use managed identity (not keys) # 2. Network policies restrict workload communication # 3. Workload attestation before sensitive operations

Module 3: Network Micro-Segmentation

Module 3: Eliminate Implicit Network Trust

Move from network perimeter to micro-segmented, identity-aware access.

60-90 minutes5 steps
12

Network Zero Trust Principles

Network
Network Zero Trust Requirements: ELIMINATE IMPLICIT TRUST: ✓ No "trusted" network segments ✓ Corporate network = untrusted ✓ All traffic encrypted (TLS 1.3) ✓ No VPN-based full network access MICRO-SEGMENTATION: ✓ Workload-to-workload controls ✓ Application-level segmentation ✓ East-west traffic inspection ✓ Default deny between segments ZERO TRUST NETWORK ACCESS (ZTNA): ✓ Per-application access (not network) ✓ Identity-based access ✓ Device posture checked ✓ Continuous session validation NETWORK VISIBILITY: ✓ All traffic logged ✓ Network Detection & Response (NDR) ✓ DNS query logging ✓ Anomaly detection Traditional VPN vs ZTNA: VPN: Connect to network access everything ZTNA: Authenticate access one application
13

Azure Network Segmentation

Azure
# Azure Network Security Groups (NSG) # Micro-segment by subnet and workload # Create NSG for web tier az network nsg create \ --name web-tier-nsg \ --resource-group production-rg # Allow only HTTPS from internet az network nsg rule create \ --nsg-name web-tier-nsg \ --name AllowHTTPS \ --priority 100 \ --direction Inbound \ --access Allow \ --protocol Tcp \ --destination-port-ranges 443 \ --source-address-prefixes Internet # Deny all other inbound az network nsg rule create \ --nsg-name web-tier-nsg \ --name DenyAllInbound \ --priority 4096 \ --direction Inbound \ --access Deny \ --protocol '*' \ --source-address-prefixes '*' # Application Security Groups (ASGs) # Group VMs by application function az network asg create --name web-servers-asg az network asg create --name api-servers-asg az network asg create --name db-servers-asg # Rule: Only web-servers can talk to api-servers az network nsg rule create \ --nsg-name api-tier-nsg \ --name AllowFromWebTier \ --source-asgs web-servers-asg \ --destination-asgs api-servers-asg \ --destination-port-ranges 8080
14

AWS Security Groups & VPC

AWS
# AWS Zero Trust Network Design # 1. Separate VPCs per environment aws ec2 create-vpc --cidr-block 10.1.0.0/16 --tag "Name=production-vpc" aws ec2 create-vpc --cidr-block 10.2.0.0/16 --tag "Name=development-vpc" # 2. Private subnets (no internet gateway) aws ec2 create-subnet \ --vpc-id vpc-xxx \ --cidr-block 10.1.1.0/24 \ --tag "Name=private-app-subnet" # 3. Security Groups (stateful micro-segmentation) # Web tier SG aws ec2 create-security-group \ --group-name web-sg \ --description "Web tier - HTTPS only" aws ec2 authorize-security-group-ingress \ --group-id sg-web \ --protocol tcp \ --port 443 \ --cidr 0.0.0.0/0 # App tier SG - only from web tier aws ec2 authorize-security-group-ingress \ --group-id sg-app \ --protocol tcp \ --port 8080 \ --source-group sg-web # DB tier SG - only from app tier aws ec2 authorize-security-group-ingress \ --group-id sg-db \ --protocol tcp \ --port 5432 \ --source-group sg-app # 4. VPC Flow Logs for visibility aws ec2 create-flow-logs \ --resource-type VPC \ --resource-ids vpc-xxx \ --traffic-type ALL \ --log-destination-type cloud-watch-logs
15

Kubernetes Network Policies

Kubernetes
# Kubernetes Network Policies for Zero Trust # Default deny all ingress apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: production spec: podSelector: {} policyTypes: - Ingress - Egress --- # Allow frontend to backend only apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-backend namespace: production spec: podSelector: matchLabels: app: backend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080 --- # Allow backend to database only apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend-to-db namespace: production spec: podSelector: matchLabels: app: database policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: backend ports: - protocol: TCP port: 5432
16

Zero Trust Network Access (ZTNA)

ZTNA
ZTNA Solutions (Replace VPN): MICROSOFT: - Entra Private Access (preview) - Per-app tunnels - Integrates with Conditional Access CLOUDFLARE ACCESS: - Identity-aware proxy - No VPN client needed - Browser-based access ZSCALER PRIVATE ACCESS: - Software-defined perimeter - Inside-out connectivity - No inbound connections GOOGLE BEYONDCORP: - Original Zero Trust implementation - Context-aware access proxy - IAP (Identity-Aware Proxy) ZTNA Benefits over VPN: ✓ Application-level (not network) ✓ No lateral movement possible ✓ Identity and device verification per-request ✓ Works from anywhere (no network dependency) ✓ Better user experience ✓ Reduced attack surface Migration Path: 1. Deploy ZTNA for new apps 2. Migrate existing apps progressively 3. Deprecate VPN for end users 4. Keep VPN only for legacy (temporary)

Module 4: Application-Level Security

Module 4: Secure Every Application Access

Move authentication and authorization to the application layer.

45-60 minutes4 steps
17

Application Zero Trust

Application
Application Zero Trust Requirements: AUTHENTICATION: ✓ SSO via central IdP (no app-local accounts) ✓ Modern protocols (OIDC/SAML) ✓ Per-application MFA policies ✓ Session management AUTHORIZATION: ✓ Fine-grained permissions ✓ API-level authorization ✓ Scope-based access tokens ✓ Consent management API SECURITY: ✓ OAuth 2.0 for authorization ✓ Short-lived access tokens ✓ Token validation on every request ✓ Rate limiting ✓ API gateway enforcement APPLICATION INVENTORY: ✓ Discover all applications (shadow IT) ✓ Risk categorization ✓ Integration with IdP ✓ Deprecate legacy apps
18

Integrate All Apps with SSO

Entra ID
Navigate to: Entra ID Enterprise applications Integration Priority: 1. Business-critical apps (ERP, CRM) 2. Apps with sensitive data 3. Apps accessed by external users 4. Remaining internal apps For Each Application: SAML Integration: Add application Create your own Configure SAML Upload IdP metadata Configure attribute mapping Test SSO OIDC Integration: App registrations New registration Configure redirect URIs Create client secret (or use certificates) Configure scopes/permissions Conditional Access per App: Create CA policy targeting specific app Require MFA Require compliant device Block risky sign-ins Shadow IT Discovery: Microsoft Defender for Cloud Apps Discover cloud apps Risk assessment Sanction or block
19

API Gateway Zero Trust

API Gateway
# AWS API Gateway with JWT Authorization # Create authorizer for Cognito/OIDC aws apigateway create-authorizer \ --rest-api-id abc123 \ --name CognitoAuthorizer \ --type COGNITO_USER_POOLS \ --provider-arns arn:aws:cognito-idp:us-east-1:123:userpool/xxx # Or custom JWT authorizer (Lambda) aws apigateway create-authorizer \ --rest-api-id abc123 \ --name JWTAuthorizer \ --type TOKEN \ --authorizer-uri arn:aws:lambda:us-east-1:123:function:jwt-auth # Apply authorizer to method aws apigateway put-method \ --rest-api-id abc123 \ --resource-id xyz789 \ --http-method GET \ --authorization-type COGNITO_USER_POOLS \ --authorizer-id auth123 # API Gateway Best Practices: # 1. Validate JWTs on every request # 2. Check token scopes match API requirements # 3. Use short-lived tokens (< 1 hour) # 4. Log all API requests # 5. Rate limit per client/user # 6. Use mTLS for service-to-service
20

Service Mesh for Microservices

Istio
# Istio Authorization Policy (Zero Trust for Microservices) # Deny all by default apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: deny-all namespace: production spec: {} # Empty spec = deny all --- # Allow frontend to call backend with valid JWT apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: backend-policy namespace: production spec: selector: matchLabels: app: backend action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/production/sa/frontend"] when: - key: request.auth.claims[iss] values: ["https://login.microsoftonline.com/tenant-id/v2.0"] --- # Require mTLS for all traffic apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: production spec: mtls: mode: STRICT

Module 5: Data Protection & Classification

Module 5: Protect Data Regardless of Location

Classify, encrypt, and control access to sensitive data.

45-60 minutes4 steps
21

Data Zero Trust Principles

Data
Data Zero Trust Requirements: DATA CLASSIFICATION: ✓ Automatic classification ✓ Sensitivity labels ✓ Visual markings ✓ Data owner identification DATA PROTECTION: ✓ Encryption at rest ✓ Encryption in transit (TLS 1.3) ✓ Customer-managed keys ✓ Rights management (DRM) DATA LOSS PREVENTION (DLP): ✓ Content inspection ✓ Block sensitive data exfiltration ✓ Endpoint DLP ✓ Cloud DLP ACCESS CONTROL: ✓ Data-level permissions ✓ Time-limited access ✓ Access logging ✓ Anomaly detection Classification Levels: Public (Green) Internal (Yellow) Confidential (Orange) Highly Confidential (Red) Restricted (Black)
22

Microsoft Purview Data Protection

Purview
Navigate to: compliance.microsoft.com Information protection Create Sensitivity Labels: Labels Create a label Label: Highly Confidential - Scope: Items (files, emails) - Encryption: ✓ Encrypt content ✓ Assign permissions now ✓ Users: Specific users/groups ✓ Permissions: Co-Author ✓ Offline access: 7 days ✓ Content expires: Never - Content marking: ✓ Header: "HIGHLY CONFIDENTIAL" ✓ Footer: "Do not distribute" ✓ Watermark: User email - Auto-labeling: ✓ Credit card numbers ✓ SSN patterns ✓ Custom regex patterns Publish Labels: Label policies Create policy - Labels to publish: All labels - Users: All users - Policy settings: ✓ Require justification to remove label ✓ Require users to apply label ✓ Default label for documents: General
23

AWS Data Protection

AWS
# AWS Data Protection for Zero Trust # 1. S3 Default Encryption (SSE-S3 or SSE-KMS) aws s3api put-bucket-encryption \ --bucket my-bucket \ --server-side-encryption-configuration '{ "Rules": [{ "ApplyServerSideEncryptionByDefault": { "SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "arn:aws:kms:xxx" }, "BucketKeyEnabled": true }] }' # 2. Block public access (organization level) aws s3control put-public-access-block \ --account-id 123456789012 \ --public-access-block-configuration \ BlockPublicAcls=true,\ IgnorePublicAcls=true,\ BlockPublicPolicy=true,\ RestrictPublicBuckets=true # 3. Macie for sensitive data discovery aws macie2 enable-macie aws macie2 create-classification-job \ --job-type ONE_TIME \ --s3-job-definition '{ "bucketDefinitions": [{ "accountId": "123456789012", "buckets": ["my-bucket"] }] }' # 4. KMS key policy - require encryption context # 5. S3 Object Lock for immutability # 6. VPC endpoints for private access
24

DLP Policies

DLP
Microsoft Purview DLP: Data loss prevention Policies Create policy Policy: Block Credit Card Sharing Locations: ✓ Exchange email ✓ SharePoint sites ✓ OneDrive accounts ✓ Teams chat and channel ✓ Devices Conditions: - Content contains: Credit card number - Content is shared with: People outside organization Actions: - Block sharing with external users - Encrypt content - Notify user with policy tip - Alert admin User Overrides: - Allow override with business justification - Require report to compliance team Testing: 1. Create test mode policy first 2. Review matches in activity explorer 3. Tune conditions to reduce false positives 4. Enable enforcement

Module 6: Continuous Verification & Risk

Module 6: Never Stop Verifying

Implement continuous authentication and risk assessment.

45-60 minutes4 steps
25

Continuous Access Evaluation

Entra ID
Continuous Access Evaluation (CAE): Traditional: Token valid until expiration (1 hour) CAE: Token revoked in near real-time on critical events Critical Events That Trigger Re-evaluation: - User account disabled - User password changed - MFA credentials changed - Admin revokes all tokens - High-risk user detected - Network location changes Enable CAE: Conditional Access Session controls Customize continuous access evaluation: Enabled Supported Apps: - Exchange Online - SharePoint Online - Teams - Microsoft Graph Result: Before CAE: Disabled user access for up to 1 hour After CAE: Disabled user blocked within minutes Configure Strict Location Enforcement: Enable strict location enforcement Token reevaluated on IP change
26

Session Risk Monitoring

SIEM
Continuous Risk Assessment Signals: IDENTITY SIGNALS: - Sign-in from new location - Sign-in from new device - Impossible travel - Password spray attack - Credential stuffing - Token anomaly DEVICE SIGNALS: - Compliance state change - Malware detected - Jailbreak detected - Configuration drift NETWORK SIGNALS: - Connection from Tor - VPN usage - Anonymous proxy - Unusual bandwidth BEHAVIOR SIGNALS: - Unusual file access patterns - Mass download/deletion - Off-hours access - Sensitive data access Response Actions (Automated): - Low risk: Log and monitor - Medium risk: Step-up authentication - High risk: Block and alert - Critical: Terminate session, disable account
27

UEBA - User Behavior Analytics

Sentinel
# Microsoft Sentinel UEBA Configuration # Enable UEBA # Settings Settings UEBA Enable # Configure entity behavior # Entities tracked: Users, Devices, IP Addresses # Anomaly Detection Rules: # 1. Anomalous login # 2. Anomalous Azure AD activity # 3. Anomalous Office 365 activity # 4. First access to resource # 5. Unusual data access # Create Analytics Rule for Insider Threat # Analytics Create Scheduled query rule let threshold = 100; let timeframe = 1h; OfficeActivity | where TimeGenerated > ago(timeframe) | where Operation in ("FileDownloaded", "FileSyncDownloadedFull") | summarize DownloadCount = count() by UserId | where DownloadCount > threshold | project UserId, DownloadCount, TimeGenerated # Response Playbook: # 1. Alert security team # 2. Disable user account (high severity) # 3. Create incident # 4. Start investigation
28

Token Lifetime Policies

Entra ID
# Configure Token Lifetimes (Zero Trust = Shorter) # Using Microsoft Graph API # Create token lifetime policy POST https://graph.microsoft.com/v1.0/policies/tokenLifetimePolicies { "definition": [ "{\"TokenLifetimePolicy\":{\"Version\":1,\"AccessTokenLifetime\":\"01:00:00\",\"MaxAgeSessionSingleFactor\":\"08:00:00\"}}" ], "displayName": "ZeroTrust-ShortTokens", "isOrganizationDefault": true } # Zero Trust Token Recommendations: # Access Token: 1 hour (default, can't shorten further) # Refresh Token (Single Factor): 8 hours # Refresh Token (MFA): 24 hours # Session (Single Factor): 8 hours # Session (MFA): 24 hours # Conditional Access Sign-in Frequency: # Session controls Sign-in frequency # Enforce: Every 4 hours (high security apps) # Force re-auth for sensitive operations: # Configure step-up authentication for: # - Password change # - MFA registration # - Privileged actions

Module 7: Zero Trust for Cloud & SaaS

Module 7: Secure Multi-Cloud and SaaS

Extend Zero Trust principles to cloud infrastructure and SaaS applications.

45-60 minutes4 steps
29

Cloud Security Posture Management

CSPM
Cloud Zero Trust via CSPM: Microsoft Defender for Cloud: Environment settings Enable all plans Coverage: ✓ CSPM (Cloud Security Posture Management) ✓ CWP (Cloud Workload Protection) ✓ Defender for Servers ✓ Defender for Containers ✓ Defender for Storage ✓ Defender for Databases Security Recommendations: - Enable MFA for accounts with owner permissions - Remove deprecated accounts - Enable encryption at rest - Enable network security groups - Disable public access to storage - Enable diagnostic logging Secure Score: - Target: 80%+ for Zero Trust - Prioritize by impact and difficulty - Track improvement over time Multi-Cloud: Connect AWS accounts Connect GCP projects Unified security view
30

SaaS Security (CASB)

Defender for Cloud Apps
Microsoft Defender for Cloud Apps (CASB): Cloud Discovery: Discover Cloud app catalog - 31,000+ apps assessed - Risk score based on 80+ factors - Shadow IT visibility App Governance: Policies App governance - Monitor OAuth app permissions - Detect overprivileged apps - Revoke suspicious app access Session Policies: Policies Conditional Access App Control - Real-time monitoring - Block downloads from unmanaged devices - Apply DLP in real-time - Block upload of malware Activity Policies: Policies Activity policy - Detect mass downloads - Detect external sharing - Detect admin account compromise - Alert on suspicious activity File Policies: Policies File policy - Scan for sensitive content - Apply labels automatically - Quarantine risky files
31

Infrastructure as Code Security

IaC
# Zero Trust for Infrastructure as Code # 1. Scan IaC templates before deployment # Checkov - open source IaC scanner pip install checkov checkov -d ./terraform --framework terraform # 2. Enforce policies in CI/CD # GitHub Actions example name: IaC Security Scan on: [push, pull_request] jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Checkov uses: bridgecrewio/checkov-action@master with: directory: terraform/ framework: terraform soft_fail: false # Fail pipeline on issues # 3. Policy as Code (OPA/Rego) # Deny public S3 buckets package terraform.aws deny[msg] { resource := input.resource.aws_s3_bucket[name] resource.acl == "public-read" msg := sprintf("S3 bucket %v has public ACL", [name]) } # 4. Drift Detection # Terraform Cloud/Enterprise # Detect when actual state differs from code
32

Workload Identity Zero Trust

Workload
Workload Identity Zero Trust Principles: NO LONG-LIVED CREDENTIALS: ✗ Service account keys ✗ Hardcoded secrets ✗ Static API keys USE FEDERATED IDENTITY: ✓ AWS IAM Roles (IRSA for EKS) ✓ Azure Managed Identity ✓ GCP Workload Identity ✓ SPIFFE/SPIRE for multi-cloud WORKLOAD ATTESTATION: ✓ Verify workload identity before issuing credentials ✓ Check workload integrity ✓ Validate deployment context LEAST PRIVILEGE: ✓ Minimal permissions per workload ✓ Scoped to specific resources ✓ Time-limited where possible SECRETS MANAGEMENT: ✓ Fetch secrets at runtime (not baked in) ✓ Automatic rotation ✓ Audit secret access ✓ Solutions: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager

Module 8: Maturity Assessment & Roadmap

Module 8: Measure and Improve Zero Trust Maturity

Assess current state and build implementation roadmap.

45-60 minutes4 steps
33

Zero Trust Maturity Model

Assessment
Level 1: Traditional

Perimeter-based security, VPN access, passwords only, flat network, implicit trust inside

Level 2: Initial

MFA deployed, some SSO, basic network segmentation, endpoint protection

Level 3: Advanced

Risk-based auth, device compliance, micro-segmentation, CASB, some automation

Level 4: Optimal

Continuous verification, full ZTNA, automated response, data-centric security

Level 5: Adaptive

ML-driven decisions, real-time risk, self-healing, fully automated, predictive

34

Assessment Checklist by Pillar

Checklist
Identity
  • MFA for all users
  • Phishing-resistant MFA (FIDO2)
  • SSO for all applications
  • Risk-based Conditional Access
  • JIT privileged access (PIM)
  • Automated lifecycle (JML)
  • Regular access reviews
Device
  • All devices enrolled in MDM
  • Compliance policies enforced
  • EDR deployed
  • Device health in access decisions
  • Disk encryption required
  • Patch compliance monitored
Network
  • Network segmentation
  • Default deny rules
  • ZTNA deployed (vs VPN)
  • Encrypted traffic (TLS 1.3)
  • Network flow logging
  • NDR/NTA deployed
Application
  • All apps integrated with IdP
  • Shadow IT discovered
  • API authentication enforced
  • Session controls configured
  • CASB deployed
Data
  • Data classification in place
  • Encryption at rest
  • Encryption in transit
  • DLP policies enforced
  • Data access logging
  • Rights management
35

Implementation Roadmap

Roadmap
Zero Trust Implementation Phases: PHASE 1: FOUNDATION (Months 1-3) Deploy MFA for all users Integrate critical apps with SSO Enable Identity Protection Deploy endpoint protection Baseline network segmentation Establish monitoring/logging PHASE 2: ENHANCEMENT (Months 4-6) Implement Conditional Access policies Deploy device compliance Configure PIM for privileged access Implement data classification Deploy CASB for SaaS visibility ZTNA pilot for new apps PHASE 3: OPTIMIZATION (Months 7-9) Phishing-resistant MFA rollout Micro-segmentation implementation Full ZTNA deployment Automated lifecycle workflows DLP policy enforcement Continuous verification (CAE) PHASE 4: MATURITY (Months 10-12) ML-driven risk scoring Automated response playbooks Full visibility and analytics Regular posture assessments Continuous improvement process Success Metrics: - MFA adoption: 100% - SSO coverage: 95%+ - Mean time to revoke: < 1 hour - Secure score: 80%+
36

Quick Wins & Priority Actions

Quick Wins

Top 10 Zero Trust Quick Wins

  • Enable MFA for everyone - Immediate impact, blocks 99.9% of account compromises
  • Block legacy authentication - Eliminates MFA bypass
  • Require compliant devices - Extends trust to endpoints
  • Enable Identity Protection - Risk-based access decisions
  • Implement PIM - Eliminate standing privileged access
  • Configure break-glass accounts - Emergency access procedures
  • Enable audit logging everywhere - Visibility is foundational
  • Integrate top 10 apps with SSO - Quick coverage wins
  • Deploy endpoint protection - Device health signals
  • Enable Continuous Access Evaluation - Near real-time revocation

Implementation Playbook Summary

ZERO TRUST DECISION FLOW

1. Who is the user?

Strong authentication, MFA, identity verification

2. Is the device trusted?

Managed, compliant, healthy, encrypted

3. What's the risk context?

Location, time, behavior, threat signals

4. What resource is requested?

Sensitivity level, data classification

5. Is access appropriate?

Least privilege, need to know, JIT

6. Grant with continuous monitoring

Session controls, CAE, anomaly detection