Q: What ZTNA policy grants least-privilege access with automatic expiration, and how do you prevent lateral movement if the contractor's account is compromised?

ZTNA policy design: (1) **Application-specific access only**: the contractor receives access to `jenkins.internal.company.com:8443` via a browser-based ZTNA gateway. No network-level access, no subnet reachability. The ZTNA gateway (Cloudflare Access, Zscaler ZPA, Palo Alto Prisma Access) acts as a reverse proxy — the contractor never sees the internal IP. (2) **Time-bound automatic expiration**: the account is created in Azure AD / Okta with an expiration date (14 days). On day 15, the account is automatically disabled via **Lifecycle Management** workflow. No manual cleanup needed. (3) **Device posture requirements**: even for BYOD contractors, enforce browser-based checks — current browser version, no anonymizer extensions, and geolocation within approved regions. (4) **Session recording**: all Jenkins web sessions are recorded at the ZTNA gateway for audit and compliance review. Lateral movement prevention: (1) **Micro-segmentation around Jenkins**: the Jenkins server lives in an isolated micro-segment (dedicated VLAN/VPC) with no outbound access except to Git repositories on TCP 443. Even if compromised, the contractor cannot scan the network. (2) **No credential storage on device**: Jenkins access uses short-lived OIDC tokens (15-minute expiry) rather than passwords or API keys stored on the contractor laptop. (3) **Deception tokens**: place fake SSH keys and AWS credentials in the Jenkins workspace as canary tokens. If an attacker uses them, an immediate alert fires to the SOC. (4) **Just-enough admin**: the contractor account has only `Job/Build` and `Job/Read` permissions, not `Overall/Administer`.

Question 1

What three architectural differences make ZTNA fundamentally more secure than legacy VPN, and what is the migration sequencing?

Accepted Answer

Legacy VPN grants **network-level access** — once authenticated, the user is inside the corporate perimeter with implicit trust to scan, pivot, and attack lateral targets. ZTNA (Zero Trust Network Access) replaces this with **identity-aware, per-application micro-tunnels**. Three differences: (1) **Least-privilege access**: instead of `10.0.0.0/8`, the user gets access only to `jira.company.com` and `confluence.company.com` on TCP 443, nothing else. (2) **Device posture validation**: every session re-evaluates device health — is EDR running? Is the OS patched? Is the device jailbroken? VPN typically checks once at connection time. (3) **No flat network**: ZTNA uses a reverse proxy or software-defined perimeter (SDP) architecture where each app connection is independently authenticated and authorized. There is no "inside" to pivot to. Migration sequencing: **Phase 1 (Weeks 1-4)**: Pilot ZTNA for low-risk SaaS apps (O365, Salesforce) with a volunteer group of 500 users. Keep VPN as fallback. **Phase 2 (Weeks 5-10)**: Migrate all remote users to ZTNA for sanctioned SaaS and web apps. **Phase 3 (Weeks 11-12)**: Move legacy RDP/SSH access to ZTNA brokered connections with session recording. **Phase 4 (Week 13)**: Decommission VPN entirely after confirming 99.9% ZTNA adoption. Critical: maintain **parallel identity sources** (Active Directory + IdP) during cutover to avoid lockouts.

Question 2

What four criteria evaluate a "true SASE" platform vs. a bundled acquisition, and which components are hardest to consolidate?

Accepted Answer

A **true SASE** platform converges networking and security in a **single-pass cloud-native architecture**, not a bundle of acquired products stitched together. Four criteria: (1) **Converged data plane**: traffic is inspected once for all functions (SWG, CASB, ZTNA, FWaaS) rather than chaining through separate VMs or services. Look for vendors advertising "single-pass SSL inspection." (2) **Unified policy engine**: one policy language controls access, DLP, threat prevention, and QoS. If you need three different UIs to configure ZTNA and CASB, it is not unified. (3) **Single agent / agentless option**: users should not need separate agents for VPN, DLP, and web security. (4) **Common identity context**: the user identity, device posture, and risk score must be shared across all SASE functions in real-time. **Hardest to consolidate**: **CASB API inspection** is the deepest integration — it requires OAuth app registration, deep understanding of each SaaS API (Salesforce, Slack, GitHub), and continuous updates as SaaS vendors change APIs. A vendor that acquired a CASB cannot easily merge it into a unified engine without rebuilding the connectors. **SD-WAN underlay optimization** is also hard to merge because it requires hardware/firmware at branch edges, while SASE is cloud-delivered. The best-of-breed vs. single-vendor decision depends on team size: smaller teams benefit from single-vendor simplicity; enterprises with dedicated CASB/SWG teams may prefer best-of-breed with API integration.

