Cisco Secure Workload

Cisco Umbrella CASB

Network Insight · Engineering Guide

Cisco Umbrella CASB: Cloud Visibility, Data Protection and Zero Trust Investigation

Cloud applications have changed where users work, where data is stored and where security decisions must be made. A modern Cloud Access Security Broker (CASB) approach is therefore not simply about blocking applications. It is about discovering cloud activity, understanding identity and data context, applying proportionate controls, and investigating what actually happened.

Discover

Identify sanctioned and unsanctioned SaaS activity and build visibility into the real cloud environment.

Decide

Combine identity, application, device, data and requested activity before making a policy decision.

Investigate

Correlate cloud, identity, DNS, web and security evidence to distinguish signals from confirmed incidents.

Engineering path Cloud Discovery → Context → Enforcement → Investigation
Network Insight · Interactive Architecture

Cisco Umbrella CASB Architecture Explorer

Explore how cloud application discovery, identity context, data protection and security policy fit together. Select any component to examine its engineering role.

Select an architecture component

Identity & policy Visibility & data Risk & response
01

Cloud Application Visibility: Discovering the Real SaaS Environment

Before a security team can protect cloud applications, it needs to understand what applications are actually being used. SaaS adoption rarely follows the approved application catalogue. Employees may introduce new services, connect third-party applications through OAuth, or move business data between platforms without the security team having complete visibility.

What CASB visibility needs to establish

  • Which cloud applications are being accessed?
  • Which applications are sanctioned and which are unknown?
  • Which users, devices and identities are involved?
  • What type of activity is taking place?
  • What data could be exposed or transferred?
  • How much risk does the application introduce?
Engineering principle Discovery comes before enforcement. A security control cannot reliably protect a cloud environment that it cannot see.

Cloud Application Visibility: Discovering the Real SaaS Environment

Cloud application security starts with visibility. Organisations may have an approved catalogue of SaaS services, but real-world usage is usually much broader. Users can introduce applications, connect third-party services through OAuth, and move business information between cloud platforms without those activities appearing in a traditional application inventory.

What the security team needs to discover

CASB visibility should establish which applications are being used, who is using them, what devices are involved, what activity is taking place and whether sensitive information may be entering or leaving the organisation.

SaaS application
User identity
Device context
Cloud activity
Data movement
Application risk
Why discovery matters

An unknown application is not automatically a security incident. It is a visibility signal that requires context. The security team needs to understand the application, its users, its data and its business purpose before deciding whether enforcement is appropriate.

CASB LAB 01 · CLOUD DISCOVERY

SaaS Discovery Explorer

Explore a simplified cloud environment and determine which applications require attention based on usage, approval status and risk.

Discovered SaaS Environment 6 applications
Microsoft 365 Low
Approved collaboration platform
Salesforce Low
Approved business application
Canva Medium
Unapproved SaaS usage detected
Dropbox Medium
External file-sharing activity
Unknown AI Tool High
Potential sensitive-data destination
GitHub Low
Approved development platform
Application Inspector
Application Microsoft 365
Approval Yes
Observed users 184
Risk Low
Engineering readout: Select an application to inspect its cloud-risk context.
02

Identity, Application and Data Context: Turning Cloud Activity Into Policy

Application identity alone is not enough to make a useful security decision. The same SaaS application may be appropriate for one user, device or dataset and unacceptable for another. CASB policy therefore combines multiple dimensions of context before determining what should happen to a cloud request.

Identity Who is making the request?
Device Is the endpoint trusted and healthy?
Application Is the SaaS service approved and appropriate?
Data What information is being accessed or moved?
Action What is the user attempting to do?
Policy principle

The strongest CASB decisions are contextual decisions: identity + device + application + data + activity. This allows security teams to apply controls proportionately instead of treating every cloud interaction as equally risky.

Identity, Application and Data Context: Turning Cloud Activity Into Policy

Once cloud activity has been discovered, the next challenge is deciding what that activity means. A CASB policy should not simply ask whether a user is accessing a particular SaaS application. It should evaluate the identity, device, application, data and requested action together.

Identity Who is making the request and what privileges do they have?
Device Is the endpoint trusted, managed and in an acceptable state?
Application Is the cloud service approved and appropriate for the organisation?
Data Does the activity involve sensitive or regulated information?
Action Is the user viewing, downloading, uploading or sharing data?
Context changes the decision

The same SaaS application can represent very different levels of risk depending on who is using it, what device they are using and what information they are attempting to move.

From signal to policy

Identity, application risk, data classification and activity context provide the evidence required to move from simple visibility toward a defensible security policy.

Network Insight · Interactive Policy Lab

CASB SaaS Access & Data Protection Engine

Change the identity, application, data sensitivity and requested action. Run the scenario to see how a sample CASB policy evaluates the available context and selects a response.

1. Configure the scenario

Application categories are illustrative policy inputs, not live reputation data.
The path affects which responses this example considers technically available.

2. Policy evaluation

Ready to evaluate

Awaiting scenario

Choose the scenario inputs, then run the policy engine to generate a decision and its explanation.

Decision reasoning
  • The engine evaluates the selected user, application, data and activity.
  • The available enforcement path limits the actions that can be taken.
Recommended next step
Run the scenario to see the recommended response.
Policy logic is deliberately simplified for learning. Real deployments require product-specific capabilities, identity signals, application support, licensing and validated organisational rules.
CASB POLICY LAB

CASB Policy Decision Engine

Evaluate cloud activity using identity, device posture, application risk, data sensitivity and requested action — rather than treating every SaaS request as equal.

Policy Inputs Context → Risk → Decision
Policy evaluation path
Identity → Device → SaaS → Data → Action → Policy
03

CASB Enforcement: DLP, SASE and Remote Browser Isolation

Visibility and policy decisions only become useful when they can drive an appropriate control. Modern cloud security can combine inline inspection, API-based controls, Data Loss Prevention (DLP), SASE enforcement and Remote Browser Isolation (RBI). The engineering challenge is choosing the right control for the evidence and the risk.

I
Inline CASB Inspect activity while the user is actively accessing a cloud service.
A
API CASB Inspect cloud-hosted data and activity through application integrations.
D
DLP Identify sensitive information and control inappropriate data movement.
R
RBI Isolate risky web content so the endpoint has less direct exposure.
Engineering principle: enforcement should be proportional to risk. Blocking, restricting, inspecting or isolating are different control responses and should be selected according to identity, application, data and activity context.

CASB Enforcement: DLP, SASE and Remote Browser Isolation

Visibility and policy decisions become operational security controls when they can trigger an appropriate enforcement mechanism. Modern cloud security architectures can combine inline CASB controls, API-based inspection, Data Loss Prevention and Remote Browser Isolation, often as part of a broader SASE architecture.

IN
Inline CASB

Inspect and control cloud activity while traffic or sessions are actively being used.

API
API CASB

Analyse data and activity already stored within connected SaaS platforms.

DLP
Data Loss Prevention

Identify sensitive information and apply controls to inappropriate data movement.

RBI
Remote Browser Isolation

Separate risky web content from the endpoint to reduce direct exposure.

Engineering principle

Enforcement should be proportional to evidence and risk. A mature cloud security architecture does not automatically block every anomaly; it selects the control that best matches the identity, application, data and activity involved.

Network Insight · Incident Investigation Lab

Shadow IT & Data Exposure Investigator

Act as the security analyst. Review a simulated SaaS security incident, examine the evidence and select a response supported by what the evidence actually establishes.

Investigation briefing A cloud application or SaaS activity has triggered an alert. Determine what is known, what remains uncertain and which containment or remediation action is justified.

1. Select an incident

2. Review the evidence

Incident ID: NI-CASB-104 · Simulated evidence · Times are illustrative

09:14:02
New SaaS destination observed

DNS and web gateway telemetry show connections to a service not present in the approved application catalogue.

Discovery signal
09:14:18
Repeated user activity

Several requests are associated with the same source identity, where identity mapping is available.

Activity pattern
09:16:40
Content exposure not verified

No SaaS audit record or API evidence has yet confirmed that sensitive files were uploaded.

Evidence gap
What is the most defensible initial response?

3. Analyst findings

Investigation not submitted

Select an incident, review its evidence and choose the response that best fits the facts. You will receive feedback explaining the evidence and limitations.

Analyst objective: separate a detection signal from a confirmed policy violation or data exposure.
Investigation checklist
STEP 1
Establish scope

Identify the user, application, activity, relevant time window and available data sources.

STEP 2
Corroborate evidence

Compare network records with SaaS audit events, identity logs and API evidence where available.

STEP 3
Apply proportionate response

Choose a supported control, preserve evidence and verify that remediation worked.

CLOUD PROTECTION CONTROL PLANE

Where Should the Control Live?

CASB is not a single enforcement point. Select a protection mechanism and inspect where it operates across the user request, cloud activity, stored data and endpoint exposure.

Inline CASB

Inline CASB provides visibility and policy enforcement while the user is actively accessing a cloud application.

Primary role
REAL-TIME
Control Placement Map Click a mechanism to compare coverage
User Request
Policy decision during active cloud access.
ACTIVE
Cloud Activity
Visibility into SaaS transactions and user actions.
CONTEXT
Stored Cloud Data
Inspection of data already residing in SaaS platforms.
LIMITED
Endpoint Exposure
Protection of the endpoint from risky web content.
LIMITED
Primary control point Supporting visibility
Engineering Readout Inline CASB is strongest when the organisation needs to evaluate and enforce policy during an active cloud session. It is about controlling the transaction as it happens.
Educational model: these mechanisms can overlap in real architectures. The important engineering question is where visibility is obtained, where policy is evaluated and where enforcement can actually occur.
04

Cloud Security Investigation: From Alert to Defensible Response

A cloud security alert is not automatically a confirmed incident. Effective investigation requires analysts to correlate the original signal with identity, SaaS activity, DNS and web telemetry, endpoint context and application evidence. The objective is to establish what happened, determine the confidence of the finding and select a defensible response.

01 · DETECT
Capture the signal Start with the alert, anomaly or suspicious cloud activity.
02 · CORRELATE
Build context Connect identity, application, DNS, endpoint and data evidence.
03 · VALIDATE
Test the hypothesis Separate supporting evidence from assumptions and missing data.
04 · RESPOND
Choose the action Contain, monitor, remediate or escalate according to confidence.
Shadow IT

An unknown SaaS application becomes more significant when combined with sensitive data movement, unusual identity activity or unexpected OAuth permissions.

Data Exposure

A suspected exposure should be investigated through the actual data classification, recipient, activity and available audit evidence rather than the alert alone.

Cloud Security Investigation: From Alert to Defensible Response

Security analytics becomes valuable when individual alerts can be connected to a broader evidence chain. A suspicious SaaS application, unusual OAuth permission or possible data exposure should therefore be investigated across identity, application, DNS, web, endpoint and audit evidence before an operational decision is made.

01 · DETECT
Capture the signal

Start with the alert, anomaly or suspicious cloud activity that triggered the investigation.

02 · CORRELATE
Build the evidence chain

Connect identity, SaaS, DNS, endpoint, data and audit information.

03 · VALIDATE
Test the finding

Determine what the evidence proves, what it suggests and what remains unknown.

04 · RESPOND
Choose the action

Contain, monitor, remediate or escalate according to confidence and business impact.

Shadow IT investigation

An unknown SaaS application becomes more significant when combined with unusual authentication, sensitive data movement, risky OAuth permissions or other supporting evidence.

Defensible response

The objective is not simply to react to an alert. It is to establish a sufficiently supported finding and select a response that matches the available evidence.

SECURITY INVESTIGATION LAB

Shadow IT Investigation Lab

Move from an alert to a defensible conclusion. Select an incident, collect the available evidence, correlate the signals and decide whether the activity represents a genuine security concern.

Unapproved SaaS Application

A previously unknown cloud application has appeared in enterprise traffic. Determine whether this is simply unsanctioned software or a genuine security concern.

NOT INVESTIGATED
Evidence Inspector 0 / 4 collected
Identity Telemetry Pending
Who performed the activity?
Awaiting collection
SaaS Activity Pending
What application activity occurred?
Awaiting collection
Data Evidence Pending
What information was involved?
Awaiting collection
Network / DNS Pending
What infrastructure or destination was involved?
Awaiting collection
Investigation readout
Begin by selecting an incident and collecting evidence. An alert alone is not enough to establish a security event.
Confidence
0%
Analyst finding No finding submitted. Collect evidence before deciding whether the alert represents a confirmed security concern.
Educational simulation: the evidence model is intentionally simplified. In a production investigation, analysts would combine identity, application, DNS/web, endpoint, DLP and SaaS audit evidence with organisational policy and incident-response procedures.
tion
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
DNS Security

DNS Security Solutions

Network Insight · Engineering Guide

DNS Security: Protecting the First Connection

DNS is one of the foundational services behind almost every digital application. Before a browser connects to a website, a device reaches a cloud service, or an application establishes a session, DNS is often involved in identifying the destination. That makes DNS more than a directory of names and IP addresses — it is an important security and visibility control point.

A modern DNS security architecture therefore needs to address several different problems at the same time: where DNS traffic is allowed to go, whether DNS data can be trusted, whether destinations are considered safe, and whether unusual DNS behaviour can be detected.

Engineering Question

How can an organisation use DNS to protect the earliest stage of a connection without confusing DNS encryption, DNS filtering and DNSSEC as if they solved the same security problem?

01 · REQUEST
Client Query
A user, device or application requests a hostname.
02 · RESOLVE
Recursive Resolver
The resolver retrieves or returns the requested DNS data.
03 · INSPECT
Security Policy
Reputation, filtering and policy controls evaluate the request.
04 · VALIDATE
DNSSEC
Signed DNS data can be cryptographically validated.
05 · OBSERVE
Telemetry
DNS activity becomes evidence for detection and investigation.

01 · The Security Context DNS Is More Than Name Resolution

Traditional DNS provides a distributed mechanism for translating human-readable hostnames into addresses. Its hierarchical design, delegation model and caching make Internet-scale name resolution practical. But the original protocol was not designed around the security expectations of today's Internet.

Modern environments contain unknown Internet participants, cloud applications, remote users, unmanaged devices and constantly changing infrastructure. As a result, DNS has become both a critical dependency and an attractive attack surface.

Resolution

Find the Destination

Recursive resolution, caching and delegation allow clients to discover the DNS information required to reach an application or service.

Security

Evaluate the Destination

Filtering and threat intelligence can determine whether a requested domain should be allowed, blocked or redirected for further inspection.

Visibility

Understand the Behaviour

DNS telemetry provides evidence about which domains devices are requesting, how frequently they are queried and whether unusual patterns are emerging.

02 · Three Different Problems Privacy, Integrity and Trust

One of the most important engineering distinctions in DNS security is that different technologies protect different properties. Encrypting a DNS query does not prove that the destination is safe. Filtering a domain does not authenticate the DNS response. DNSSEC validation does not provide complete visibility into endpoint behaviour.

Privacy

DoH and DoT can protect DNS traffic between a client and its selected resolver from passive observation on the transport path.

Integrity

DNSSEC provides cryptographic validation of signed DNS data and helps detect manipulation of responses when the relevant chain of trust is available.

Policy

DNS filtering evaluates requested destinations against security policy, reputation and threat intelligence to determine whether resolution should proceed.

01

DNS Filtering

Filtering can block known malicious, phishing, command-and-control or otherwise prohibited domains before a connection is established. It is a policy decision, not a cryptographic proof of authenticity.

02

DNSSEC

