Zero Trust, SASE, and SSE Concepts
Key Takeaways
- Zero trust assumes no implicit trust based on network location; access decisions are explicit, contextual, and continuously evaluated.
- Core zero trust ideas include least privilege, strong identity, device posture, segmentation, continuous monitoring, and policy enforcement.
- SASE combines networking and security functions, commonly including SD-WAN, secure web gateway, CASB, zero trust network access, and firewall capabilities.
- SSE is the security-services subset of SASE and commonly includes SWG, CASB, ZTNA, and data protection controls.
- For exam scenarios, choose ZTNA or identity-aware access when the requirement is app-specific remote access without broad network VPN exposure.
Zero Trust, SASE, and SSE Concepts
Zero trust is an architecture approach, not a single product. It removes implicit trust from network location and makes access decisions based on identity, device, application, data sensitivity, context, and risk.
Zero Trust Principles
| Principle | Meaning | Example |
|---|---|---|
| Verify explicitly | Authenticate and authorize each access request | MFA plus device compliance check |
| Least privilege | Grant only required access | User can reach one app, not a whole subnet |
| Assume breach | Limit blast radius and monitor continuously | Microsegmentation and EDR telemetry |
| Continuous evaluation | Access can change as risk changes | Block session after device becomes noncompliant |
| Strong identity | Users and workloads are known | SSO, federation, service identity, certificate-based auth |
Zero Trust Policy Inputs
A policy decision point may evaluate:
- User identity and group.
- Device health, encryption, EDR, and patch posture.
- Location and impossible travel signals.
- Application being requested.
- Data classification.
- Session risk.
- Authentication strength.
- Time and behavior patterns.
The policy enforcement point then allows, blocks, challenges, limits, or logs the session.
ZTNA vs Traditional VPN
| Feature | Traditional remote access VPN | ZTNA |
|---|---|---|
| Access model | Often network-level access | Application-specific access |
| Trust basis | Authenticated user joins network path | Identity, device, and policy per app |
| Blast radius | Can expose many internal services if poorly scoped | Limits user to approved applications |
| Good fit | Admin networks, legacy protocols, site-to-site needs | Remote workforce access to specific apps |
Exam trap: VPN is not wrong in every scenario. But when a question asks for least-privilege remote access to a specific private application, ZTNA is often the better answer.
SASE and SSE
Secure Access Service Edge, or SASE, combines wide-area networking and cloud-delivered security. Security Service Edge, or SSE, is the security-services portion without the full network transport focus.
| Component | Usually associated with | Purpose |
|---|---|---|
| SD-WAN | SASE | Intelligent traffic routing across WAN links |
| Secure web gateway (SWG) | SASE/SSE | Web filtering, URL filtering, malware controls |
| Cloud access security broker (CASB) | SASE/SSE | Visibility and policy enforcement for cloud apps |
| Zero trust network access (ZTNA) | SASE/SSE | App-specific private access |
| Firewall as a service (FWaaS) | SASE/SSE | Cloud-delivered firewall policy |
| Data loss prevention (DLP) | SASE/SSE | Detect and restrict sensitive data movement |
PBQ-Style Scenario
A company has remote employees, unmanaged SaaS usage, and private internal applications. Users currently connect through a full-tunnel VPN, then browse to SaaS and internal systems. The security team wants app-level access, SaaS visibility, and consistent web filtering.
Reasonable target design:
- Use identity provider federation and MFA for users.
- Use ZTNA for private applications so users receive access only to approved apps.
- Use CASB to discover and control SaaS usage.
- Use SWG for web filtering and malware protection.
- Use device posture checks before allowing sensitive application access.
- Send policy and access logs to centralized monitoring.
Wrong direction: "Put every user on the internal network and trust them after login." That keeps the old perimeter model and does not satisfy least privilege.
Design Review Checklist
- Is access based on identity and context rather than subnet alone?
- Are users limited to required applications?
- Are devices checked before sensitive access?
- Is sensitive data protected in SaaS and web channels?
- Are policy decisions logged?
- Are exceptions documented and time-bound?
Zero trust questions often reward the answer that narrows access while increasing verification and visibility.
A remote employee needs access to one internal HR application but should not receive broad access to the internal network. Which technology best fits?
Which services are commonly part of SSE? Choose three.
Select all that apply
Which statement best describes zero trust?