Question 3

How does an identity-aware proxy (IAP) enable BYOD without MDM enrollment, and what three contextual signals gate access?

Accepted Answer

An **Identity-Aware Proxy (IAP)** is a reverse proxy that sits in front of internal applications. It terminates TLS, authenticates the user via corporate IdP (Okta, Azure AD), evaluates context, and only then forwards the request to the backend. BYOD without MDM works because IAP is **agentless for the user experience** — contractors access apps through a browser with SSO login, no software installation required. The proxy enforces security at the gateway. Three contextual signals: (1) **User identity + MFA**: the contractor must authenticate with corporate credentials and pass MFA (TOTP, push, or hardware key). (2) **Device hygiene signals via browser**: even without an agent, the IAP can collect signals via JavaScript and HTTP headers — browser version, OS patch level, screen resolution, and presence of enterprise certificates. Some IAPs (Cloudflare Access, Zscaler ZPA) use lightweight browser extensions for deeper checks. (3) **Geolocation and time-of-day**: if the contractor normally logs in from Bangalore 9 AM-6 PM IST, a login at 3 AM from an anonymizer IP triggers step-up auth or block. Limitation: without MDM, there is no device-level DLP (clipboard monitoring, screen capture blocking). Mitigation: apply **in-browser DLP** via CASB inline controls — disable download/upload for sensitive Confluence spaces, apply visible watermarks to pages, and block print-to-PDF for classified content. Session recording via the IAP can also provide audit trails.

Question 4

What Zero Trust segmentation model protects OT without breaking real-time SCADA communication?

Accepted Answer

The **Purdue Model + Zero Trust Micro-segmentation** approach. Traditional VLANs are insufficient because they are coarse — one VLAN for all OT means any compromised device can scan everything. The modern approach uses **identity-based micro-segmentation** with protocol awareness. Architecture: (1) **Passive asset discovery**: tools like Armis, Claroty, or Nozomi passively fingerprint OT devices by MAC OUI, DHCP fingerprints, Modbus/DNP3 behavior, and known vendor signatures. Each PLC, HMI, and RTU is tagged by Purdue level (Level 0 = physical process, Level 1 = basic control, Level 2 = supervisory). (2) **Micro-segment policies**: instead of VLANs, use **software-defined micro-segmentation** (Illumio, Guardicore, VMware NSX) or **policy-based routing** on industrial switches. Example policies: Level 3 (IT DMZ) can initiate to Level 2 (supervisory) on TCP 44818 (EtherNet/IP) and UDP 2222 (IGNITE), but Level 2 cannot initiate to Level 1 (PLCs). Level 1 can only communicate with Level 0 within the same production line. (3) **Protocol whitelisting by function code**: Modbus TCP allows many function codes (read coils, write registers, diagnostics). Allow only `Read Holding Registers (0x03)` and `Read Input Registers (0x04)` from SCADA to PLCs; block `Write Multiple Coils (0x0F)` and `Diagnostics (0x08)` except from authorized engineering workstations. **Critical for real-time**: SCADA polling traffic must not traverse stateful firewalls with default 30-second idle timeouts, as this breaks periodic Modbus polls. Use **stateless ACLs** or tune session timers to 1-5 seconds for OT protocols. Implement **out-of-band monitoring** via SPAN ports so security tools do not add latency to control traffic.

Question 5

What two CASB deployment modes discover shadow IT, and how do you block unsanctioned uploads without breaking business workflows?

Accepted Answer

**Discovery modes**: (1) **API CASB** connects to sanctioned SaaS apps (O365, Salesforce, Box) via OAuth/API to monitor data at rest — shared files, external collaborators, DLP policy violations. This only sees the 10 connected apps. (2) **Forward proxy / SWG-based discovery** sees all web traffic because all user web requests pass through the SWG. The SWG fingerprints SaaS apps by analyzing SSL certificates, SNI headers, DNS queries, and HTTP patterns. It categorizes discovered apps by function (file sharing, collaboration, CRM) and risk score. Shadow IT discovery = analyzing SWG logs for high-volume traffic to unsanctioned categories. **Blocking strategy with business continuity**: use **sanctioning tiers** rather than binary block/allow. Tier 1 (Sanctioned): full access with DLP scanning — O365, Google Workspace, corporate Slack. Tier 2 (Tolerated): read-only access, no upload/download — personal Dropbox, Notion free tier. Users can reference content but not exfiltrate corporate data. Tier 3 (Blocked): complete block with a custom block page suggesting the approved alternative ("You tried to upload to personal Dropbox. Use company OneDrive instead"). For uploads specifically: **real-time DLP scanning on the forward proxy** intercepts HTTPS uploads, decrypts with enterprise CA, scans for PII/credentials using regex and ML classifiers, and blocks before the upload completes. If the file is encrypted (password-protected zip), block all uploads >10MB to unsanctioned Tier 3 apps regardless of content.