DNSSEC uses digitally signed DNS data and a hierarchical chain of trust to validate responses. It addresses authenticity and integrity rather than domain reputation.

03

DoH / DoT

DNS over HTTPS and DNS over TLS encrypt the client-to-resolver connection. Encryption protects the channel but does not determine whether the requested domain is malicious.

04

DNS Telemetry

Resolver and security logs expose DNS behaviour that can be correlated with endpoint, identity, network and application evidence during investigation.

Engineering Model

Where DNS Security Controls Operate

A modern deployment can combine several controls. The exact inspection order and component placement depend on the enterprise, cloud or managed DNS architecture.
Client Generates DNS requests before establishing application sessions.
Resolver Provides recursive resolution, caching and a central policy point.
Filtering Evaluates domain reputation and security policy.
DNSSEC Validates signed data and the DNS chain of trust.
Telemetry Records queries, decisions, anomalies and validation events.

03 · Why DNS Becomes an Attack Surface Security Starts Before the Application Session

Because DNS commonly occurs before an application connection is established, attackers can abuse the protocol at an early stage of the attack chain. DNS can be manipulated to redirect users, used to communicate with command-and-control infrastructure, abused for data exfiltration, or overwhelmed to disrupt service availability.

Examples include cache poisoning, DNS spoofing or hijacking, DNS tunnelling, amplification attacks, DNS floods and random-subdomain or NXDOMAIN attacks. Each produces different evidence and requires a different combination of controls.

Manipulation

Poisoning & Spoofing

Incorrect DNS information can redirect clients towards unintended destinations or cause a resolver to return manipulated data.

Covert Channel

DNS Tunnelling

Encoded information can be carried inside DNS queries and responses, creating a potential channel for command-and-control or data exfiltration.

Availability

Flood & Amplification

DNS infrastructure can be targeted directly or abused as part of reflected and amplified denial-of-service activity.

04 · Architectural Response Build DNS Security as a Control Stack

A resilient DNS security design should therefore avoid treating any individual feature as the complete solution. Filtering, DNSSEC, encrypted DNS transport, resilient resolver infrastructure, logging and threat intelligence address different parts of the problem.

The result is a layered security model in which DNS provides both an enforcement point and an early source of security telemetry. Suspicious DNS behaviour can be blocked, investigated or correlated with other evidence before the associated application session becomes the primary security signal.

Network Insight · Engineering Takeaway

DNS should be treated as part of the security architecture rather than as a background network service. The strongest design combines secure transport, DNS filtering, DNSSEC validation, resilient infrastructure and continuous telemetry. The key engineering principle is simple: each control solves a different problem, and effective DNS security comes from combining those controls with broader endpoint, identity, network and application evidence.

Network Insight · Engineering Guide

DNS Security — Engineering Guide

Follow the guide from normal DNS resolution through attack surface, security controls and operational investigation. Select a section to jump directly to its interactive engineering map.

DNS as a Security Control Plane: Architecture, Telemetry and Investigation

Engineering Map · Section 01
DNS resolution path

Follow a DNS request before looking at the security problem

DNS security makes more sense when the normal resolution process is understood first. Select a stage below to see what happens at that point in the request path.

01

Client

A user, device or workload requests a name.

→
02

Resolver

The recursive resolver processes the query.

→
03

Security Policy

Filtering and intelligence can inspect the request.

→
04

Authoritative DNS

Authoritative infrastructure supplies DNS data.

Client: The process begins when an endpoint, application or workload needs to resolve a domain name.
Section 01 · DNS Architecture

DNS as a Security Control Plane

DNS is traditionally viewed as a resolution service: a client asks for a hostname and a resolver returns the information required to reach the destination. In a modern security architecture, however, the resolver can become much more than a lookup mechanism.

Because DNS activity normally occurs before an application connection is established, it provides an early opportunity to apply policy, evaluate destination risk and collect security telemetry.

01 · The Architectural Shift From Resolver to Security Control Point

A traditional DNS deployment focuses primarily on availability and resolution. The resolver answers queries, follows delegation, caches records and returns the information requested by clients.

A security-aware resolver adds another layer of responsibility. It can become the point where DNS requests are evaluated against threat intelligence, reputation data, organisational policy and identity context before the connection continues.

Engineering Principle

DNS does not need to replace the firewall, endpoint security or application security. Its value comes from providing an early control point that can make a security decision before the requested application session begins.

02 · DNS Architecture Three Operational Planes

It is useful to think about modern DNS security in terms of three operational planes. The terminology differs between products and architectures, but the engineering responsibilities remain broadly similar.

01 · RESOLUTION

Recursive Resolution

The resolver performs recursive lookups, follows DNS delegation, caches responses according to TTL values and returns DNS information to the requesting client.

02 · SECURITY

Policy & Enforcement

DNS requests can be evaluated against domain reputation, threat intelligence, filtering rules, identity context and organisational policy. A request may be allowed, blocked or redirected for additional inspection.

03 · VISIBILITY

Telemetry & Detection

DNS queries, responses, policy decisions and anomalies can become security telemetry. This information can then be correlated with endpoint, identity, network and application evidence.

03 · Resolution Path Where Security Decisions Can Be Applied

The DNS resolution path provides several opportunities for inspection. The precise architecture varies between enterprise, cloud and managed DNS environments, but the basic security model can be represented as a sequence of resolution, evaluation, validation and observation.

Conceptual DNS security processing path
Client Query User, endpoint or application requests a hostname.
Recursive Resolver Resolver checks cache or performs recursive resolution.
Security Policy Reputation and filtering rules evaluate the requested domain.
DNSSEC Validation Signed DNS data can be validated where DNSSEC is deployed.
Telemetry Query, decision and validation data becomes security evidence.

04 · Security Stack Different Controls Solve Different Problems

A common architectural mistake is to treat DNS encryption, DNS filtering and DNSSEC as interchangeable security controls. They are not. Each protects a different property of the DNS process.

ENC

DoH / DoT

Encrypts the DNS connection between a client and its selected resolver. This helps protect the query from passive observation on the transport path, but does not establish that the destination is safe.

FIL

DNS Filtering

Uses policy, reputation and threat intelligence to determine whether a requested domain should be resolved. Filtering is primarily an access-control and threat-prevention mechanism.

SEC

DNSSEC

Uses cryptographic signatures and a chain of trust to validate DNS data. It addresses integrity and authenticity rather than domain reputation.

LOG

DNS Telemetry

Captures query behaviour, responses, policy decisions and anomalies. Telemetry provides the evidence needed for detection, investigation and threat hunting.

05 · Operational Security DNS Becomes a Security Sensor

The value of DNS telemetry comes from the patterns that appear across many requests rather than from a single DNS event. A single unusual domain does not necessarily indicate compromise. A sequence of rare domains, unusual query lengths, abnormal NXDOMAIN activity or repeated connections to suspicious infrastructure can provide a much stronger signal.

DNS Investigation Model

Turn DNS Activity into Evidence

Query Pattern Examine frequency, timing, length and naming behaviour.
Domain Risk Compare requested destinations with reputation and threat intelligence.
Endpoint Context Identify the device, user and process generating the DNS activity.
Network Evidence Correlate DNS activity with subsequent connections and network flows.

06 · Engineering Checklist Designing DNS as a Security Control Plane

✓
Centralise DNS policy where practical so security decisions can be applied consistently.
✓
Protect resolver infrastructure against unauthorised administrative access and service disruption.
✓
Use DNS filtering to block known malicious or prohibited destinations.
✓
Use DNSSEC validation where the relevant zones and architecture support it.
✓
Consider DoH or DoT where encrypted client-to-resolver transport is required.
✓
Export DNS telemetry so suspicious behaviour can be correlated with wider security evidence.
Section 01 · Engineering Takeaway

DNS becomes significantly more valuable when it is treated as a security control plane and telemetry source rather than simply a resolution service. The resolver can provide the point where requests are evaluated, DNSSEC can validate signed data, encrypted DNS can protect the transport and telemetry can expose suspicious behaviour. The important engineering principle is that these controls are complementary — no single DNS technology solves the entire security problem.

DNS Resolution Lab / Architecture Simulator

Follow One DNS Query Through the Network.

Step through a normal DNS request and see where recursive resolution, security policy and authoritative DNS each participate in the process.
Ready
DNS Resolution Path
0 / 7
◉
CLIENT
10.10.10.20
Application
◈
RECURSIVE
RESOLVER
10.10.10.53
Resolver
◆
SECURITY
POLICY
Reputation
Filtering
▣
AUTHORITATIVE
DNS
example.net
DNS Zone
Current DNS Transaction
WAITING
QUERY www.example.net TYPE=A
Engineering principle: DNS security becomes easier to understand when the normal resolution path is separated into distinct decision points.
Resolution Roles
Live
Client Requests name
Resolver Finds answer
Policy Evaluates request
Authoritative Owns zone data
Query Evidence
Observed
Domain
www.example.net
Record Type
A
Security Decision
Not evaluated
Resolution Timeline
Request lifecycle
01
CLIENT
Application requests the IP address for www.example.net.
02
RESOLVER
Recursive resolver receives the DNS query.
03
POLICY
DNS security policy evaluates the requested domain.
04
RESOLVER
Resolver determines where authoritative information must be obtained.
05
AUTHORITATIVE
Authoritative DNS returns the requested record information.
06
VALIDATE
Resolver evaluates the response before returning it to the client.
07
CLIENT
Client receives the DNS response and can initiate the next connection.
Lab Telemetry
Live interpretation
Current Event
Press Step Forward to begin
Simulation Progress
Engineering takeaway: DNS is a control path between an application request and the destination information required to reach a service.

DNS Threats: Where Resolution Becomes an Attack Surface

Threat Explorer · Section 02

Where can the DNS process be attacked?

DNS attacks do not all target the same property. Select an attack class to see the primary security concern behind it.

Cache Poisoning Corrupting the resolver's answer.
DNS Tunnelling Using DNS as a covert data path.
Amplification Abusing DNS to increase attack traffic.
NXDOMAIN Flood Generating large volumes of failed queries.
Integrity
Cache poisoning attacks the trustworthiness of DNS responses.

The security objective is to ensure that clients receive the correct DNS information rather than an attacker-controlled destination.

Network Insight · Engineering Guide · Section 02

DNS Threats: Where the Resolution Process Becomes an Attack Surface

DNS was designed to provide scalable name resolution rather than to act as a security system. That distinction matters. The same distributed architecture that makes DNS efficient and resilient can also provide attackers with opportunities to manipulate responses, hide activity, exhaust resources or use DNS as a communications channel.

Modern DNS security therefore begins with understanding how the attack changes the normal resolution process. Some attacks target the integrity of DNS data. Others target availability. Others abuse DNS itself as a transport mechanism for command-and-control or data exfiltration.

Engineering Question
When suspicious DNS activity is detected, what exactly is being attacked — the DNS data, the DNS infrastructure, the availability of the service, or the DNS protocol itself?

The Major DNS Attack Classes

The most useful way to understand DNS threats is to separate them by the security property they attempt to undermine. This makes it easier to select an appropriate control rather than treating every DNS security problem as a generic filtering problem.

01

DNS Cache Poisoning

An attacker attempts to introduce incorrect DNS information into a resolver's cache so that subsequent clients receive an unintended destination address.

02

DNS Spoofing & Hijacking

DNS responses or resolution behaviour are manipulated so that users are directed somewhere other than the intended destination. The attack can occur at different points in the resolution path.

03

DNS Amplification

Attackers abuse exposed or poorly configured DNS infrastructure to generate responses toward a victim, using asymmetric request and response sizes to amplify traffic.

04

DNS Flooding

DNS servers or their supporting network infrastructure are overwhelmed with large volumes of requests, reducing the ability of legitimate clients to obtain resolution.

05

Random Subdomain / NXDOMAIN Attacks

Large numbers of unique, nonexistent names can generate repeated NXDOMAIN processing and reduce resolver or authoritative-server efficiency.

06

DNS Tunnelling

DNS queries and responses can be abused to carry encoded information, enabling covert command-and-control or data-exfiltration channels that may blend into normal DNS traffic.

Attack Path: From DNS Request to Security Impact

A DNS attack does not necessarily begin with a malicious-looking packet. In many cases the initial request can appear syntactically normal. The security problem emerges from the destination, frequency, response behaviour, context or relationship between multiple DNS events.

Conceptual DNS attack path
01 · Request Client generates DNS query
→
02 · Resolution Resolver processes request
→
03 · Manipulation Data, traffic or behaviour is abused
→
04 · Outcome Redirect, disruption or covert communication

DNS Cache Poisoning

DNS cache poisoning attempts to place false information into a recursive resolver's cache. Once the incorrect record is cached, clients using that resolver may receive the malicious destination until the cached information expires or is replaced.

The fundamental security problem is therefore data integrity. A resolver may successfully complete the DNS transaction from a protocol perspective while still returning an incorrect answer. This is why DNSSEC provides a fundamentally different security function from DNS filtering.

Investigation Evidence
What might indicate manipulated DNS data?
Integrity Signal
Unexpected destination A familiar hostname resolves to an unexpected or previously unseen address.
Validation failure DNSSEC validation fails where a signed zone and validating resolver are expected.
Resolver anomaly Cache behaviour or response patterns differ significantly from the expected resolution path.

DNS Spoofing and Hijacking

DNS spoofing describes situations where false DNS information is presented to a client or resolver. DNS hijacking can occur when an attacker or intermediary gains the ability to alter DNS settings, responses or resolution behaviour.

The important engineering distinction is that the user may still perform a perfectly normal DNS lookup from the endpoint's perspective. The problem is that the lookup has been influenced by another party. This can redirect users toward phishing infrastructure, malicious services or unwanted destinations.

DNS Amplification and Flood Attacks

Availability attacks target a different property. Rather than attempting to make DNS return the wrong answer, the attacker attempts to prevent legitimate users from obtaining answers at all.

DNS Amplification

  • Uses DNS infrastructure as a traffic reflector.
  • Often relies on spoofed source addresses.
  • Attempts to generate a larger response toward the victim.
  • Can contribute to large distributed denial-of-service attacks.

DNS Flooding

  • Directly overwhelms DNS infrastructure with requests.
  • Consumes processing, bandwidth or connection capacity.
  • Can affect legitimate DNS resolution.
  • Requires resilience, capacity and traffic protection.

Random Subdomain and NXDOMAIN Attacks

A random-subdomain attack generates large numbers of queries for names that do not exist. The resulting NXDOMAIN responses create additional processing requirements for recursive and authoritative infrastructure.

This demonstrates why DNS security cannot focus exclusively on malicious domains. A domain can be legitimate while the behaviour associated with the query is abnormal. Query volume, uniqueness, timing, source identity and response patterns can therefore become important detection signals.

DNS Tunnelling

DNS tunnelling represents a different type of abuse. Instead of attacking DNS resolution directly, the attacker uses DNS as a communication mechanism. Data can be encoded into DNS queries and responses, allowing information to move through infrastructure that permits DNS traffic.

This can support command-and-control communication or data exfiltration. Because DNS is ubiquitous and required by many environments, simply allowing DNS traffic does not mean that all DNS activity should be considered trusted.

DNS Telemetry
Signals that can make tunnelling suspicious
Behavioural Analysis
Unusually long labels Repeated queries contain unusually large or encoded-looking subdomain labels.
High query frequency A single endpoint generates DNS requests at a rate inconsistent with its normal behaviour.
Rare destinations Queries repeatedly target unusual or previously unseen domains and subdomains.
Security Principle
Integrity Determine whether DNS data has been modified or manipulated.
Availability Ensure users can continue to resolve names during failures or attacks.
Visibility Use DNS telemetry to identify abnormal destinations and behaviours.

