Secure access service edge (SASE)

The request, step by step

1. Reach the nearest healthy edge

   A remote user, a managed device and a branch site each connect to a nearby point of presence instead of backhauling to one data centre. SD-WAN steers branch traffic by application, link health and policy.

   • Request: Remote worker to Managed laptop, “Opens payroll from hotel Wi-Fi”
   • Request: Managed laptop to Edge gateway, “Encrypted tunnel to the nearest edge”
   • Request: Branch site to Edge gateway, “SD-WAN overlay, steered per application”

   Emphasised at this step: Edge gateway.

2. Build the request context

   The service combines the asserted identity with device posture, the requested application, the destination, location and current risk. Identity answers who is asking; the rest answers whether this request, from this device, to this application, should proceed.

   • Context: Remote worker to Identity provider, “Authentication and a second factor”
   • Context: Identity provider to Policy engine, “Identity, group and risk claims”
   • Context: Managed laptop to Policy engine, “Device posture: signatures are stale”
   • Request: Edge gateway to Policy engine, “Request presented for a decision”

   Emphasised at this step: Identity provider.

3. Make one explicit decision

   A single policy engine decides whether to allow, require stronger verification, isolate or block, and which inspection services the traffic must pass through. The verdict is recorded with the signals that produced it.

   • Request: Policy engine to Security service chain, “Verdict and the controls it requires”

   Emphasised at this step: Policy engine.

4. Enforce the verdict

   The selected services carry it out. Here the ZTNA broker exposes the payroll application alone, data loss prevention stops the file download to a device with stale signatures, and the web gateway inspects everything bound for the internet.

   • Request: Security service chain to Payroll application, “Brokered session, no network route”

   Emphasised at this step: Security service chain.

5. Route and observe

   Permitted traffic continues to the internet, a sanctioned SaaS platform or a private application, which then reads its own data. Telemetry from the edge, the policy engine and the service chain reaches security operations, where it becomes evidence and feeds policy tuning.

   • Request: Security service chain to Web destination, “Permitted web traffic”
   • Request: Security service chain to SaaS platform, “Permitted SaaS traffic”
   • Request: Payroll application to Payroll records, “Application reads payroll records”
   • Telemetry: Edge gateway to Security operations, “Session and path metrics”
   • Telemetry: Policy engine to Security operations, “Every decision and the signals behind it”
   • Telemetry: Security service chain to Security operations, “Inspection and data-handling events”

   Emphasised at this step: Security operations.

Attempts shown, and where each one stops

• Adversary on the same network attempts:

  • Attack: Adversary on the same network to Managed laptop, “Credential capture on the shared network”
  • Attack: Adversary on the same network to Edge gateway, “Stolen credentials replayed at the edge”
  • Terminated here by Security service chain — “Refused: unknown device, no posture signal”. The line stops short and takes a bar, not an arrowhead.

• Actions a control refused, with no adversary involved:

  • Blocked: Managed laptop stopped at Security service chain, “Payroll download blocked to a stale device”. The line stops short of its target: the action did not complete.

Annotations

1. Why the edge has to be nearby

   Boundary “Nearest SASE point of presence” (managed)

   Every connection is inspected somewhere. Putting the enforcement point close to the user keeps the added latency small enough that people do not look for ways around it. Proximity is therefore a security property, not only a performance one.

2. What the policy engine evaluates

   Component “Policy engine”

   Identity and group membership, device posture, the requested application, the destination, data sensitivity, location and current risk. One engine reaching one verdict is what makes the decision reviewable; several tools each reaching their own is what SASE is meant to replace.

3. The chain is an outcome, not a fixed pipeline

   Component “Security service chain”

   Which services apply follows from the verdict. A brokered private session, an inspected web request and a SaaS upload subject to data loss prevention traverse different services, even though they enter at the same point of presence.

4. An untrusted network can still hold a managed device

   Boundary “Shared and public networks” (untrusted)

   The zone states the trust posture of the network, not of the device inside it. A managed laptop on hotel Wi-Fi is still managed, and its posture signals still count. Equally, sitting in a managed zone grants a request no privilege on its own.

5. Private applications gain no inbound exposure

   Boundary “Private applications” (internal)

   The broker makes an outbound-initiated connection to the application, so there is no listening service published to the internet for an adversary to scan. Access is to one named application, not to the network it sits on.

6. Telemetry is the evidence trail

   Component “Security operations”

   Network, policy and inspection events are what let an investigator answer why a request was allowed, and what let an architect find the policy that is too broad. If the events are thin or unexportable, the architecture cannot be audited.

7. What the attacker view adds

   Component “Adversary on the same network”

   The attacker view overlays the probes an adversary on the same network can make, and where each one terminates: a replayed credential meets a device-posture requirement it cannot satisfy, and a download from an at-risk device is refused by data loss prevention.