Question 6

What three SASE architecture decisions affect latency, and how do you design for sub-100ms application response globally?

Accepted Answer

Three latency factors: (1) **PoP proximity and hairpinning**: if the India office SD-WAN sends all traffic to the Singapore SASE PoP, every packet travels ~4,000 km round-trip (~80-120ms) before reaching Salesforce. Solution: **deploy a local SASE PoP** in Mumbai or use **SD-WAN with local internet breakout** for trusted SaaS. Salesforce is a well-known SaaS app — send it directly via local DIA (Direct Internet Access) instead of backhauling to Singapore. Use the SASE PoP only for corporate apps and inspected traffic. (2) **SSL inspection overhead**: full TLS break-and-inspect (decrypt, scan, re-encrypt) adds 1-3 RTTs per connection. For latency-sensitive apps, use **selective inspection** — inspect uncategorized and high-risk sites, but bypass inspection for known-good SaaS (Salesforce, Zoom, Microsoft) using vendor-maintained URL categories. Enable **hardware SSL acceleration** (Intel QAT, dedicated crypto cards) at the PoP. (3) **Backbone vs. internet path quality**: SASE vendors use private backbones (Zscaler Private Access, Cloudflare Argo, Palo Alto Prisma). Use **RIPE Atlas** or **ThousandEyes** to measure latency from India to SaaS apps via vendor backbone vs. direct internet. If direct internet is faster for a given app, configure **split tunneling** in the SASE client: corporate traffic → SASE PoP; SaaS traffic → direct internet. Target architecture for sub-100ms: local DIA for SaaS (20-40ms to app) + local SASE PoP for corporate (20-40ms to PoP) + SD-WAN underlay optimization (FEC, packet duplication) for real-time voice.

Question 7

What service mesh feature enforces Zero Trust between microservices without sidecars, and what are the trade-offs?

Accepted Answer

**Sidecar-less service mesh** architectures eliminate the per-pod proxy while maintaining mTLS and L4 policy. Two leading implementations: **Istio Ambient Mesh** and **Cilium Service Mesh**. In Istio Ambient, a lightweight **ztunnel** (zero-trust tunnel) runs per node instead of per pod. It handles L4 encryption and authentication via eBPF or iptables redirection. For services needing L7 routing (retries, traffic splitting, authorization policies), **waypoint proxies** are deployed only for those specific services — not fleet-wide. Cilium Service Mesh uses **eBPF** in the kernel to handle L4 load balancing, mTLS, and network policy without any per-pod or per-node proxy for basic cases. Trade-offs: (1) **Identity granularity**: sidecars have per-pod SPIFFE identities. Sidecar-less uses per-node identity (ztunnel) or per-service identity (Cilium), which is coarser. If two microservices on the same node need different policies, sidecar-less may struggle without waypoint proxies. (2) **L7 capabilities**: sidecars provide rich L7 metrics, tracing, and routing out of the box. Sidecar-less requires explicit waypoint proxies for L7, reintroducing some overhead for services that need it. (3) **Resource savings**: sidecar-less reduces memory by 40-60% and CPU by 20-30% because there are no Envoy proxies in every pod. This is the primary driver for adoption. Recommendation: use **ambient mesh** for all services needing L4 mTLS (automatic, no config), and add **waypoint proxies** only for services needing L7 authorization or complex routing. Verify with `istioctl proxy-status` (shows ztunnels and waypoints) or `cilium service list` for eBPF-based services.

Question 8

What Zero Trust feature reduces session hijacking risk, and how do you implement step-up authentication for sensitive actions?

Accepted Answer