Why DNS Creates a Security Blind Spot

DNS is frequently treated as background infrastructure. Applications depend on it, firewalls allow it, and users rarely interact with it directly. This can make DNS activity difficult to notice until something goes wrong.

The security challenge is therefore not simply that DNS has vulnerabilities. It is that DNS activity can provide attackers with a highly available channel that may not receive the same depth of inspection as web, application or endpoint traffic.

This is particularly important for DNS tunnelling and command-and-control activity. A security architecture that only evaluates the final application connection may miss useful evidence contained in the DNS activity that occurred before that connection was established.

Section 02 · Engineering Takeaway

DNS attacks fall into several distinct classes: integrity attacks can manipulate resolution data, availability attacks can disrupt resolution, and protocol abuse can turn DNS into a covert communications channel. Effective DNS security therefore requires more than domain blocking. It combines validation, filtering, resilience and behavioural visibility so that the security team can understand both what DNS returned and how DNS was being used.

DNS Threat Investigation / Attack Simulator

Inject a DNS Attack. Follow the Evidence.

Select an attack class and watch how the DNS resolution path changes. Use the evidence panel to identify the primary security property under pressure.
Normal
Select Attack Scenario
Four common DNS attack classes
◉
CLIENT
10.20.10.20
Workstation
◈
RECURSIVE
RESOLVER
10.20.10.53
DNS Service
▣
AUTHORITATIVE
DNS
Internet
Zone Data
Query Pattern
Normal
Resolver Behaviour
Stable
Security Property
Normal resolution
Engineering principle: DNS attacks target different properties of the resolution process. Identify what is being affected before selecting the security control.
Attack Assessment
Live analysis
Attack class Cache Poisoning
Primary risk Integrity
Attack location Resolver
Detection source DNS telemetry
Risk Level
HIGH
Evidence
Investigation data
Domain / Query
www.example.net
Response
203.0.113.20
Observed Signal
Unexpected DNS answer
Attack Timeline
Investigation sequence
01
QUERY
Client generates a DNS request.
02
SIGNAL
Abnormal DNS behaviour becomes visible.
03
ANALYSE
Resolver and response behaviour are compared with expected patterns.
04
EVIDENCE
DNS telemetry provides evidence of the selected attack pattern.
05
CONTROL
The appropriate DNS security control can now be selected.
Investigation Readout
Live interpretation
Current Finding
Select an attack and run the investigation.
Investigation Progress
Analyst principle: an unusual DNS event is a signal requiring investigation, not automatically proof of compromise.

DNS Security Controls: Filtering, Validation, Encryption and Visibility

Control Selector · Section 03

Four controls — four different security problems

DNS filtering, DNSSEC, encrypted DNS and telemetry are often discussed together. Select each control to see the specific security property it addresses.

DNS Filtering
DNSSEC
DoH / DoT
DNS Telemetry
Primary function

DNS Filtering

Evaluates requested domains against policy and threat intelligence so known malicious or prohibited destinations can be blocked before the connection proceeds.

Protects the security decision
Network Insight · Engineering Guide · Section 03

DNS Security Controls: Filtering, Validation, Encryption and Visibility

DNS security is not a single feature that can simply be switched on. Effective protection comes from combining controls that address different properties of the DNS transaction: what is being requested, who is requesting it, whether the response is authentic, how the query is transported, and what the activity reveals about the wider attack.

Engineering question

If DNS filtering blocks a malicious domain, DNSSEC validates the response, and DoH encrypts the query path, are those controls solving the same problem? No. Each protects a different part of the DNS security model.

01

Protect the decision

DNS filtering and threat intelligence determine whether a requested domain should be allowed, blocked, redirected or investigated.

02

Protect the channel

DNS over TLS and DNS over HTTPS encrypt DNS communication between a client and its resolver, reducing exposure to interception and manipulation in transit.

03

Protect integrity

DNSSEC provides cryptographic validation so a resolver can determine whether signed DNS data is authentic and has not been altered.

04

Protect visibility

DNS logging, telemetry and behavioural analysis turn resolution activity into security evidence that can be correlated with users, devices and threats.

Secure DNS resolution path
Client / Identity User, device, workload and originating context
→
Encrypted DNS DoH / DoT protects the resolver communication channel
→
Policy + Validation Filtering, threat intelligence and DNSSEC checks
→
Telemetry Logging, analytics and security investigation evidence
F

DNS Filtering & Threat Intelligence

Filtering evaluates the requested domain against security policy, reputation data and threat intelligence. A request associated with malware, phishing, command-and-control infrastructure or another prohibited category can be blocked before the connection proceeds.

Important: Filtering makes a security decision about the destination. It does not prove that the DNS response itself is authentic.
S

DNSSEC Validation

DNSSEC adds cryptographic signatures to DNS data and allows validating resolvers to establish the authenticity and integrity of signed responses. It addresses a fundamentally different problem from domain reputation.

Important: DNSSEC can validate DNS data without determining whether the destination itself is trustworthy.
E

DNS over HTTPS / TLS

DoH and DoT encrypt the communication between the DNS client and resolver. This reduces the ability of intermediate networks to inspect or manipulate DNS requests in clear text.

Important: Encryption protects the transport path. It does not automatically make a requested domain safe.
V

DNS Logging & Analytics

DNS telemetry provides a security view of the destinations being requested across users, endpoints and workloads. Patterns such as repeated failures, unusual query volumes or suspicious domain relationships can become early indicators of compromise.

Important: Visibility is not prevention by itself, but it can significantly improve detection and investigation.
Control
Primary property
Security role
DNS Filtering
Policy
Decides whether a DNS request should be permitted based on security policy and intelligence.
Threat Intelligence
Reputation
Provides context about domains, infrastructure and known malicious activity.
DNSSEC
Integrity
Validates signed DNS data and helps detect tampering with authenticated DNS information.
DoH / DoT
Confidentiality
Encrypts DNS communication between the client and resolver.
DNS Telemetry
Visibility
Exposes behavioural patterns that can support detection, investigation and response.

DNS policy can become identity-aware

Traditional DNS policy often starts with an IP address or network segment. Modern security architectures can associate DNS activity with the identity and context behind the request. This allows policy to consider the user, device, workload, location or security posture rather than treating every query from a network as equivalent.

User or workload identity
Device or endpoint context
Security policy and destination category
Threat intelligence and reputation
Historical DNS behaviour and anomaly signals

DNS becomes particularly useful in Zero Trust and SASE architectures because name-resolution activity occurs before many application connections are established. A DNS security service can therefore provide an early policy and visibility point across users, endpoints, branches and cloud workloads.

Identity-aware policy Apply different DNS controls according to user, device or workload context.
Secure resolution Use protected resolver communication and validate DNS responses where applicable.
Threat prevention Block known malicious destinations before the application connection is established.
Continuous visibility Capture DNS activity as telemetry for detection, investigation and correlation.
C

Cloud-delivered DNS security

DNS requests are sent to a security service that combines policy enforcement, threat intelligence, filtering and telemetry. This model can provide consistent controls across distributed users and locations.

O

On-premises DNS security

Resolver infrastructure and security controls remain within the organisation. This can provide direct operational control and integration with existing internal DNS architecture.

H

Hybrid DNS security

Internal and external resolution paths are combined so that private zones, enterprise policy, cloud workloads and Internet-facing DNS can be protected according to their different requirements.

A

Architecture-aware controls

Enterprise platforms can combine DNS security with broader secure-access, cloud, identity and monitoring capabilities, making DNS one component of a larger security architecture.

Section 03 takeaway

DNS security works best as a layered control system. Filtering decides what should be allowed, threat intelligence supplies context, DNSSEC protects the integrity of signed DNS data, DoH and DoT protect the resolver communication channel, and DNS telemetry provides the visibility required to detect and investigate abnormal behaviour. No single control replaces the others.

Network Insight · DNS Security Control Lab

One DNS Query. Four Security Controls.

Enable or disable the major DNS security controls and watch the same query move through filtering, encrypted transport, DNSSEC validation and telemetry.
Ready
Secure DNS Resolution Path
Idle
◉
CLIENT
User / workload
10.10.10.24
◇
ENCRYPTED DNS
DoH / DoT
Protected channel
◆
SECURITY CONTROL
Filtering
Threat intelligence
▣
AUTHORITATIVE
DNS answer
DNSSEC data
Current Query
www.example.com A
Security Controls
Click to toggle
DNS Filtering
Blocks known malicious destinations.
DNSSEC Validation
Validates DNS response integrity.
DoH / DoT
Protects the DNS transport channel.
DNS Telemetry
Records queries and security evidence.
Security Decision
Live
Current Result
Press Run DNS Query
Filtering Enabled
DNSSEC Valid
Transport Encrypted
Telemetry Logging
DNS Security Event Log
Live evidence
--:--
SYSTEM
Waiting for DNS query execution.
Engineering Interpretation
Control plane
Current Security Property
DNS security controls protect different properties of the resolution process. No single control provides the complete security model.
ON
Decision
ON
Integrity
ON
Channel
ON
Visibility

DNS as a Security Control Plane: Architecture, Telemetry and Investigation

Investigation Workflow · Section 04

Turn a DNS event into an engineering investigation

Security Operations

A suspicious DNS query is a signal, not automatically a verdict. Follow the investigation path and combine DNS evidence with identity, endpoint and network context.

01
Identify Who generated it?
02
Inspect Where is it going?
03
Correlate What pattern exists?
04
Validate What evidence exists?
05
Respond What should happen?
Identify
Start with the source

Determine which user, endpoint, server, application or workload generated the DNS request before deciding whether the activity is suspicious.

Network Insight · Engineering Guide · Section 04

DNS as a Security Control Plane: Architecture, Telemetry and Investigation

The value of DNS security extends beyond blocking malicious domains. When DNS requests are consistently controlled, logged and analysed, the resolver becomes a strategic observation point across the network. It can connect identity, destination, policy, threat intelligence and behavioural telemetry before an application session is fully established.

Engineering principle

Treat DNS as part of the security architecture rather than as an isolated naming service. The objective is not simply to make DNS harder to attack; it is to make DNS useful for prevention, validation, detection and investigation.

Reference security architecture
DNS security control plane

Users · Devices · Workloads

DNS requests originate from endpoints, servers, applications, branches and cloud workloads.

→

Secure DNS Control

Encrypted transport, policy enforcement, threat intelligence, filtering and DNSSEC validation.

→

Authoritative DNS / Internet

Resolution continues toward authoritative infrastructure and the requested destination.

Query logs
Threat signals
Identity context
Security analytics
The operational model
01

Observe

Capture DNS requests, responses, identities, destinations, response codes and behavioural patterns.

02

Decide

Apply security policy and intelligence to determine whether a request should proceed, be blocked or be investigated.

03

Validate

Validate response integrity where DNSSEC is available and identify inconsistencies or unexpected resolution behaviour.

04

Investigate

Use DNS telemetry as evidence when searching for malware, tunnelling, command-and-control activity or compromised systems.

What DNS telemetry can reveal

Normal resolution behaviour

Expected query volume for a known endpoint or workload.
Repeated access to established internal and external services.
Predictable response codes and record types.
DNS activity consistent with the application's expected behaviour.

Potential anomaly signals

Large increases in NXDOMAIN responses or random-looking subdomains.
Unusually high query frequency from a single endpoint.
Repeated requests to newly observed or suspicious domains.
Patterns consistent with DNS tunnelling or command-and-control communication.
DNS investigation workflow

From query to security decision

A DNS event should not automatically be treated as an attack. The investigation process should combine DNS evidence with identity, endpoint, application and network context. This avoids turning a single unusual query into a false positive while still allowing patterns to surface early.

01
Identify the source. Which user, device, workload or application generated the request?
02
Inspect the destination. What domain was requested and what is known about it?
03
Assess the pattern. Is the activity isolated or part of a larger behavioural anomaly?
04
Correlate the evidence. Compare DNS activity with endpoint, identity and network telemetry.
05
Apply the response. Block, investigate, contain or allow according to the evidence and policy.
DNS analytics and automated detection

A DNS query becomes a security signal

DNS security platforms and custom analytics can evaluate multiple attributes rather than relying on a single rule. This makes it possible to detect behaviour that may not match a known malicious domain.

Query frequency Detect unusually high request rates from an endpoint or workload.
Domain reputation Compare destinations against known threat and reputation data.
Response behaviour Inspect response codes, record types and unusual resolution patterns.
Behavioural anomaly Identify patterns that differ significantly from an established baseline.
Implementation considerations
Centralise policy where practical Use a consistent security policy model across users, branches, endpoints and cloud environments where the architecture allows it.
Protect resolver access Control which resolvers clients can use and consider encrypted DNS transport where appropriate to the environment.
Enable meaningful logging Capture enough DNS context to associate queries with identities, systems and security events without generating unusable telemetry.
Monitor failure patterns NXDOMAIN spikes, unusual query rates, suspicious destinations and unexpected response behaviour can all provide useful signals.
Integrate with security operations DNS events become more valuable when correlated with endpoint, identity, firewall, proxy and application telemetry.
Test the control path Verify that policy enforcement, DNSSEC validation, encrypted resolution and logging operate as intended during both normal and abnormal conditions.
Section 04 takeaway

The strategic value of DNS security is visibility combined with control. A secure DNS architecture can prevent access to known malicious destinations, protect DNS communication, validate signed responses and expose behavioural anomalies. When that telemetry is correlated with identity and endpoint evidence, DNS becomes an early security control plane rather than simply a background network service.

Network Insight · DNS Security Investigation Lab

Investigate DNS as a Security Control Plane

A suspicious DNS event is a signal, not automatically a verdict. Follow the evidence from source identification through correlation, validation and response.
Investigation Ready
DNS Investigation Workflow
Step 1 / 5
01
Identify
Locate the source of the DNS activity.
02
Inspect
Examine the queried destination.
03
Correlate
Compare DNS with other evidence.
04
Validate
Establish an evidence chain.
05
Respond
Select the appropriate action.
Source
10.10.20.44
Query Rate
184/min
NXDOMAIN
82%
Reputation
Unknown
Current Observation
Evidence
Query Frequency
ANOMALY
DNS activity from this source is significantly above its normal baseline.
Domain Pattern
SUSPICIOUS
Requests contain frequently changing labels and a high proportion of failed resolutions.
Identity
KNOWN
Source maps to workstation ENG-WS-044 assigned to a known engineering identity.
Analyst Finding
Step detail
Identify
Identify the DNS source
Start with the device or workload generating the DNS activity. A DNS event becomes useful when it can be tied to a specific source and identity.
Security Operations Event Console
DNS telemetry
--:--
SYSTEM
Investigation ready. Begin by identifying the DNS source.
Response Decision
Analyst action
Current Risk
MEDIUM
Continue collecting evidence before applying a disruptive response.
25%
Confidence
1/5
Evidence
01
Stage
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
zero trust network design

Zero Trust SASE

Zero Trust SASE

The traditional network perimeter has become increasingly difficult to define. Users work from offices, homes, mobile devices, and third-party locations, while applications and data are distributed across private data centres, SaaS platforms, and public clouds. In this environment, security cannot depend solely on whether a connection originates from a trusted corporate network. Organizations need a way to evaluate access continuously while delivering security and connectivity closer to users and applications.

Zero Trust provides the security model for this approach. Its core principle is that access should not be automatically trusted simply because a user or device is inside a particular network. Authentication and authorization should consider factors such as user identity, device posture, application, location, risk, and the sensitivity of the requested resource. Access can then be granted according to policy and the level of access actually required.