The core problem is **long-lived sessions with no continuous validation**. Zero Trust mitigates this with **continuous authentication and risk-based step-up**. Implementation layers: (1) **Short session TTL with re-authentication**: reduce SSO session lifetime from 12 hours to 4 hours, with forced re-authentication for admin roles. Azure AD Conditional Access: `Session > Sign-in frequency > 4 hours`. (2) **Device-centric session binding**: bind the session cryptographically to the device using a **device certificate** stored in TPM or a **hardware security key** (YubiKey, Windows Hello). If the device changes (stolen laptop vs. new browser), the session is invalid even with the same cookies. (3) **Real-time risk engine**: integrate Azure AD Identity Protection, Okta Identity Engine, or Google BeyondCorp with the SSO provider. Risk signals include impossible travel, anonymizer IP usage, new device fingerprint, and malware detection. If risk score exceeds "medium," trigger step-up MFA. (4) **Just-in-time (JIT) privileged access**: for sensitive actions (AWS `DeleteBucket`, IAM changes, cost center modifications), require time-bound elevation via **Privileged Identity Management (PIM)**. Example: user requests AWS Admin role in Azure AD PIM, manager approves via Teams adaptive card, JIT token issued for 2 hours with full audit trail. AWS SSO + Azure AD PIM integration makes this seamless. (5) **Session revocation on device loss**: MDM (Intune, Jamf) detects device as "lost" and pushes a signal to IdP to revoke all sessions for that device within minutes.

Question 9

How does SASE handle real-time traffic QoS without an MPLS SLA, and what is the SD-WAN underlay requirement?

Accepted Answer

SASE is a cloud-delivered security overlay — it does not inherently guarantee QoS because it rides over the public internet or broadband. **SD-WAN provides the underlay QoS; SASE provides the security overlay**. Architecture: (1) **SD-WAN edge with multiple transports**: each branch has broadband + LTE + optional fiber. SD-WAN CPE (Cisco Meraki, Palo Alto Prisma, Fortinet, Versa) monitors link quality (latency, jitter, packet loss) in real-time. Voice traffic marked DSCP EF is automatically sent over the best available link (typically fiber or low-latency broadband). If the primary link degrades, failover to LTE happens in <1 second. (2) **Forward Error Correction (FEC) and packet duplication**: for VoIP, SD-WAN can send duplicate packets over two links simultaneously. If one link drops packets, the receiver uses the duplicate. This compensates for internet unpredictability. (3) **SASE PoP integration**: SD-WAN forms IPsec/GRE tunnels from the branch edge to the nearest SASE PoP. The SASE cloud applies security (SWG, CASB, ZTNA) after SD-WAN has already optimized the transport. **QoS preservation**: SD-WAN copies the inner DSCP value to the outer IPsec header (`copy-dscp enable`), so the SASE cloud and intermediate networks honor the same priority. Critical: voice traffic should **not** be backhauled to a distant DC — send it to the nearest SASE PoP or use **local internet breakout** for trusted voice services (Zoom, Teams) if they are not inspected. Vendor convergence: Palo Alto Prisma SD-WAN + Prisma Access, Cisco Meraki + Umbrella, Fortinet SD-WAN + FortiSASE, and Versa SASE all offer this integrated model.

Question 10

What ZTNA policy grants least-privilege access with automatic expiration, and how do you prevent lateral movement if the contractor's account is compromised?

Accepted Answer

ZTNA policy design: (1) **Application-specific access only**: the contractor receives access to `jenkins.internal.company.com:8443` via a browser-based ZTNA gateway. No network-level access, no subnet reachability. The ZTNA gateway (Cloudflare Access, Zscaler ZPA, Palo Alto Prisma Access) acts as a reverse proxy — the contractor never sees the internal IP. (2) **Time-bound automatic expiration**: the account is created in Azure AD / Okta with an expiration date (14 days). On day 15, the account is automatically disabled via **Lifecycle Management** workflow. No manual cleanup needed. (3) **Device posture requirements**: even for BYOD contractors, enforce browser-based checks — current browser version, no anonymizer extensions, and geolocation within approved regions. (4) **Session recording**: all Jenkins web sessions are recorded at the ZTNA gateway for audit and compliance review. Lateral movement prevention: (1) **Micro-segmentation around Jenkins**: the Jenkins server lives in an isolated micro-segment (dedicated VLAN/VPC) with no outbound access except to Git repositories on TCP 443. Even if compromised, the contractor cannot scan the network. (2) **No credential storage on device**: Jenkins access uses short-lived OIDC tokens (15-minute expiry) rather than passwords or API keys stored on the contractor laptop. (3) **Deception tokens**: place fake SSH keys and AWS credentials in the Jenkins workspace as canary tokens. If an attacker uses them, an immediate alert fires to the SOC. (4) **Just-enough admin**: the contractor account has only `Job/Build` and `Job/Read` permissions, not `Overall/Administer`.

Question 11

What three SSL inspection policies balance security with performance, and how do you handle certificate pinning apps?

Accepted Answer

Full SSL break-and-inspect on all traffic is a **blunt instrument** that degrades real-time apps. Three balancing policies: (1) **Category-based selective inspection**: use the SWG vendor's URL categorization to bypass inspection for known-good, latency-sensitive categories — Video Streaming, Video Conferencing, and Software Updates. Inspect only High Risk, Uncategorized, and Sanctioned SaaS (where DLP matters). Most enterprise SWGs (Zscaler, Netskope, Palo Alto) maintain these categories automatically. (2) **Optimal cipher and protocol selection**: use TLS 1.3 with session resumption to reduce handshake overhead from 2-RTT to 1-RTT (or 0-RTT with early data, though this has replay risks). Disable legacy TLS 1.0/1.1 to avoid unnecessary cipher negotiation. Enable **hardware SSL acceleration** (Intel QAT, dedicated crypto ASICs) on SWG appliances or cloud instances. (3) **Bandwidth-aware inspection**: for large file downloads (ISO images, video files), use **streaming inspection** that scans in chunks rather than buffering the entire file. For real-time video, bypass body inspection and rely on header/metadata analysis. **Certificate pinning apps** (mobile banking apps, some healthcare EHR clients, and modern mobile apps) reject the SWG's substituted CA certificate, causing connection failures. Handling: (1) **Pinning bypass list**: maintain a list of apps that pin (detected by TLS fingerprinting). Exclude them from break-and-inspect. (2) **Passive TLS fingerprinting (JA3/JA4)**: instead of decrypting pinned traffic, analyze the JA3 hash, SNI, and traffic patterns for anomalies. (3) **MDM-deployed SWG CA**: for corporate-managed mobile devices, push the SWG root CA via MDM so pinned apps trust it. For BYOD mobile, pinned apps must bypass inspection.

Question 12

What three technical controls prevent data exfiltration in a Zero Trust model, and how do you handle encrypted uploads?

Accepted Answer

Three controls: (1) **Endpoint DLP agent**: software (Microsoft Endpoint DLP, Symantec DLP, CrowdStrike Falcon) monitors clipboard, USB devices, browser uploads, and print jobs. If the agent detects a file containing PII (detected by regex, ML classification, or RMS labels) being uploaded to an unsanctioned site, it blocks the upload and alerts the SOC. (2) **CASB inline DLP on the forward proxy/SWG**: all web traffic passes through the CASB gateway. When the user attempts to upload to Google Drive, the CASB terminates TLS, decrypts the payload with the enterprise CA, scans content for PII/credentials using pattern matching and NLP, and blocks the upload before it reaches Google. This works even without an endpoint agent (agentless DLP). (3) **Rights Management Service (RMS) / encryption-at-rest**: apply Azure Information Protection labels or AWS Macie classification to all customer data. If the file leaks, it remains encrypted and unreadable without the user's identity + policy server. Even if exfiltration succeeds, the data is useless. **Encrypted uploads (password-protected ZIP, customer-encrypted files)**: endpoint DLP and CASB cannot inspect encrypted content. Strategy: **contextual blocking** — block all uploads to unsanctioned personal cloud services (Tier 3 apps) regardless of content if they exceed 10 MB or match archive extensions (`.zip`, `.7z`, `.rar`). For sanctioned cloud (OneDrive, SharePoint), allow with full audit logging. UEBA adds another layer: flag the user if they suddenly start uploading 10x their normal volume, even if each upload passes DLP.

Question 13

How do you apply Infrastructure-as-Code principles to SASE policy management, and what is the GitOps workflow?

Accepted Answer