SASE, or Secure Access Service Edge, addresses the architectural side of the problem. It brings networking and security capabilities together through a distributed, cloud-delivered model designed to support users and applications wherever they are located. Instead of forcing all traffic through a traditional central data centre, security and connectivity services can be positioned closer to users, branches, and cloud resources.

A SASE architecture can incorporate capabilities such as secure web gateways, cloud-delivered firewalls, Zero Trust Network Access, security controls, and data protection services. The exact combination varies between implementations and vendors, but the broader objective is consistent: provide secure, policy-driven access without depending on a fixed network perimeter.

The combination of Zero Trust principles with SASE can simplify how organizations approach distributed access. Identity, device context, application requirements, security policy, and network connectivity can be evaluated together rather than treated as completely separate functions. This can help reduce unnecessary access while providing users with more direct and consistent connectivity to the applications they need.

The model also changes how security teams think about visibility and control. Rather than focusing only on network boundaries, they need to understand who is accessing an application, from which device, under what conditions, and what activity occurs after access is granted. Monitoring and policy enforcement therefore become continuous parts of the architecture rather than one-time decisions at the network edge.

Zero Trust and SASE should not be viewed as a single product or a quick replacement for existing security infrastructure. They represent architectural approaches that require careful consideration of identity, applications, devices, connectivity, security controls, legacy systems, and operational processes. When these elements are designed together, Zero Trust and SASE can provide a more adaptable security architecture for organizations operating across distributed users, networks, and cloud environments.

Zero Trust SASE • Risk-Based Access

Zero Trust Access Decision

See how identity, device posture and context are evaluated before access is granted. Zero Trust does not automatically trust the user simply because they are on a known network.

ACCESS DECISION ENGINE
User Request Who is requesting access? Identity User • role • authentication • MFA Device Posture Healthy • managed • compliant Context Location • time • behaviour • resource Risk & Policy Engine Evaluate trust against policy ALLOW Trusted request MFA Verify again LIMITED Restrict access DENY Block request
LEARNING PANEL
Selected

Trusted User

A trusted request still passes through the Zero Trust decision process. Trust is evaluated rather than assumed.

IDENTITY Authenticated user with valid MFA
DEVICE Managed and compliant
CONTEXT Normal behaviour and expected resource
DECISION ALLOW — application access granted

Highlights: Zero Trust SASE

Innovative Security Framework

Zero Trust SASE is an innovative security framework that combines Zero Trust principles with Secure Access Service Edge (SASE) architecture. It emphasizes continuous verification and validation of every user, device, and network resource attempting to access an organization’s network, regardless of location. By adopting a zero-trust approach, organizations can enhance security by eliminating the assumption of trust and implementing stricter access controls.

1. Note: Zero Trust SASE is built upon several key components to create a robust and comprehensive security framework. These components include identity and access management, multi-factor authentication, network segmentation, encryption, continuous monitoring, and threat intelligence integration. Each element is crucial in strengthening network security and protecting against evolving cyber threats.

2. Note: Both SASE and ZTNA are essential components of modern security architecture. However, they are two different solutions. SASE provides a comprehensive, multi-faceted security framework, while ZTNA is a more narrowly focused model focused on limiting resource access, which is a part of SAS

SASE + Zero Trust — Unified Secure Access for Modern Networks

SASE (Secure Access Service Edge) and Zero Trust form a unified architecture for securing modern distributed environments. SASE delivers networking and security controls through a cloud‑based framework, while Zero Trust defines how access should be verified, limited, and continuously monitored. Together, they replace legacy perimeter‑based models with identity‑driven, context‑aware access that follows users, devices, and applications wherever they operate. SASE provides the delivery mechanism—SD‑WAN, SWG, CASB, FWaaS, ZTNA—while Zero Trust provides the decision engine, enforcing least‑privilege access and continuous verification.

— Identity as the Foundation of Secure Access

Zero Trust requires explicit verification of every user, device, and session. Identity becomes the primary control point, replacing network location as the basis for trust. SASE operationalizes this by applying identity‑aware policies at distributed cloud enforcement points rather than centralized data centers. This ensures consistent protection across remote workers, branch sites, and cloud workloads. Identity signals—user role, device posture, authentication strength, and behavioral context—drive access decisions, aligning with NIST Zero Trust principles.

— Continuous Verification and Context‑Aware Access

Zero Trust eliminates implicit trust by continuously evaluating risk throughout the session. SASE enforces this through ZTNA, SWG, CASB, and FWaaS delivered at the cloud edge. Every request is assessed based on identity, device health, location, application sensitivity, and behavioral anomalies. If risk increases—unusual commands, suspicious cloud activity, degraded device posture—policies tighten automatically. This adaptive enforcement ensures that access is always aligned with real‑time context rather than static rules.

— Replacing VPNs with Application‑Level Access

Zero Trust SASE replaces traditional VPNs with ZTNA, granting access only to specific applications rather than entire network segments. This eliminates over‑privileged access and reduces lateral movement risk. Users connect directly to the application they are authorized to use, not the network. This model is especially critical as hybrid work expands and VPN concentrators become bottlenecks and security liabilities. ZTNA inside SASE becomes the modern remote‑access architecture.

— Cloud‑Delivered Security at the Edge

SASE shifts security from centralized appliances to distributed cloud points of presence (PoPs). SWG, CASB, DNS security, FWaaS, and ZTNA are applied close to users and applications, improving performance and reducing backhaul. This cloud‑delivered model supports hybrid work, SaaS adoption, and multi‑cloud architectures by enforcing consistent policies across all edges—branch, remote, and cloud. Zero Trust ensures that these policies are identity‑driven and continuously validated.

— Zero Trust SASE — One Policy Engine for All Traffic

Zero Trust SASE unifies private‑app access, web traffic inspection, SaaS governance, and WAN security under a single policy engine. Identity, device posture, data sensitivity, and application behavior feed into one decision framework. This ensures that least‑privilege access applies not only to private applications but also to SaaS, AI traffic, encrypted channels, and cloud workloads. Modern Zero Trust SASE platforms integrate AI visibility, DLP, and app control to secure data paths—not just ports and protocols.

**Challenge: The Lag in Security** 

Today’s digital transformation and strategy initiatives require speed and agility in I.T. However, there is a lag, and that lag is with security. Security can either hold them back or not align with the fluidity needed for agility. As a result, we have decreased an organization’s security posture, which poses a risk that needs to be managed. We have a lot to deal with, such as the rise in phishing attacks, mobile malware, fake public Wi-Fi networks, malicious apps, and data leaks. Therefore, we have new requirements that SASE can help with.

Zero Trust Security

Zero Trust Security is a paradigm shift from the traditional perimeter-based security model. It operates on the principle of “never trust, always verify.” Unlike the old approach, where users and devices were granted broad access once inside the network, Zero Trust Security treats every user, device, and network segment as potentially untrusted. This enhanced approach minimizes the risk of unauthorized access and lateral movement within the network.

Continuous Verification & Strict Access Control

Zero Trust is a security model that operates on the principle of never trusting any network or user by default. It emphasizes continuous verification and strict access control to mitigate potential threats. With Zero Trust, organizations adopt a granular approach to security, ensuring that every user, device, and application is authenticated and authorized before accessing any resources.

Zero Trust SASE Through Unified Access & Steering

This lab demonstrates how Zero Trust SASE evaluates every access request using identity, posture, and behavioural signals before allowing traffic to move across the network. By analysing trustScore, anomalyScore, burst‑traffic behaviour, device posture, and identity tokens, the Zero Trust SASE engine builds a complete security context for each session. This lightweight model shows learners how Zero Trust SASE continuously validates both the user and the device before any routing or access decision is made.

Unified Access and Steering

When the Zero Trust SASE server receives a request, it calculates a risk score that reflects identity strength, posture health, and behavioural stability. This risk score drives the enforcement outcome, shifting the session between allow, MFA‑required, limited‑access, or deny. Because the test payload represents a trusted and stable session, the Zero Trust SASE engine returns an allow decision. This makes it easy for learners to see how Zero Trust SASE uses risk to adapt its security posture in real time.Zero Trust Engine

The Zero Trust SASE lab provides full visibility into how access decisions are made. The server prints the payload, headers, risk breakdown, and final enforcement action, while the client displays the JSON decision returned by the engine. This end‑to‑end flow illustrates how Zero Trust SASE merges identity validation, posture assessment, and behavioural analytics into a single enforcement pipeline. With this foundation in place, learners can expand into more advanced Zero Trust SASE topics such as microsegmentation, continuous authentication, and dynamic session re‑evaluation.
Zero Trust Enforcement Engine

Zero Trust SASE Through Behaviour‑Driven Trust

This lab demonstrates how Zero Trust SASE strengthens security by evaluating every client request using behavioural signals rather than relying solely on identity or tokens. By analysing request frequency, metadata consistency, and error patterns, the system builds a dynamic trust profile for each client. This ensures that Zero Trust SASE policies continuously validate every action, preventing risky behaviour from moving across the edge‑to‑cloud environment.

The risk engine applies weighted rules to burst‑traffic spikes, identity mismatches, repeated failures, and trust‑score influence to generate a single risk value. This multi‑factor scoring model reflects how Zero Trust SASE depends on combining diverse indicators to detect anomalies across distributed branches, cloud edges, and secure gateways. As risk increases, the system escalates its security posture, shifting from normal to monitored to quarantine service to protect the SASE fabric.

Once the risk score is computed, the steering engine selects the appropriate response path. Low‑risk behaviour is routed normally, medium‑risk behaviour is monitored, and high‑risk behaviour is quarantined. This adaptive routing illustrates how Zero Trust SASE enforces dynamic segmentation, ensuring that suspicious behaviour triggers stronger controls while legitimate application flows continue securely across the network.

Zero Trust SASE Through Identity‑Centric Access Control

This server file demonstrates how Zero Trust SASE begins with strict identity validation before any traffic is allowed to reach protected services. The login endpoint issues JWT tokens that act as authenticated identity credentials, mirroring how SASE platforms verify users before granting access to cloud or edge resources. The JWT middleware enforces continuous authentication, ensuring that every request is checked rather than relying on any implicit trust. By anchoring all routing decisions to verified identity, the application reflects the Zero Trust SASE principle that access must always be authenticated, authorized, and continuously validated

SD WAN Policy

Once identity is confirmed, the application applies Zero Trust SASE logic by evaluating multiple contextual attributes—user role, application version, and client IP—to determine how traffic should be routed. This mirrors how SASE engines combine identity, device posture, application metadata, and network origin to enforce granular access policies. The policy engine dynamically selects the correct backend service based on these combined factors, demonstrating how Zero Trust SASE uses layered, context‑driven checks to classify flows and apply precise routing decisions across distributed cloud environments. Every request is steered according to explicit policy rather than network location or assumed trust.SDN WAN Node Js

The overall behavior of this file showcases how Zero Trust SASE can be implemented through dynamic segmentation and secure path selection. After a request passes identity validation and policy evaluation, the application determines the correct backend service, effectively creating isolated service paths based on role, version, and network origin. This reflects SASE architectures where segmentation is enforced through identity‑driven policy rather than static network boundaries, ensuring that each flow reaches only the services it is authorized to access. By combining identity, metadata, and IP context, the application demonstrates how Zero Trust SASE delivers adaptive, policy‑driven control over traffic movement across cloud and edge environments.
SD WAN security testing
SD WAN Security testing

Knowledge Checks: Microsegmentation

**Understanding Microsegmentation**

Microsegmentation is a network security technique that involves creating secure zones within a data center, enabling organizations to isolate different workloads from each other. This isolation limits the potential for lateral movement by attackers, thereby reducing the attack surface. Unlike traditional network segmentation, which often relies on physical barriers, microsegmentation uses software-defined policies to manage and secure traffic between segments.

**Benefits of Microsegmentation**

The primary advantage of microsegmentation is its ability to provide granular security controls. By implementing policies at the workload level, organizations can tailor security measures to specific applications and data. This not only enhances protection but also improves compliance with regulatory standards. Additionally, microsegmentation offers greater visibility into network traffic, allowing for more effective monitoring and threat detection.

Challenge: Large Segments with VLANs

Example Technology: Network Endpoint Groups

#### What Are Network Endpoint Groups?

Network Endpoint Groups are collections of endpoints, which can be instances, IP addresses, or other network entities, that share the same configuration within Google Cloud. NEGs are pivotal for managing traffic and balancing loads across multiple endpoints, ensuring that applications remain available and performant even under heavy demand. This flexibility allows businesses to seamlessly scale their operations without compromising on efficiency or security.

#### Types of Network Endpoint Groups

Google Cloud provides different types of NEGs to cater to various networking needs:

1. **Zonal NEGs**: These are used for backend services within a single zone, offering reliability and low-latency connections.

2. **Internet NEGs**: Designed for external services, these endpoints can reside outside of Google Cloud, enabling effective hybrid cloud architectures.

3. **Serverless NEGs**: Perfect for serverless applications, these allow you to integrate Cloud Run, App Engine, and Cloud Functions with your load balancer.

Each type serves distinct use cases, making it vital to choose the right NEG for your specific application requirements.

**Understanding Micro-segmentation**

Microsegmentation is a critical strategy in modern network management, providing a method to improve security by dividing a network into smaller, isolated segments. This approach ensures that any potential security breaches are contained and do not spread across the network. In the context of Google Cloud, NEGs can be effectively used to implement microsegmentation. By creating smaller, controlled segments, you can enforce security policies more rigorously, reducing the risk of unauthorized access and enhancing the overall security posture of your applications.


network endpoint groups

**The SASE Concept**

Gartner coined the SASE concept after seeing a pattern emerge in cloud and SD-WAN projects where full security integration was needed. We now refer to SASE as a framework and a security best practice. SASE leverages multiple security services into a framework approach.

The idea of SASE was not far from what we already did, which was integrating numerous security solutions into a stack that ensured a comprehensive, layered, secure access solution. By calling it a SASE framework, the approach to a complete solution somehow felt more focused than what the industry recognized as a best security practice.

The security infrastructure and decisions must become continuous and adaptive, not static, that formed the basis of traditional security methods. Consequently, we must enable real-time decisions that balance risk, trust, and opportunity. As a result, security has beyond a simple access control list (ACL) and zone-based segmentation based on VLANs. In reality, no network point acts as an anchor for security.

Example Technology: IPv6 Access Lists 

Many current network security designs and technologies were not designed to handle all the traffic and security threats we face today. This has forced many to adopt multiple-point products to address the different requirements. Remember that for every point product, there is an architecture to deploy, a set of policies to configure, and a bunch of logs to analyze. I find correlating logs across multiple-point product solutions used in different domains hard.

For example, a diverse team may operate the secure web gateways (SWG) to that of the virtual private network (VPN) appliances. It could be the case that these teams work in silos and are in different locations.

Zero Trust SASE requirements:

  1. Information hiding: SASE requires clients to be authenticated and authorized before accessing protected assets, regardless of whether the connection is inside or outside the network perimeter.
  2. Mutually encrypted connections: SASE uses the full TLS standard to provide mutual, two-way cryptographic authentication. Mutual TLS provides this and goes one step further to authenticate the client.
  3. Need to know the access model: SASE employs a need-to-know access model. As a result, SASE permits the requesting client to view only the resources appropriate to the assigned policy.
  4. Dynamic access control: SASE deploys a dynamic firewall that starts with one rule – deny all. Then, requested communication is dynamically inserted into the firewall, providing an active firewall security policy instead of static configurations.
  5. Identity-driven access control: SASE provides adaptive, identity-aware, precision access for those seeking more precise access and session control to applications on-premises and in the cloud.

Starting Zero Trust

Endpoint Security 

Understanding ARP (Address Resolution Protocol)

ARP is a vital network communication protocol that maps an IP address to a physical MAC address. By maintaining an ARP table, endpoints can efficiently communicate within a network. 

Routes and gateways act as the pathways for data transmission between networks. Safeguarding these routes is crucial to ensure network integrity. We will discuss the significance of secure routing protocols, such as OSPF and BGP, and how they contribute to endpoint security. 

Netstat, short for Network Statistics, is a powerful command-line tool providing detailed information about network connections and statistics. This section will highlight the importance of using netstat for monitoring endpoint security. From identifying active connections to detecting suspicious activities, netstat empowers administrators to protect their networks proactively.

Understanding SELinux

SELinux is a robust security framework built into the Linux kernel. It provides fine-grained access control policies and mandatory access controls (MAC) to enforce system-wide security policies. Unlike traditional Linux discretionary access controls (DAC), SELinux operates on the principle of least privilege, ensuring that only authorized actions are allowed.

Organizations can establish a robust security posture for their endpoints by combining SELinux with zero trust principles. SELinux provides granular control over system resources, enabling administrators to define strict policies based on user roles, processes, and system components. This ensures that even if an endpoint is compromised, the attacker’s lateral movement and potential damage are significantly limited.

### Understanding Authentication in Vault

Authentication is the process of verifying the identity of a user or system. In Vault, this is achieved through various authentication methods such as tokens, AppRole, LDAP, GitHub, and more. Each method serves different use cases, allowing flexibility and scalability in managing access. Vault ensures that only authenticated users can access sensitive data, thus mitigating the risk of unauthorized access.

—

### The Role of Authorization

While authentication verifies identity, authorization determines what authenticated users can do. Vault uses policies to define the actions that users and applications can perform. These policies are written in HashiCorp Configuration Language (HCL) or JSON, and they provide a fine-grained control over access to secrets. By segregating duties and defining clear access levels, Vault helps prevent privilege escalation and minimizes the risk of data exposure.

—

### Managing Identity with Vault

Vault’s identity management capabilities allow organizations to unify identities across various platforms. By integrating with identity providers and managing roles and entities, Vault simplifies user management and enhances security. This integration ensures that user credentials are consistently verified and that access rights are updated as roles change, reducing the risk of stale credentials being exploited.

—

Vault

Use Case: WAN Edge Performance Routing

SASE & Performance-Based Routing

Performance-based routing is a dynamic routing technique that selects the best path for network traffic based on real-time performance metrics. Traditional routing protocols often follow static routes, leading to suboptimal network performance. However, performance-based routing leverages latency, packet loss, and bandwidth availability metrics to make informed routing decisions. By continuously evaluating these metrics, networks can adapt and reroute traffic to ensure optimal performance.

Google Cloud & IAP

**Understanding the Basics of IAP**

At its core, Identity-Aware Proxy is a security service that acts as a gatekeeper for applications and resources. It ensures that only authenticated and authorized users can access specific web applications hosted on cloud platforms. Unlike traditional security models that rely on network-level access controls, IAP takes a user-centric approach, verifying identity and context before granting access. This method not only strengthens security but also simplifies access management across distributed environments.

**The Role of IAP in Google Cloud**

Google Cloud offers a versatile and integrated approach to using IAP, making it an attractive option for organizations leveraging cloud services. With Google Cloud’s IAP, businesses can secure their web applications and VMs without the need for traditional VPNs or complex network configurations. This section will delve into how Google Cloud implements IAP, highlighting its seamless integration with other Google Cloud services and the ease with which it can be deployed. By utilizing Google Cloud’s IAP, businesses can streamline their security operations and focus on delivering value to their customers.

**Benefits of Using Identity-Aware Proxy**

The advantages of implementing IAP are manifold. Firstly, it enhances security by enforcing granular access controls based on user identity and context. This reduces the risk of unauthorized access and potential data breaches. Secondly, IAP simplifies the user experience by enabling single sign-on (SSO) capabilities, allowing users to access multiple applications with a single set of credentials. Additionally, IAP’s integration with existing identity providers ensures that businesses can maintain a consistent security policy across their entire IT ecosystem.

Identity aware proxy

 

Zero Trust SASE • Least Privilege

Zero Trust Micro-Perimeter Lab

Compare broad network access with application-level access. ZTNA creates a smaller security boundary around the application instead of placing the user directly onto the network.

APPLICATION-LEVEL ACCESS
User Identity + device ZTNA Identity + Context Least Privilege Application Policy Application A Approved application ACCESS ALLOWED Application B Policy permitted ACCESS ALLOWED Database Higher privilege ACCESS BLOCKED
LEARNING PANEL
Selected

ZTNA Model

The user is not placed directly onto the network. Access is granted to specific applications based on identity and policy.

ACCESS MODEL Application-level access
TRUST BOUNDARY Micro-perimeter around the application
SECURITY RESULT Reduced lateral movement

Zero Trust SASE

Many challenges to existing networks and infrastructure create big security holes and decrease security posture. In reality, several I.T. components give the entity more access than required. We have considerable security flaws with using I.P. addresses as a security anchor and static locations; the virtual private networks (VPN) and demilitarized zone (DMZ) architectures used to establish access are often configured to allow excessive implicit trust.  

##Challenge 1: The issue with a DMZ

The DMZ is the neutral network between the Internet and your organization’s private network. It’s protected by a front-end firewall that limits Internet traffic to specific systems within its zone. The DMZ can have a significant impact on security if not appropriately protected. Remote access technologies such as VPN or RDP, often located in the DMZ, have become common targets of cyberattacks. One of the main issues I see with the DMZ is that the bad actors know it’s there. It may be secured, but it’s visible.

##Challenge 2: The issue with the VPN

In basic terms, a VPN provides an encrypted server and hides your IP address. However, the VPN does not secure users when they land on a network segment and is based on coarse-grained access control where the user has access to entire network segments and subnets. Traditionally, once you are on a segment, there will be no intra-filtering on that segment. That means all users in that segment need the same security level and access to the same systems, but that is not always the case. 

GRE without IPsec GRE with IPsec

##Challenge 3: permissive network access

VPNs generally provide broad, overly permissive network access with only fundamental access control limits based on subnet ranges. So, the traditional VPN provides overly permissive access and security based on I.P. subnets. Note: The issue with VLAN-based segmentation is large broadcast domains with free-for-all access. This represents a larger attack surface where lateral movements can take place. Below is a standard VLAN-based network running Spanning Tree Protocol ( STP ).

## Challenge 4: Security-based on trust

Much of the non-zero trust security architecture is based on trust, which bad actors abuse. On the other hand, examining a SASE overview includes zero trust networking and remote access as one of its components, which can adaptively offer the appropriate trust required at the time and nothing more. It is like providing a narrow segmentation based on many contextual parameters continuously assessed for risk to ensure the users are who they are and that the entities, either internal or external to the network, are doing what they are supposed to do.

**Removes excessive trust**

A core feature of SASE and Zero Trust is that it removes the excessive trust once required to allow entities to connect and collaborate. Within a zero-trust environment, our implicit trust in traditional networks is replaced with explicit identity-based trust with a default denial. With an identity-based trust solution, we are not just looking at IP addresses to determine trust levels. After all, they are just binary, deemed a secure private or a less trustworthy public. This assumption is where all of our problems started. They are just ones and zeros.

## Challenge 5: IP for Location and Identity 

To improve your security posture, it would be best to stop relying primarily on IP addresses and network locations as a proxy for trust. We have been doing this for decades. There is minimal context in placing a policy with legacy constructs. To determine the trust of a requesting party, we need to examine multiple contextual aspects, not just IP addresses.

And the contextual aspects are continuously assessed for security posture. This is a much better way to manage risk and allows you to look at the entire picture before deciding to enter the network or access a resource.

Example: Firewall Tagging

Firewall tags

1) SASE: First attempt to 

Organizations have adopted different security technologies to combat these changes and include them in their security stack. Many of the security technologies are cloud-based services. Some of these services include the cloud-based secure web gateway (SWG), content delivery network [CDN], and web application firewall [WAF].

A secure web gateway (SWG) protects users from web-based threats and applies and enforces acceptable corporate use policies. A content delivery network (CDN) is a geographically distributed group of servers that works together to deliver Internet content quickly. A WAF, or web application firewall, helps protect web applications by filtering and monitoring HTTP traffic between them and the Internet.

The data center is the center of the universe.

However, even with these welcomed additions to security, the general trend was that the data center is still the center of most enterprise networks and network security architectures. Let’s face it: These designs are becoming ineffective and cumbersome with the rise of cloud and mobile technology. Traffic patterns have changed considerably, and so has the application logic.

2) SASE: Second attempt to

The next attempt was for a converged cloud-delivered secure access service edge (SASE) to accomplish this shift in the landscape. And that is what SASE architecture does. As you know, the SASE architecture relies on multiple contextual aspects to establish and adapt trust for application-level access. It does not concern itself with significant VLANs and broad-level access or believe that the data center is the center of the universe. Instead, the SASE architecture is often based on PoPs, where each PoP acts as the center of the universe.

The SASE definition and its components are a transformational architecture that can combat many of these discussed challenges. A SASE solution converges networking and security services into one unified, cloud-delivered solution that includes the following core capabilities of sase.

From the network side of things: SASE in networking:

    1. Software-defined wide area network (SD-WAN)
    2. Virtual private network (VPN)
    3. Zero Trust Network ZTN
    4. Quality of service (QoS)
    5. Software-defined perimeter (SDP)

Example SDP Technology: VPC Service Controls

**What are VPC Service Controls?**

VPC Service Controls are a security feature offered by Google Cloud that allows organizations to define a security perimeter around their cloud resources. This perimeter helps prevent unauthorized access to sensitive data and provides an additional layer of protection against potential threats. By using VPC Service Controls, you can restrict access to your resources based on specific criteria, ensuring that only trusted entities can interact with your data.

**Key Benefits of Implementing VPC Service Controls**

Implementing VPC Service Controls offers several key benefits for organizations seeking to enhance their cloud security:

1. **Enhanced Data Security**: By creating a security perimeter around your cloud resources, you can reduce the risk of data breaches and ensure that sensitive information remains protected.

2. **Granular Access Control**: VPC Service Controls allow you to define access policies based on various factors such as source IP addresses, user identities, and more. This granular control ensures that only authorized users can access your resources.

3. **Simplified Compliance**: For organizations operating in regulated industries, compliance with data protection laws is critical. VPC Service Controls simplify the process of meeting regulatory requirements by providing a robust security framework.

4. **Seamless Integration**: Google Cloud’s VPC Service Controls integrate seamlessly with other Google Cloud services, allowing you to maintain a consistent security posture across your entire cloud environment.

**Setting Up VPC Service Controls**

Getting started with VPC Service Controls is a straightforward process. First, identify the resources you want to protect and define the security perimeter around them. Next, configure access policies to control who can access these resources and under what conditions. Google Cloud provides detailed documentation and tools to guide you through the setup process, ensuring a smooth implementation.

**Best Practices for Using VPC Service Controls**

To maximize the effectiveness of your VPC Service Controls, consider the following best practices:

– **Regularly Review Access Policies**: Periodically review and update access policies to ensure they align with your organization’s security requirements and industry standards.

– **Monitor and Audit Activity**: Use Google Cloud’s monitoring and logging tools to track access to your resources and identify any potential security incidents.

– **Educate Your Team**: Ensure that your team is well-versed in the use of VPC Service Controls and understands the importance of maintaining a secure cloud environment.

VPC Security Controls VPC Service Controls

From the security side of things, SASE capabilities in security:

    1. Firewall as a service (FWaaS)
    2. Domain Name System (DNS) security
    3. Threat prevention
    4. Secure web gateways
    5. Data loss prevention (DLP)
    6. Cloud access security broker (CASB)

Example Technology: The Web Security Scanner

### How Google Cloud’s Web Security Scanner Works

Google Cloud’s Web Security Scanner is a robust solution that integrates seamlessly with the Google Cloud environment. It automatically scans your web applications for common vulnerabilities, such as cross-site scripting (XSS), mixed content, and outdated libraries. The scanner’s intuitive interface provides detailed reports, highlighting potential issues and offering actionable recommendations for mitigation. This automation not only saves time but also ensures that your applications remain secure as you continue to develop and deploy new features.

### Key Features and Benefits

One of the standout features of Google Cloud’s Web Security Scanner is its ability to perform authenticated scans. This means it can test parts of your web application that require user login, ensuring a comprehensive security assessment. Additionally, the scanner is designed to work seamlessly with other Google Cloud services, making it a convenient choice for those already invested in the Google ecosystem. Its cloud-native architecture ensures that it scales efficiently to meet the needs of businesses, big and small.

### Best Practices for Using Web Security Scanners

To get the most out of your web security scanner, it’s important to integrate it into your continuous integration and deployment processes. Regularly scanning your applications ensures that any new vulnerabilities are promptly identified and addressed. Additionally, consider using the scanner alongside other security tools to create a multi-layered defense strategy. Training your development team on common security pitfalls can also help prevent vulnerabilities from being introduced in the first place.

security web scanner

SASE changes the focal point to the identity of the user and device. With traditional network design, we have the on-premises data center, considered the universe’s center. With SASE, that architecture changes this to match today’s environment and moves the perimeter to the actual user, devices, or PoP with some SASE designs. In contrast to traditional enterprise networks and security architectures, the internal data center is the focal point for access. 

Example Product: Cisco Meraki

### What is Cisco Meraki?

Cisco Meraki is a suite of cloud-managed IT solutions that include wireless, switching, security, EMM (Enterprise Mobility Management), and security cameras, all centrally managed from the web. The Meraki dashboard provides powerful and intuitive tools to manage your entire network from a single pane of glass. This holistic approach ensures that businesses can maintain robust security protocols without compromising on ease of management.

### Key Features of Cisco Meraki

#### Cloud-Based Management

One of the standout features of Cisco Meraki is its cloud-based management. This allows for real-time monitoring, configuration, and troubleshooting from anywhere in the world. With automatic updates and seamless scalability, businesses can ensure their network is always up-to-date and secure.

#### Advanced Security Features

Cisco Meraki offers a range of advanced security features designed to protect your network from various threats. These include intrusion detection and prevention systems (IDS/IPS), advanced malware protection (AMP), and content filtering. By leveraging these tools, businesses can safeguard their data and maintain the integrity of their network.

#### Simplified Deployment

Deploying a traditional network can be a complex and time-consuming task. Cisco Meraki simplifies this process with zero-touch provisioning, which allows devices to be pre-configured and managed remotely. This reduces the need for on-site technical expertise and accelerates the deployment process.

### Benefits of Using Cisco Meraki for Network Security

#### Centralized Control

The centralized control offered by the Meraki dashboard enables IT teams to manage multiple sites from a single interface. This not only streamlines operations but also ensures consistent security policies across all locations.

#### Scalability

As businesses grow, their network needs evolve. Cisco Meraki’s scalable solutions allow for easy expansion without the need for significant infrastructure changes. This flexibility ensures that businesses can adapt to changing demands without compromising on security.

#### Cost Efficiency

By reducing the need for on-site hardware and simplifying management, Cisco Meraki can lead to significant cost savings. Additionally, the reduced need for technical expertise can lower operational costs, making it an attractive option for businesses looking to optimize their IT budget.

VPN Security Scenario 

  • Challenge: Traditional remote access VPNs