SASE policy as code treats firewall rules, ZTNA policies, DLP rules, and SWG URL filters as version-controlled artifacts. Implementation: (1) **Vendor APIs for export/import**: Zscaler ZIA/ZPA, Palo Alto Prisma Access, Cloudflare, and Netskope all expose REST APIs. Use the API to export existing policies to JSON/YAML and store them in Git. (2) **Terraform providers**: use provider-specific Terraform modules — `zscaler/zpa`, `paloalto/prismacloud`, `cloudflare/cloudflare` — to define SASE resources as Terraform code. Example: `resource "zpa_application_segment" "jenkins" { name = "Jenkins" domain_names = ["jenkins.internal.com"] tcp_port_ranges = ["8443","8443"] }`. (3) **GitOps workflow**: developer/ops engineer opens a PR with policy changes. CI pipeline runs `terraform plan` + policy simulation (what traffic would this affect?) using vendor sandbox APIs. Security team reviews the PR. On merge, CD pipeline (`terraform apply`) deploys to the SASE tenant. Post-apply validation runs synthetic traffic tests to confirm the policy works as intended. **Drift detection**: a nightly cron job runs `terraform plan` against production. If UI changes were made outside Git (break-glass incident response), the plan shows drift and alerts the security team. The drift is either reverted automatically or merged into Git. **Break-glass process**: during incidents, admins can make UI changes directly, but the system auto-reverts them after 24 hours unless explicitly merged to Git via PR. This balances operational agility with policy consistency.

Question 14

What agentless Zero Trust approach segments IoT devices, and how do you handle device impersonation?

Accepted Answer

Agentless Zero Trust for IoT relies on **passive discovery, fingerprinting, and network-level enforcement** rather than endpoint software. Architecture: (1) **Passive device fingerprinting**: tools like Forescout, Armis, Claroty, or Nozomi listen to switch SPAN ports or use ERSPAN to mirror traffic. They identify devices by MAC OUI (e.g., `00:50:56` for GE Healthcare), DHCP hostname (e.g., `MRI-Room-3`), mDNS broadcasts, and protocol behavior (DICOM for imaging, HL7 for EMR, Modbus for building controls). (2) **MUD (Manufacturer Usage Description)**: if devices support RFC 8520, they broadcast a URL to a MUD file describing their intended network behavior. The network automatically generates ACLs: "This infusion pump should only talk to the pump server on TCP 8080." (3) **VLAN + stateless ACL segmentation**: place devices in isolated VLANs with stateless ACLs on industrial switches (e.g., Cisco IE, Hirschmann) allowing only required protocols. No routing to corporate networks. **Device impersonation prevention**: (1) **802.1X with MACsec**: switchports authenticate devices using certificates or MAC Authentication Bypass (MAB) with RADIUS. MACsec (IEEE 802.1AE) encrypts traffic at Layer 2, preventing an attacker from unplugging a legitimate device and impersonating its MAC. (2) **Private VLANs (PVLAN)**: devices in the same VLAN cannot communicate with each other directly — they can only reach the promiscuous port (gateway). This prevents lateral movement even within the same VLAN. (3) **Location-based binding**: if a portable X-ray machine normally connects to Ward-3 switchport Gi1/0/15, an alert fires if it appears on Ward-7. Some NAC solutions enforce this geographically.

Question 15

What five KPIs demonstrate SASE/Zero Trust business value, and how do you benchmark before/after?

Accepted Answer

Five KPIs: (1) **Mean time to contain (MTTC)** a breach: before SASE, red teams move freely from VPN to domain admin in 4+ hours. After SASE, ZTNA micro-segments contain lateral movement; target MTTC <1 hour. Measure via quarterly red team exercises. (2) **Successful lateral movement instances**: count of internal scans, pass-the-hash attempts, or east-west C2 beacons detected. Should drop 90% after micro-segmentation. (3) **Unsanctioned application usage**: % of workforce using approved SaaS vs. shadow IT. CASB discovery quantifies this. Target: >95% of data in sanctioned apps. (4) **VPN helpdesk ticket volume**: password resets, connectivity issues, split-tunnel problems. ZTNA is simpler for users; target 70% reduction in VPN tickets. (5) **Risk-adjusted cost of breach**: use the FAIR (Factor Analysis of Information Risk) model. Before SASE: 20% probability of $10M breach = $2M annual loss exposure. After SASE: 5% probability = $500K exposure. Net risk reduction: $1.5M/year, justifying the $2M subscription when combined with operational savings. **Benchmarking**: run a **breach and attack simulation (BAS)** before SASE deployment using tools like SafeBreach, AttackIQ, or Mandiant Validation. Document which MITRE ATT&CK techniques succeeded (Initial Access, Lateral Movement, Exfiltration). Re-run 90 days post-deployment and compare. The delta is your proof. Present to the CFO as a **quarterly risk dashboard** with trend lines.

SASE & Zero Trust Architecture: 15 Real-World Interview Scenarios

More Network Security Interview Prep