Remote access VPNs are primarily built to allow users outside the perimeter firewall to access resources inside the perimeter firewall. As a result, they often follow a hub-and-spoke architecture, with users connected by tunnels of various lengths depending on their distance from the data center. Traditional VPNs introduce a lot of complexity. For example, what do you do if you have multiple sites where users need to access applications? In this scenario, the cost of management would be high. 

  • Challenge: Tunnel based on I.P

What’s happening here is that the tunnel creates an extension between the client device and the application location. The tunnel is based on IP addresses on the client device and the remote application. Now that there is I.P. connectivity between the client and the application, the network where the application is located is extended to the client.

However, the client might not sit in an insecure hotel room or from home. These may not be sufficiently protected, and such locations should be considered insecure. The traditional VPN has many issues to deal with. It is user-initiated, and policy often permits split-tunnel VPNs without Internet or cloud traffic inspection.

SASE: A zero-trust VPN solution

A SASE solution encompasses VPN services and enhances the capabilities of operating in cloud-based infrastructure to route traffic. On the other hand, with SASE, the client connects to the SASE PoP, which carries out security checks and forwards the request to the application. A SASE design still allows clients to access the application, but they can only access that specific application and nothing more, like a stripped-down VLAN known as a micro-segmentation.

Restricting Lateral Movements

Clients must pass security controls, and no broad-level access is susceptible to lateral movements. Access control is based on an allowlist rather than the traditional blocklist rule. Also, other variables present in the request context are used instead of using I.P. addresses as the client identifier. As a result, the application is now the access path, not the network.

Simplified Management & Policy Control

So, no matter what type of VPN services you use, the SASE provides a unified cloud to connect to instead of backhauling to a VPN gateway—simplifying management and policy control. Well-established technologies such as VPN, secure web gateway, and firewall are being reviewed and reassessed in Zero Trust remote access solutions as organizations revisit approaches that have been in place for over a decade. 

A recommendation: SASE and SD-WAN

The value of SD-WAN is high. However, it also brings many challenges, including new security risks. In some of my consultancies, I have seen unreliable performance and increased complexity due to the need for multiple overlays. Also, these overlays need to terminate somewhere, and this will be at a hub site.  However, when combined with SASE, the SD-WAN edge devices can be connected to a cloud-based infrastructure rather than the physical SD-WAN hubs. This brings the value of interconnectivity between branch sites without the complexity of deploying or managing physical Hub sites.

Zero Trust SASE: Vendor considerations

SASE features converge various individual components into one connected, cloud-delivered service, making it easy to control policies and behaviors. The SASE architecture is often based on a PoP design. When examining the SASE vendor, the vendor’s PoP layout should be geographically diverse, with worldwide entry and exit points. 

Also, considerations should be made regarding the vendor’s edge/physical infrastructure providers or colocation facilities. We can change your security posture, but we can’t change the speed of light and the laws of physics.

Consider how the SASE vendor routes traffic in their PoP fabric. Route optimization should be performed at each PoP. Some route optimizations are for high availability, while others are for performance. Does the vendor offer cold-potato or hot-potato routing? The cold-potato routing means bringing the end-user device into the provider’s network as soon as possible. On the other hand, “hot-potato routing” means the end user’s traffic traverses more of the public Internet.

The following is a list of considerations to review when discussing SASE with your preferred cybersecurity vendor:

A. Zero Trust SASE requirements: Information hiding:

Secure access service requires clients to be authenticated and authorized before accessing protected assets, regardless of whether the connection is inside or outside the network perimeter. Then, real-time encrypted connections are created between the requesting client and the protected asset. As a result, all SASE-protected servers and services are hidden from all unauthorized network queries and scan attempts.

You can’t attack what you can’t see.

The base for network security started by limiting visibility – you cannot attack what you cannot see. Public and private IP addresses range from separate networks. This was the biggest mistake we ever made as I.P. addresses are just binary, whether they are deemed public or private. If a host were assigned a public address and wanted to communicate with a host with a private address, it would need to go through a network address translation (NAT) device and have a permit policy set.

Understanding Port Knocking

Port knocking is a technique that enables secure and controlled access to network services. Traditionally, network ports are open and accessible, leaving systems vulnerable to unauthorized access. However, with port knocking, access to specific ports is only granted after a predefined sequence of connection attempts is made to other closed ports. This sequence acts as a virtual “knock” on the door, allowing authorized users to gain access while keeping malicious actors at bay.

To fully comprehend port knocking, let’s explore its inner mechanics. When users wish to access a specific service, they must first send connection attempts to a series of closed ports in a particular order. This sequence acts as a secret handshake, notifying the server that the user is authorized. Once the correct sequence is detected, the server dynamically opens the desired port, granting access to the requested service. It’s like having a hidden key that unlocks the door to a secure sanctuary.

Security based on the visibility

Network address translation is mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. Limiting visibility this way works to a degree, but we cannot ignore the fact that a) if you have someone’s IP address, you can reach them, and b) if a port is open, you can potentially connect to it.

Therefore, the traditional security method can open your network wide for compromise, especially when bad actors have all the tools. However, finding, downloading, and running a port scanning tool is not hard.

“Nmap,” for Network Mapper, is the most widely used port scanning tool. Nmap works by checking a network for hosts and services. Once found, the software platform sends information to those hosts and services, responding. Nmap reads and interprets the response and uses the data to create a network map.

Example: Understanding Lynis

Lynis is an open-source security auditing tool for discovering vulnerabilities on Unix, Linux, and macOS systems. It comprehensively analyzes the system’s configuration and provides valuable insights into potential security weaknesses. By scanning the system against a vast database of known security issues, Lynis helps identify areas for improvement.

Lynis runs a series of tests and audits on the target system. It examines various aspects, including file permissions, system settings, available software packages, and network configurations. Lynis generates a detailed report highlighting any identified vulnerabilities or potential security gaps by analyzing these factors. This report becomes a valuable resource for system administrators and security professionals to take necessary actions and mitigate risks.

Example: Single Packet Authorization

Zero-trust network security hides information and infrastructure through lightweight protocols such as single-packet authorization (SPA). No internal IP addresses or DNS information is shown, creating an invisible network. As a result, we have zero visibility and connectivity, only establishing connectivity after clients prove they can be trusted to allow legitimate traffic. Now, we can have various protected assets hidden regardless of location: on-premise, public or private clouds, a DMZ, or a server on the internal LAN, in keeping with today’s hybrid environment.

Default-drop dynamic firewall

This approach mitigates denial-of-service attacks. Anything internet-facing is reachable on the public Internet and, therefore, susceptible to bandwidth and server denial-of-service attacks. The default-drop firewall is deployed, with no visible presence to unauthorized users. Only good packets are allowed. Single packet authorization (SPA) also provides for attack detection.

If a host receives anything other than a valid SPA packet or similar construct, it views that packet as part of a threat. The first packet to a service must be a valid SPA packet or similar security construct.

If it receives another packet type, it views this as an attack, which is helpful for bad packet detection. Therefore, SPA can determine an attack based on a single malicious packet, a highly effective way to detect network-based attacks. Thus, external network and cross-domain attacks are detected.

B. Zero Trust SASE architecture requirements: Mutually encrypted connections:

Transport Layer Security ( TLS ) is an encryption protocol that protects data when it moves between computers. When two computers send data, they agree to encrypt the information in a way they both understand. Transport layer security (TLS) was designed to provide mutual device authentication before enabling confidential communication over the public Internet. However, the standard TLS configuration validates that the client is connected to a trusted entity. So, typical TLS adoptions authenticate servers to clients, not clients to servers. 

Mutually encrypted connections

SASE uses the full TLS standard to provide mutual, two-way cryptographic authentication. Mutual TLS provides this and goes one step further to authenticate the client. Mutual TLS connections are set up between all components in the SASE architecture. Mutual Transport Layer Security (mTLS) establishes an encrypted TLS connection in which both parties use X. 509 digital certificates to authenticate each other.

MTLS can help mitigate the risk of moving services to the cloud and prevent malicious third parties from imitating genuine apps. This offers robust device and user authentication, as connections from unauthorized users and devices are mitigated. Secondly, forged certificates, which are attacks aimed at credential theft, are disallowed. This will reduce impersonation attacks, where a bad actor can forge a certificate from a compromised authority.

C. Need to know the access model: Zero Trust SASE architecture requirements

Thirdly, SASE employs a need-to-know access model. As a result, SASE permits the requesting client to view only the resources appropriate to the assigned policy. Users are associated with their devices, which are validated based on policy. Only connections to the specifically requested service are enabled, and no other connection is allowed to any other service. SASE provides additional information, such as who made the connection, from what device, and to what service.

This gives you complete visibility into all the established connections, which is hard to do without an IP-based solution. So now we have a contextual aspect of determining the level of risk. As a result, it makes forensics easier. The SASE architecture only accepts good packets; bad packets can be analyzed and tracked for forensic activities.

Key Point: Device validation

Secondly, it enforces device validation, which helps against threats from unauthorized devices. We can examine the requesting user and perform device validation. Device validation ensures that the machine runs on trusted hardware and is used by the appropriate user.

Finally, suppose a device becomes compromised. In that case, lateral movements are entirely locked down, as a user is only allowed access to the resource it is authorized to. Or they could be placed into a sandbox zone where human approval must intervene and assess the situation.

D. Dynamic access control: Zero Trust SASE architecture requirements

This traditional type of firewall is limited in scope as it cannot express or enforce rules based on identity information, which you can with zero trust identity. Attempting to model identity-centric control with the limitations of the 5-tuple, SASE can be used alongside traditional firewalls and take over the network access control enforcement that we try to do with conventional firewalls. SASE deploys a dynamic firewall that starts with one rule – deny all.

Then, requested communication is dynamically inserted into the firewall, providing an active firewall security policy instead of static configurations. For example, every packet hitting the firewall is inspected with a single packet authentication (SPA) and then quickly verified for a connection request. 

Key Point: Dynamic firewall

Once established, the firewall is closed again. Therefore, the firewall is dynamically opened only for a specific period. The connections made are not seen by rogues outside the network or the user domain within the network. Allows dynamic, membership-based enclaves that prevent network-based attacks.

The SASE dynamically binds users to devices, enabling those users to access protected resources by dynamically creating and removing firewall rules.  Access to protected resources is facilitated by dynamically creating and removing inbound and outbound access rules. Therefore, we now have more precise access control mechanisms and considerably reduced firewall rules.

**Micro perimeter**

Traditional applications were grouped into VLANs whether they offered similar services or not. Everything on that VLAN was reachable. The VLAN was a performance construct to break up broadcast domains, but it was pushed into the security world and never meant to be there. 

Its prime use was to increase performance. However, it was used for security in what we know as traditional zone-based networking. The segments in zone-based networks are too large and often have different devices with different security levels and requirements.

Key Points:

A. Logical-access boundary: SASE enables this by creating a logical access boundary encompassing a user and an application or set of applications. And that is it—nothing more and nothing less. Therefore, we have many virtual micro perimeters specific to the business instead of the traditional main inside/outside perimeter. Virtual perimeters allow you to grant access to the particular application, not the underlying network or subnet.

B. Reduce the attack surface: The smaller micro perimeters reduce the attack surface and limit the need for excessive access to all ports and protocols or all applications. These individualized “virtual perimeters” encompass only the user, the device, and the application. They are created and specific to the session and then closed again when it is over or if the risk level changes and the device or user needs to perform setup authentication.

C. Software-defined perimeter (SDP): SASE only grants access to the specific application at an application layer. The SDP part of SASE now controls which devices and applications can access distinctive services at an application level. Permitted by a policy granted by the SDP part of SASE, machines can only access particular hosts and services and cannot access network segments and subnets.

**Reduced: Broad Network Access**

Broad network access is eliminated, reducing the attack surface to an absolute minimum. SDP provides a fully encrypted application communication path. However, the binding application permits only authorized applications to communicate through the established encrypted tunnels, thus blocking all other applications from using them. This creates a dynamic perimeter around the application, including connected users and devices. Furthermore, it offers a narrow access path—reducing the attack surface to an absolute minimum.

E. Identity-driven access control: Zero Trust SASE architecture requirements

Traditional network solutions provide coarse-grained network segmentation based on someone’s IP address. However, someone’s IP address is not a good security hook and does not provide much information about user identity. SASE enables the creation of microsegmentation based on user-defined controls, allowing a 1-to-1 mapping, unlike with a VLAN, where there is the potential to see everything within that VLAN.

Identity-aware access: SASE provides adaptive, identity-aware, precision access for those seeking more precise access and session control to applications on-premises and in the cloud. Access policies are primarily based on user, device, and application identities. The procedure is applied independent of the user’s physical location or the device’s I.P. address, except where it prohibits it. This brings a lot more context to policy application. Therefore, if a bad actor gains access to one segment in the zone, they are prevented from compromising any other network resource.

Detecting Authentication Failures in Logs:

Syslog: Useful Security Technology

Syslog, short for System Logging Protocol, is a standard for message logging within computer systems. It collects various log entries from different sources and stores them in a centralized location. Syslog is a valuable resource for detecting security events as it captures information about system activities, errors, and warnings.

Auth.log is a specific type of log file that focuses on authentication-related events in Unix-based operating systems. It records user logins, failed login attempts, password changes, and other authentication activities. Analyzing auth.log can provide vital insights into potential security breaches, such as brute-force attacks or suspicious login patterns.

Now that we understand the importance of syslog and auth.log, let’s delve into some effective techniques for detecting security events in these files. One widely used approach is log monitoring, where automated tools analyze log entries in real time, flagging suspicious or malicious activities. Another technique is log correlation, which involves correlating events across multiple log sources to identify complex attack patterns.

Zero Trust SASE • Cloud Security Edge

SASE Secure Access Flow

SASE brings networking and security services together at distributed cloud edges. The user request is inspected and policy is enforced before reaching the protected application.

SECURE ACCESS PATH
Remote User Identity + device SASE PoP Distributed security edge Policy inspection Identity-aware enforcement Traffic optimization ZTNA Private applications SWG Web security CASB SaaS visibility FWaaS Cloud firewall Policy Inspect Allow / Block Protected App Only approved access
LEARNING PANEL
Selected

SASE PoP

A SASE Point of Presence brings security enforcement closer to users and applications.

ROLE Distributed security edge
TRAFFIC Identity-aware inspection
RESULT Only policy-approved traffic continues

Summary: Zero Trust SASE

Traditional security measures are no longer sufficient in today’s rapidly evolving digital landscape, where remote work and cloud-based applications have become the norm. Enter Zero Trust Secure Access Service Edge (SASE), a revolutionary approach that combines network security and wide-area networking into a unified framework. In this blog post, we explored the concept of Zero Trust SASE and its implications for the future of cybersecurity.

Understanding Zero Trust

Zero Trust is a security framework that operates under the “never trust, always verify.” It assumes no user or device should be inherently trusted, regardless of location or network. Instead, Zero Trust focuses on continuously verifying and validating identity, access, and security parameters before granting any level of access.

The Evolution of SASE

Secure Access Service Edge (SASE) represents a convergence of network security and wide-area networking capabilities. It combines security services, such as secure web gateways, firewall-as-a-service, and data loss prevention, with networking functionalities like software-defined wide-area networking (SD-WAN) and cloud-native architecture. SASE aims to provide comprehensive security and networking services in a unified, cloud-delivered model.

The Benefits of Zero Trust SASE:

a) Enhanced Security: Zero Trust SASE brings a holistic approach to security, ensuring that every user and device is continuously authenticated and authorized. This reduces the risk of unauthorized access and mitigates potential threats.

b) Improved Performance: By leveraging cloud-native architecture and SD-WAN capabilities, Zero Trust SASE optimizes network traffic, reduces latency, and enhances overall performance.

c) Simplified Management: A unified security and networking framework can streamline organizations’ management processes, reduce complexity, and achieve better visibility and control over their entire network infrastructure.

Implementing Zero Trust SASE

a) Comprehensive Assessment: Before adopting Zero Trust SASE, organizations should conduct a thorough assessment of their existing security and networking infrastructure, identify vulnerabilities, and define their security requirements.

b) Architecture Design: Organizations must design a robust architecture that aligns with their needs and integrates Zero Trust principles into their existing systems. This may involve deploying virtualized security functions, adopting SD-WAN technologies, and leveraging cloud services.

c) Continuous Monitoring and Adaptation: Zero Trust SASE is an ongoing process that requires continuous monitoring, analysis, and adaptation to address emerging threats and evolving business needs. Regular security audits and updates are crucial to maintaining a solid security posture.

Conclusion: Zero Trust SASE represents a paradigm shift in cybersecurity, providing a comprehensive and unified approach to secure access and network management. By embracing the principles of Zero Trust and leveraging the capabilities of SASE, organizations can enhance their security, improve performance, and simplify their network infrastructure. As the digital landscape continues to evolve, adopting Zero Trust SASE is not just an option—it’s necessary to safeguard our interconnected world’s future.

rsz_secure_access_service_edge1

SASE Definition

As organisations distribute applications, users, and workloads across data centres, public cloud platforms, SaaS services, branches, and remote locations, the traditional model of sending traffic back through a central corporate network becomes increasingly difficult to scale. Secure Access Service Edge (SASE) addresses this challenge by bringing networking and security capabilities together through a cloud-delivered architectural model designed for distributed environments.

SASE combines software-defined networking with security services so that connectivity and security policy can be applied closer to users, devices, branches, and applications. Rather than treating the corporate data centre as the primary security boundary, SASE recognises that users and applications may exist in many different locations. The architecture therefore focuses on providing secure, policy-controlled access regardless of where the connection originates.

Several technologies commonly contribute to a SASE architecture. SD-WAN provides software-defined connectivity and traffic steering across transports such as MPLS, broadband, Internet, and cellular networks. Security services can include Secure Web Gateway (SWG), Firewall as a Service (FWaaS), Cloud Access Security Broker (CASB), Zero Trust Network Access (ZTNA), and data protection capabilities. The exact combination varies between implementations and providers, but the architectural objective is to bring these capabilities together through a consistent policy and operational model.

Zero Trust is particularly important to the SASE approach. Access decisions should not be based simply on whether a user is connected to a trusted corporate network. Instead, policies can consider identity, device posture, application, location, security context, and the sensitivity of the requested resource. Authentication and authorisation therefore become part of the access decision rather than an assumption made from network location alone.

SASE can also simplify operations by reducing the need to deploy and manage separate security appliances at every branch or user location. Cloud-delivered services can provide centrally managed policy while allowing enforcement to occur closer to the user or application. This can improve consistency, but implementation still requires careful planning around identity, existing infrastructure, application dependencies, traffic flows, security policy, and operational processes.

Performance is another important consideration. Distributed users accessing cloud and SaaS applications may not benefit from routing all traffic through a central data centre. SASE architectures can combine SD-WAN traffic steering with distributed security enforcement to select appropriate paths while maintaining security policy. Network performance, application experience, latency, packet loss, and service availability therefore become important operational measurements alongside traditional security events.

SASE is particularly relevant to hybrid and multi-cloud environments because the network boundary is no longer defined by a single physical location. Organisations may need to connect offices, remote users, private data centres, public clouds, SaaS applications, and third-party services while maintaining consistent access controls and security policies across these environments.

The most useful way to understand SASE is not as a single product or technology, but as an architectural approach for converging networking and security around distributed users and applications. Its effectiveness depends on how well connectivity, identity, security policy, application access, visibility, and operations are integrated. For organisations modernising their WAN and security architecture, SASE provides a framework for building secure access around the way applications and users actually operate today.

SASE Definition

Secure Access Service Edge • Widget 1

SASE Architecture Explorer

See how SASE brings networking and security together as a cloud-delivered service, with enforcement distributed closer to users, branches and applications.
USER / DEVICE Remote User Laptop / Mobile Anywhere EDGE Branch / Site Office / Campus SD-WAN edge SASE EDGE SASE PoP Distributed point of presence CONNECTIVITY SD-WAN / routing SECURITY inspection / control POLICY consistent enforcement CLOUD FABRIC SASE Cloud Networking + Security SD-WAN path control SWG web security CASB cloud control ZTNA access control FWaaS cloud firewall CLOUD APP SaaS Microsoft 365 CRM / Web Apps PRIVATE APP Enterprise Data Center / Private Cloud CORE SASE IDEA Connect users and sites to distributed SASE edges, then apply networking and security services close to the access point. CONVERGED SERVICES One cloud-delivered architecture
SASE CONCEPT

SASE Overview

SASE combines networking and security capabilities into a cloud-delivered architecture. Instead of forcing users and sites through a centralized security perimeter, services can be delivered from distributed points of presence.

Key Idea SASE is not simply a collection of security products. The important architectural change is the convergence of networking, security, cloud delivery and distributed enforcement.
SD-WAN SWG CASB ZTNA FWaaS
Cloud Delivered Networking and security functions are delivered from a distributed cloud architecture rather than requiring a separate appliance at every location.
Distributed Enforcement Users and sites can connect to nearby SASE PoPs, reducing dependence on traditional centralized security choke points.
Unified Architecture Routing, security and access policies can be managed as part of one operational model instead of many disconnected point solutions.

Highlights: SASE Definition

SASE: A Cloud-Centric Approach

Firstly, the SASE is related to our environment. In a cloud-centric world, users and devices require access to services everywhere. The focal point has changed. Now, the identity of the user and device, as opposed to the traditional model, focuses solely on the data center with many network security components. These environmental changes have created a new landscape we must protect and connect.

Many common problems challenge the new landscape. Due to deployed appliances for different technology stacks, enterprises are loaded with complexity and overhead. The legacy network and security designs increase latency. In addition, the world is encrypted when considering Zero Trust SASE. This needs to be inspected without degrading application performance.

These are reasons to leverage a cloud-delivered secure access service edge (SASE). SASE means a tailored network fabric optimized where it makes the most sense for the user, device, and application – at geographically dispersed PoPs enabling technologies that secure your environment with technologies such as single packet authorization.

**Driving Forces to Adopting SASE**

Challenge 1: Managing the Network: Converging network and security into a single platform does not require multiple integration points. This will eliminate the need to deploy these point solutions and the complexities of managing each.

Challenge 2: Site Connectivity: SASE handles all management complexities. As a result, the administrative overhead for managing and operating a global network that supports site-to-site connectivity and enhanced security, cloud, and mobility is kept to an absolute minimum.

Challenge 3: Performance Between Locations: The SASE cloud already has an optimized converged network and security platforms. Therefore, sites need to connect to the nearest SASE PoP.

Challenge 4: Cloud Agility: SASE natively supports cloud data centers (IaaS) and applications (SaaS) without additional configuration, complexity, or point solutions, enabling built-in cloud connectivity.

SASE Definition — A Converged Cloud Architecture for Secure Connectivity

Secure Access Service Edge (SASE) is a cloud‑delivered architecture that merges networking and security into a single, unified service model. Instead of deploying separate appliances for WAN connectivity, web filtering, cloud security, and remote access, SASE consolidates these capabilities into a distributed cloud fabric. The goal is simple: provide consistent, high‑performance, secure access to applications—no matter where users are located or where workloads reside. SASE shifts security and networking away from traditional data‑center choke points and distributes them across global points of presence, creating a seamless edge‑to‑cloud access layer.

Convergence of Networking and Security Services

SASE is defined by the convergence of two historically separate domains:

  • Network services such as SD‑WAN, traffic optimization, and dynamic path selection
  • Security services such as SWG, CASB, FWaaS, and threat inspection

By delivering these as cloud‑native functions, SASE eliminates the complexity of managing multiple point products. Policies, routing decisions, and security controls are applied consistently across all edges—branch, remote, mobile, and cloud. This convergence ensures that performance and protection are no longer competing priorities but integrated outcomes of the same architecture.

Cloud‑Native Enforcement at Global Points of Presence

A defining characteristic of SASE is its distributed enforcement model. Instead of backhauling traffic to a central firewall or VPN concentrator, SASE evaluates and secures traffic at cloud points of presence (PoPs) located close to users and applications. These PoPs provide:

  • low‑latency inspection
  • scalable policy enforcement
  • optimized routing to SaaS and cloud platforms
  • unified visibility across all user traffic

This distributed model supports hybrid work, multi‑cloud adoption, and global operations without relying on legacy hub‑and‑spoke designs.

Unified Policy, Visibility, and Operational Control

SASE centralizes policy management into a single cloud platform. Administrators define access rules, security controls, and routing preferences once, and the SASE fabric enforces them everywhere. This unified control plane provides:

  • consistent policy enforcement
  • real‑time visibility into user and application behavior
  • simplified operations across distributed environments
  • automated updates and continuous improvement

SASE reduces operational overhead by replacing manual configuration with cloud‑driven orchestration and analytics‑based optimization.

Outcome‑Driven Architecture for Modern Enterprises

SASE is not just a technology stack—it is an operational model designed to deliver measurable outcomes:

  • Improved performance through optimized cloud and SaaS access
  • Reduced complexity by consolidating multiple security and networking tools
  • Stronger protection through unified inspection and consistent policy enforcement
  • Scalability for global users, remote workforces, and cloud‑native applications

By merging connectivity and security into a single cloud‑delivered architecture, SASE becomes the foundation for modern digital transformation.

**Components of SASE**

1. Network as a Service (NaaS): SASE integrates network services such as SD-WAN (Software-Defined Wide Area Network) and cloud connectivity to provide organizations with a flexible and scalable network infrastructure. With NaaS, businesses can optimize network performance, reduce latency, and ensure reliable connectivity across different environments.

2. Security as a Service (SECaaS): SASE incorporates various security services, including secure web gateways, firewall-as-a-service, data loss prevention, and zero-trust network access. By embedding security into the network infrastructure, SASE enables organizations to enforce consistent security policies, protect against threats, and simplify the management of security measures.

3. Zero-Trust Architecture: SASE adopts a zero-trust approach, which assumes that no user or device should be trusted by default, even within the network perimeter. By implementing continuous authentication, access controls, and micro-segmentation, SASE ensures that every user and device is verified before accessing network resources, reducing the risk of unauthorized access and data breaches.

4. Cloud-Native Architecture: SASE leverages cloud-native technologies to provide a scalable, agile, and elastic network and security infrastructure. By transitioning from legacy hardware appliances to software-defined solutions, SASE enables organizations to respond more to changing business requirements, reduce costs, and improve overall efficiency.

Note: Point Solutions

SASE is becoming increasingly popular among organizations because it provides a more flexible and cost-effective approach to networking and security. The traditional approach involves deploying multiple devices or appliances, each with its functions. This approach can be complex, time-consuming, and expensive to manage. On the other hand, SASE simplifies this process by integrating all the necessary functions into a single platform.

Example Technology: Web Security Scanner

security web scanner

Example Product: Cisco Meraki

### Simplified Network Management

One of the standout features of the Cisco Meraki platform is its simplified network management. Gone are the days of complex configurations and time-consuming setups. With Meraki’s cloud-based interface, administrators can manage their entire network from a single dashboard. This ease of use not only saves time but also reduces the need for specialized IT staff, making it an ideal solution for businesses of all sizes.

### Robust Security Features

Security is a top priority for any network, and Cisco Meraki does not disappoint. The platform comes equipped with robust security features, including advanced threat protection, intrusion detection, and automated firmware updates. These features work seamlessly to protect your network from potential threats, ensuring that your data remains secure and your operations run smoothly.

### Scalability and Flexibility

As your business grows, so too does the need for a scalable network solution. Cisco Meraki’s platform is designed with scalability in mind, allowing you to easily add new devices and extend your network without any hassle. Whether you’re expanding to a new office location or integrating additional IoT devices, Meraki’s flexible architecture ensures that your network can grow alongside your business.

### Enhanced Visibility and Analytics

Understanding your network’s performance is crucial for making informed decisions. Cisco Meraki offers enhanced visibility and analytics, providing detailed insights into network usage, device performance, and potential issues. With these analytics, administrators can proactively address problems before they impact operations, optimize resource allocation, and ensure that their network is running at peak efficiency.

### Streamlined Troubleshooting

Troubleshooting network issues can be a daunting task, but Cisco Meraki makes it easier than ever. The platform’s intuitive dashboard provides real-time alerts and diagnostic tools, allowing administrators to quickly identify and resolve issues. This streamlined troubleshooting process minimizes downtime and keeps your network running smoothly.

**SASE Meaning: SASE wraps up**

SASE is a network and security architecture consolidating numerous network and security functions, traditionally delivered as siloed point solutions, into an integrated cloud service. It combines several network and security capabilities along with cloud-native security functions. The functions are produced from the cloud and provided by the SASE vendor.

They are essentially providing a consolidated, platform-based approach to security. We have a cloud-delivered solution consolidating multiple edge network security controls and network services into a unified solution with centralized management and distributed enforcement.

**The appliance-based perimeter**

Even Though there has been a shift to the cloud, the traditional perimeter network security solution has remained appliance-based. The change for moving security controls to the cloud is for better protection and performance, plus ease of deployment and maintenance.

The initial performance of the earlier cloud-delivered solutions has been overcome with the introduction of optimized routing and global footprint. However, there is a split in opinion about performance and protection. Many consider protection and performance prime reasons to remain on-premises and keep the network security solutions on-premises.

 

Secure Access Service Edge • Widget 2

SASE Performance & PoP Path Explorer

Explore how SASE chooses an access path through distributed points of presence and why latency, packet loss and jitter can matter more than raw bandwidth.
USER ACCESS SASE PoPs GLOBAL BACKBONE CLOUD APPLICATION SOURCE User Dublin / Remote POP A Nearby PoP Low-latency option POP B Distant PoP Higher latency 18 ms 46 ms EDGE 1 Backbone EDGE 2 Backbone EDGE 3 Backbone DESTINATION SaaS Application Cloud workload Example: Microsoft 365 PATH QUALITY LATENCY 18 ms PACKET LOSS 0.1% JITTER 3 ms OPTIMAL PATH PERFORMANCE PRINCIPLE Application performance depends on the quality of the path, not simply the amount of available bandwidth.
PATH ANALYSIS

Choose the Best Path

SASE can use distributed points of presence and optimized connectivity to steer traffic toward a suitable application path. Select a PoP or path to explore the decision.

Key Idea The closest PoP is not automatically the best path. Path quality depends on several network characteristics.
Latency
18 ms
Packet Loss
0.1%
Jitter
3 ms
Status
Optimal
Latency The time required for traffic to travel between endpoints. Higher latency can directly affect interactive applications.
Packet Loss Lost packets can cause retransmissions and reduce application efficiency even when plenty of bandwidth remains available.
Jitter Variation in packet arrival time matters particularly for real-time applications such as voice and video.

SASE Definition

SASE Definition with Challenge 1: Managing the Network

Across the entire networking and security industry, everyone sells individual point solutions that are not a holistic joined-up offering. Thinking only about MPLS replacement leads to incremental point solution acquisitions when confronted by digital initiatives, making networks more complex and costly.

Principally, distributed appliances for network and security at every location require additional tasks such as installation, ongoing management, regular updates, and refreshes. This results in far too many security and network configuration points. We see this all the time with NOC and SOC integration efforts.

A: Numerous integration points:

The point-solution approach addresses one issue and requires considerable integration. Therefore, you must constantly add solutions to the stack, likely resulting in management overhead and increased complexity. Let’s say you are searching for a new car. Would you prefer to build the car with all the different parts or buy the already-built one?

In the same way, if we examine the network and security industry, the way it has been geared up presently is provided in parts. It’s your job to support, manage, and build the stack over time and scale it when needed. Fundamentally, it would help if you were an expert in all the different parts. However, if you abstract complexity into one platform, you don’t need to be an expert in everything. SASE is one effective way to abstract management and operational complexity.

B: Required: How SASE solves this

Converging network and security into a single platform does not require multiple integration points. This will eliminate the need to deploy these point solutions and the complexities of managing each. Essentially, with SASE, we can bring each point solution’s functionalities together and place them under one hood—the SASE cloud. SASE merges all of the networking and security capabilities into a single platform.

This way, you now have a holistic joined-up offering. Customers don’t need to perform upgrades or size and scale their network. Instead, all this is done for them in the SASE cloud, creating a fully managed and self-healing architecture. Besides, the convergence is minimal if something goes wrong in one of the SASE Pops. All of this is automatic, and there is no need to set up new tunnels or have administrators step in to perform configurations.

SASE Definition with Challenge 2: Site Connectivity

SD-WAN appliances require other solutions for global connectivity and to connect, secure, and manage mobile users and cloud resources. As a result, many users are turning to Service Providers to handle the integration. The carrier-managed SD-WAN providers integrate a mix of SD-WAN and security devices to form SD-WAN services.

A: Lack of Agility

Unfortunately, this often makes the Service Providers inflexible in accommodating new requests. The telco’s lack of agility and high bandwidth costs will remain problematic. Deploying new locations has been the biggest telco-related frustration, especially when connecting offices outside of the telco’s operating region to the company’s MPLS network. For this, they need to integrate with other telcos.

B: Required: How SASE solves this

SASE handles all of the complexities of management. As a result, the administrative overhead for managing and operating a global network that supports site-to-site connectivity and enhanced security, cloud, and mobility is kept to an absolute minimum.

SASE Definition with Challenge 3: Performance Between Locations

The throughput is primarily determined by latency and packet loss, not bandwidth. Therefore, for an optimal experience for global applications, we must explore ways to manage the latency and packet loss end-to-end for last-mile and middle-mile segments. Most SD-WAN vendors don’t control these segments, affecting application performance and service agility.

Consequently, constant tweaking at the remote ends will be required to attain the best performance for your application. With SD-WAN, we can bundle transports and perform link bonding to solve the last mile. However, this does not create any benefits for the middle mile bandwidth. MPLS will help you overcome the middle-mile problems, but you will likely pay a high price.

A: Required: How SASE solves this

The SASE cloud already has an optimized converged network and security platforms. Therefore, sites need to connect to the nearest SASE PoP. This way, the sites are placed on the global private backbone to take advantage of global route optimization, dynamic path selection, traffic optimization, and end-to-end encryption. The traffic can also be routed over MPLS, directly between sites (not through the SASE PoP), and from IPsec tunnels to third-party devices. The SASE architecture optimizes the last and middle-mile traffic flows.

B: Required: Optimization techniques:

The SASE global backbone uses several techniques to improve network performance, resulting in predictable, consistent latency and packet loss. The SASE cloud has complete control of each PoP and can employ optimizations. It uses proprietary routing algorithms that factor in latency, packet loss, and jitter. These routing algorithms favor performance over cost and select the optimal route for every network packet. This is compared to Internet routing, where metrics don’t consider what is best for the application or the type.

Example TCP Performance Parameters.

SASE Definition with Challenge 4: Cloud Agility

Cloud applications are becoming more critical to organizations, even more so than those hosted in private data centers. When delivering cloud resources, we must consider more than just providing connectivity. In the past, when we spoke about agility, we were concerned only with the addition of new on-premises sites.

However, now, this conversation needs to encompass the cloud. Delivering cloud applications is primarily about providing an application experience that is as responsive as on-premises. However, most SD-WANs have a low response rate for rapidly offering new public cloud infrastructure. MPLS is expensive, rigid, and not built for cloud access.

A: Required: How SASE solves this

SASE natively supports cloud data centers (IaaS) and applications (SaaS) without additional configuration, complexity, or point solutions, enabling built-in cloud connectivity. This further allows the rapid delivery of new public cloud infrastructure.

The SASE PoPs are collocated in the data centers and directly connected to the IXP of the leading IaaS providers, such as Amazon AWS, Microsoft Azure, and Google Cloud Platform. In addition, cloud applications are optimized through SASE’s ability to define the egress points.

This helps exit the cloud application traffic at the points closest to the customer’s application instance. The optimal global routing algorithms can determine the best path from anywhere to the customer’s cloud application instance. This provides optimal performance to the cloud applications regardless of the user’s location.

So, when we talk about performance to the cloud with SASE, the latency to the cloud is comparable to the optimized access provided by the cloud providers, such as AWS Direct Connect or Azure Express Route. So, authentically, SASE provides out-of-the-box cloud performance.

SASE Definition with Challenge 5: Security

The security landscape is constantly evolving. Therefore, network security solutions must develop to form a well-founded landscape. Ransomware and Malware will continue to be the primary security concerns from 2020 onward. Combating the various solutions designed with complex integration points scattered throughout the network domain is challenging for the entire organization.

Security must be part of any WAN transformation initiative. It must protect users and resources regardless of the underlying network, managed through a single-pane-of-glass. However, a bundle of non-integrated security products results in appliance sprawl that hinders your security posture instead of strengthening it. The security solution must defend against emerging threats like malware and ransomware. In addition, it must boost the ability to enforce corporate security policies on mobile users.

Finally, the security solution must also address the increasing cost of buying and managing security appliances and software.

**Security and encryption**

The complexity increases due to the disparate tools required to address the different threat vectors. For example, we have DLP that can be spread across the SWG, CASB, and DLP but with three other teams managing each. What about the impact of encrypted web traffic on the security infrastructure?

The issue is that most internet traffic is now encrypted, and attackers deliver the payloads, deliver command and control instructions, and exfiltrate data over encrypted protocols. Organizations cannot decrypt all network traffic for performance reasons and avoid looking at sensitive employee information. Also, there are issues with the scalability of encrypted traffic management solutions, which can also cause performance issues.

Example Technology: Sensitive Data Protection

Sensitive data protection

Example Technology: Security Backdoors

Backdoor access refers to a hidden method or vulnerability intentionally created within a system or software that allows unauthorized access or control. It is an alternative entry point that bypasses conventional security measures, often undetected.

Using Bash: Bash, short for “Bourne Again SHell,” is a widely used command-line interpreter in Unix-based systems. It provides powerful scripting capabilities, making it a favorite among system administrators and developers. However, this versatility also brings the potential for misuse. This section will explain what a Bash backdoor is and how it functions.

Note: In the following, I created a backdoor on a corporate machine to maintain persistence within the environment. I performed bash script and system configuration using cron jobs. You will then connect to the created backdoor. Here, we demonstrate how to use tools available on standard operating system installations to bypass an organization’s security controls.

Cron jobs, derived from the word “chronos,” meaning time in Greek, are scheduled tasks that run automatically in the background of your server. They follow a specific syntax, using fields to specify when and how often a task should be executed. You can create precise and reliable automated processes by grasping the structure and components of cron jobs.


First, the file called file is deleted with the rm command if it already exists. Next, a special pipe, a new communications channel, is called a file. Any information passed to the bash terminal, such as typed commands, is transmitted to a specific IP address and port using the pipe. The | indicates the point at which the output from one Linux command passes information to the following command. You can create a network connection to a specific machine using this single line, giving a user remote access.

First, errors when running the cron task are ignored and not printed on the screen. Then, the new cronjob is printed to the screen; in this example, the backdoor bash shell will run every minute. The output of the echoed command is then written to the cronfile with crontab. 

SASE Definition with Challenge 6: MPLS and SD-WAN

MPLS does not protect resources and users, certainly not those connected to the Internet. On the other hand, SD-WAN service offerings are not all created equal since many do not include firewall/security features for threat protection to protect all edges—mobile devices, sites, and cloud resources. This lack of integrated security complicates SD-WAN deployments and often leads to Malware getting past the perimeter unnoticed.

Challenge: The cost involved

Security solutions are expensive, and there is never a fixed price. Some security vendors may charge for usage models for which you don’t yet have the quantity. This makes the planning process extraordinarily problematic and complex. As the costs keep increasing, security professionals often trade off point-security solutions due to the associated costs. This is not an effective risk-management strategy.

The security controls are also limited to mobile VPN solutions. More often than not, they are very coarse, forcing IT to open access to all the network resources. Protecting mobile users requires additional security tools like next-generation firewalls (NGFWs), so we have another point solution. In addition, mobile VPN solutions provide no last—or middle-mile optimization.

SASE Meaning: How SASE solves this

SASE converges a complete security stack into the network, allowing it to bring granular control to sites and mobile and cloud resources by enforcing the zero-trust principles for all edges. SASE provides anti-malware protection for both WAN and Internet traffic. In addition, for malware detection and prevention, SASE can offer signature and machine-based learning protection consisting of several integrated anti-malware engines.

For malware communication, SASE can stop the outbound traffic to C&C servers based on reputation feeds and network behavioral analysis. Mobile user traffic is fully protected by SASE’s advanced security services, including NGFW, secure web gateway (SWG), threat prevention, and managed threat detection and response. Furthermore, in the case of mobile, SASE mobile users can dynamically connect to the closest SASE PoP regardless of the location. Again, as discussed previously, the SASE cloud’s relevant optimizations are available for mobile users.

Rethink the WAN: The shift to the cloud, edge computing, and mobility offers new opportunities for IT professionals. Network professionals must rethink their WAN transformation approach to support these digital initiatives. WAN transformation is not just about replacing MPLS with SD-WAN. An all-encompassing solution is needed that provides the proper network performance and security level for enhanced site-to-site connectivity, security, mobile, and cloud.

Example Product: Cisco Umbrella

### What is Cisco Umbrella?

Cisco Umbrella acts as a first line of defense against internet-based threats by leveraging the cloud. It uses DNS (Domain Name System) to block malicious domains, IPs, and URLs before a connection can be established. By analyzing and learning from internet activity patterns, it can predict and prevent potential threats, ensuring that your network remains secure.

### Key Features of Cisco Umbrella

1. **DNS Layer Security**: Cisco Umbrella provides a protective shield at the DNS layer, stopping threats before they reach your network or endpoints. This means that harmful requests are blocked at the source, reducing the risk of malware infections.

2. **Secure Web Gateway**: The solution offers a secure web gateway that inspects web traffic and enforces security policies. It ensures that only safe and compliant traffic is allowed, providing an additional layer of security.

3. **Cloud-Delivered Firewall**: Cisco Umbrella includes a built-in firewall to block unwanted traffic, adding another layer of protection. This firewall can be managed from the cloud, simplifying the process of maintaining network security.

4. **Threat Intelligence**: With real-time threat intelligence updates from Cisco Talos, one of the world’s largest commercial threat intelligence teams, Cisco Umbrella ensures that your defenses are always up to date against the latest threats.

### Benefits of Using Cisco Umbrella

1. **Simplified Security Management**: Being cloud-based, Cisco Umbrella is easy to deploy and manage. There’s no need for complex hardware or software installations, reducing the burden on IT teams.

2. **Improved Visibility**: Cisco Umbrella provides comprehensive insights into internet activity across all devices and locations. This visibility helps in identifying and responding to potential threats swiftly.

3. **Enhanced User Experience**: By blocking malicious content at the DNS layer, users experience faster internet speed and reduced latency, leading to a smoother browsing experience.

4. **Scalability**: Whether you are a small business or a large enterprise, Cisco Umbrella can scale according to your needs. Its cloud-native architecture ensures that it can handle an increasing number of users and devices without compromising on performance.

Summary: SASE Definition

Secure Access Service Edge • Widget 3

SASE Security Decision Explorer

Follow a request from the user through identity and device verification, policy evaluation and security controls before the application access decision is made.
REQUEST User Alice Requests application IDENTITY Verify Identity User / role / MFA DEVICE Device Context Managed / posture POLICY ENGINE Access Decision Evaluate context against policy ALLOW ZTNA application access SWG web security CASB cloud control FWaaS firewall service RESOURCE Application SaaS / Private Resource ZERO TRUST DECISION Identity → Device Context → Policy → Security Control → Application ACCESS ALLOWED
SECURITY DECISION

Access Decision

SASE applies security controls around the user and application rather than assuming that network location automatically means trust.

Key Idea Verify the user, evaluate the device and context, apply policy, then enforce the appropriate access decision.
Current Decision
ALLOW
1. Verify Identity and device context are evaluated before access is granted. Authentication alone does not automatically establish trust.
2. Apply Policy Policy can consider identity, device posture, application, location and other contextual information.
3. Enforce ZTNA, SWG, CASB and FWaaS can provide the appropriate security enforcement for the requested application or traffic.

With the ever-evolving landscape of technology and the increasing demand for secure and efficient networks, a new paradigm has emerged in the realm of network security – SASE, which stands for Secure Access Service Edge. In this blog post, we delved into the definition of SASE, its key components, and its transformative impact on network security.

Understanding SASE

SASE, pronounced “sassy,” is a comprehensive framework that combines network security and wide area networking (WAN) capabilities into a single cloud-based service model. It aims to provide users with secure access to applications and data, regardless of their location or the devices they use. By converging networking and security functions, SASE simplifies the network architecture and enhances overall performance.

The Key Components of SASE

To fully grasp the essence of SASE, it is essential to explore its core components. These include:

1. Secure Web Gateway (SWG): The SWG component of SASE ensures safe web browsing by inspecting and filtering web traffic, protecting users from malicious websites, and enforcing internet usage policies.

2. Cloud Access Security Broker (CASB): CASB provides visibility and control over data as it moves between the organization’s network and multiple cloud platforms. It safeguards against cloud-specific threats and helps enforce data loss prevention policies.

3. Firewall-as-a-Service (FWaaS): FWaaS offers scalable and flexible firewall protection, eliminating the need for traditional hardware-based firewalls. It enforces security policies and controls access to applications and data, regardless of their location.

4. Zero Trust Network Access (ZTNA): ZTNA ensures that users and devices are continuously authenticated and authorized before accessing resources. It replaces traditional VPNs with more granular and context-aware access policies, reducing the risk of unauthorized access.

The Benefits of SASE

SASE brings numerous advantages to organizations seeking enhanced network security and performance:

1. Simplified Architecture: By consolidating various network and security functions, SASE eliminates the need for multiple-point solutions, reducing complexity and management overhead.

2. Enhanced Security: With its comprehensive approach, SASE provides robust protection against emerging threats, ensuring data confidentiality and integrity across the network.

3. Improved User Experience: SASE enables secure access to applications and data from any location, offering a seamless user experience without compromising security.

Conclusion:

In conclusion, SASE represents a paradigm shift in network security, revolutionizing how organizations approach their network architecture. By converging security and networking functions, SASE provides a comprehensive and scalable solution that addresses the evolving challenges of today’s digital landscape. Embracing SASE empowers organizations to navigate the complexities of network security and embrace a future-ready approach.