Premium Blog Scenario11.001

BGP Solutions and Insights

Interactive BGP Learning Environment

BGP is often introduced as the protocol used to exchange routing information between Autonomous Systems. While that definition is correct, understanding BGP properly requires looking beyond the protocol itself and understanding the networks, routing domains, policies, and forwarding infrastructure in which it operates.

The Internet is a network of independently operated Autonomous Systems, each with its own infrastructure, addressing, routing policies, and operational requirements. BGP provides the interdomain routing mechanism that allows these networks to exchange reachability information and apply policy when determining which routes to accept, prefer, and advertise.

The interactive components in this section build that understanding progressively.

The Internet: A Network of Networks establishes the foundation by introducing Autonomous Systems, ASNs, interconnection, and the role of BGP in exchanging reachability between independently operated routing domains. The objective is to understand why an interdomain routing protocol is required when no single organisation controls the entire Internet.

Inside an Autonomous System then moves inside an individual routing domain. An Autonomous System can contain many routers, links, and routing functions. The section shows how eBGP connects different Autonomous Systems, how iBGP distributes BGP information within an AS, and how an IGP provides the internal reachability required to reach routers and BGP next hops.

How BGP Routes Move Through the Network follows the routing information itself. A prefix can be originated, advertised in a BGP UPDATE, received by another BGP speaker, and propagated according to BGP rules and local routing policy. As the route crosses AS boundaries, attributes such as AS_PATH provide information about the route’s interdomain propagation, while other attributes influence how the route is evaluated and advertised.

How BGP Selects a Path brings these concepts together. A BGP speaker can learn multiple routes to the same destination and must evaluate those candidates using its configured decision process. Attributes such as LOCAL_PREF, AS_PATH, ORIGIN, MED, and platform-specific attributes such as Cisco Weight can influence the selection.NEXT_HOP and other attributes also contribute to route resolution and forwarding, while communities are commonly used to carry policy information between BGP speakers.

Together, these interactive components establish a visual foundation for understanding BGP:

The network → The Autonomous System → Route movement → Path selection

The goal is not to reproduce every detail of a production BGP implementation. Instead, the visualisations make the relationships between networks, BGP speakers, routing information, policy, path attributes, and forwarding easier to understand. This provides the foundation for the more detailed protocol concepts, configuration examples, and hands-on BGP labs that follow.

ENGINEERING GUIDE · BGP

Interactive BGP Learning Environment

Understanding BGP requires more than knowing its commands or memorising the best-path sequence. BGP operates across interconnected Autonomous Systems, exchanges reachability information, applies routing policy and ultimately influences how traffic is forwarded through the network.

!
Engineering Observation The most useful way to understand BGP is to follow the relationship between the network, the route, the policy and the forwarding decision — and then use the simulator to investigate what actually happens.
01 · NETWORK

The Internet

Understand why the Internet is a collection of independently operated Autonomous Systems and why BGP is required between them.

02 · ARCHITECTURE

Inside the AS

See how IGP, iBGP and eBGP divide the work of internal reachability, route distribution and interdomain connectivity.

03 · PROPAGATION

Route Movement

Follow a prefix through BGP UPDATEs, route reception, policy processing, propagation and route installation.

04 · DECISION

Best Path

Examine how multiple valid candidates are compared using policy and BGP path attributes to determine the preferred route.

BGP Learning Model
AUTONOMOUS SYSTEMS
→
BGP UPDATE
→
ROUTE PROPAGATION
→
PATH SELECTION
→
FORWARDING
Engineering View

BGP is a control-plane decision system that determines how reachability information is learned, evaluated and propagated.

Prefixes UPDATEs Policy Attributes RIB FIB
BGP PREMIUM GUIDE

BGP Learning Path

Start with the structure of the Internet, move inside an Autonomous System, follow how BGP routes propagate, and finish with the logic behind best-path selection.

FOUNDATION ARCHITECTURE PROPAGATION DECISION
☕
Support Network Insight
Help support the development of interactive networking labs, BGP simulations, and educational content.
Support the Project
Interactive BGP Lab

Take the BGP Concepts Into the Lab

Reading explains how BGP works. The simulator lets you observe the routing system as it operates. Explore BGP sessions, route propagation, attributes, best-path decisions and network behaviour through an interactive engineering environment.

01 Understand Build the conceptual model from the BGP architecture and routing principles explained in this article.
02 Investigate Open the simulator and inspect routers, BGP sessions, routes, attributes and protocol state.
03 Experiment Change the network conditions and observe how BGP propagation and path selection respond.
BGP Core Simulator

Move from theory to hands-on BGP engineering. Explore the control plane, routing decisions and protocol behaviour in an interactive environment.

🚀 LAUNCH BGP SIMULATOR
Opens the BGP Core Simulator in a new browser tab.
BGP CONTROL PLANE REFERENCE

How the BGP Control Plane Fits Together

Explore the major components involved when BGP receives routing information, evaluates candidate paths, selects a best route, and programs forwarding.
Interactive Reference
P
BGP Peers
Neighbors establish sessions and exchange routing information.
BGP
BGP Control Plane
Receives routing information, applies policy, maintains candidate paths and selects routes.
U
BGP UPDATE
Carries NLRI, path attributes and withdrawals.
A
Path Attributes
Weight, Local Preference, AS Path, MED, Communities and more.
✓
Best Path
Candidate routes are compared using the BGP decision process.
R
RIB / FIB
The selected route is installed for forwarding.
Selected Component
BGP Control Plane
The BGP control plane receives routing information, applies routing policy, maintains candidate paths and runs the best-path decision process.
Interactive component
Control-plane relationship
Click any component to explore

The Internet: A Network of Networks

FOUNDATION · THE INTERNET
The Internet Is a Network of Networks
BGP exists because the Internet is made up of many independently operated networks. These networks must exchange reachability information without giving up control of their own infrastructure or routing policy.
BGP
FOUNDATION
AS
01 · NETWORKS
Autonomous Systems
Independent routing domains operate their own infrastructure, addressing and routing policies.
→
BGP
02 · CONTROL PLANE
Reachability
BGP exchanges IP prefix information between BGP speakers and applies policy to the routes being learned and advertised.
→
RIB
03 · ROUTING
Route Selection
Each BGP speaker evaluates the routes it knows and selects a preferred path according to its policy and decision process.
→
FIB
04 · DATA PLANE
Traffic Forwarding
The selected route can be installed for forwarding so packets can reach their destination through the network.
KEY IDEA
BGP does not create the Internet. It provides the interdomain routing mechanism that allows independently operated networks to exchange reachability, apply routing policy, and make their own path-selection decisions.
IN THIS SECTION
AS Autonomous Systems BGP Interdomain Routing ROUTES Reachability TRAFFIC Forwarding
Network Insight · BGP Engineering Use Case

Investigating Internet Reachability

Start from the enterprise router and investigate how BGP provides reachability to networks located in other Autonomous Systems. Use the simulated CLI to inspect neighbours, routes and routing state.

Internet Connectivity
AS Relationships
ISP-A AS 65001 Established
ISP-B AS 65002 Established
ISP-C AS 65003 Established
Enterprise R1 AS 65010 3 BGP Neighbours
Remote Network AS 65020 10.10.10.0/24
BGP Relationship
Established
Enterprise Router CLI
Simulated
R1#
show ip bgp summary
BGP router identifier 10.255.255.1 Local AS number 65010 Neighbor AS State/PfxRcd 192.0.2.1 65001 Established 192.0.2.2 65002 Established 192.0.2.3 65003 Established

What You See

R1 has three established external BGP sessions, each connecting the enterprise to a different Autonomous System.

What It Means

BGP allows independently operated networks to exchange reachability information across AS boundaries.

Engineering Principle

The Internet is a network of independently operated Autonomous Systems connected through routing relationships.

FOUNDATION · THE INTERNET

The Internet Is a Network of Networks

BGP exists because the Internet is not one centrally operated network. It is a collection of independently managed Autonomous Systems that connect to one another and exchange reachability information.

Internet Architecture · Independent Routing Domains
AS 65001 Provider Internet connectivity and external reachability
AS 65002 Transit Provides connectivity between other networks
AS 65010 Enterprise Owns internal infrastructure and routing policy
AS 65020 Cloud Hosts services and advertises reachable prefixes
BGP
Interdomain REACHABILITY
01 · Independence Each AS operates its own network

Infrastructure, addressing, routing policy and operational decisions remain under the control of the organisation operating the AS.

02 · Interconnection Networks establish routing relationships

BGP speakers exchange reachability information across AS boundaries so destinations can become reachable through neighbouring networks.

03 · Reachability Prefixes describe destinations

BGP advertises IP prefixes and associated path information rather than carrying the user packets themselves.

04 · Policy Each AS makes its own decisions

Networks can decide which routes to accept, prefer and advertise according to their own routing policies.

B
BGP · Control Plane

BGP exchanges reachability information between BGP speakers and provides the information used to evaluate and select routes.

→
Forwarding · Data Plane

Once routing information has been selected and resolved, the forwarding plane uses the resulting information to move packets toward their destinations.

!
Engineering Principle BGP does not create a single global routing authority. It allows independently operated Autonomous Systems to exchange reachability information while retaining control over their own routing policy.

The Internet is a vast “network of networks” — a global system of independently operated networks, including Internet service providers, enterprises, cloud providers, universities, and government organisations. These networks interconnect using shared protocols and standards, with BGP providing the primary mechanism for exchanging reachability information between Autonomous Systems. Each network manages its own infrastructure, routing policies, and operational requirements while participating in a larger, interconnected system.

Each Autonomous System contributes to the global routing system by originating or advertising IP prefixes that it is authorised to announce, while learning reachability to prefixes available through other networks. BGP allows these independently administered networks to exchange this information without requiring a central routing authority. As routes are learned and withdrawn, each network applies its own policies to determine which paths it will accept, prefer, and advertise to its neighbours.

This distributed model is fundamental to the resilience of the Internet. A network can have multiple connections to different providers or neighbouring Autonomous Systems, allowing alternative routes to exist when a link or routing path becomes unavailable. When a route is withdrawn or a topology changes, BGP can propagate the new reachability information so that affected networks can recalculate their available paths. The result is not a single global routing table controlled by one organisation, but a collection of interconnected routing domains making independent decisions based on shared protocols and local policy.

Because the Internet is composed of many independently operated networks, its topology and routing behaviour are constantly evolving. Links are added and removed, policies change, prefixes are originated or withdrawn, and business relationships influence how routes are exchanged. BGP provides the interdomain framework that allows these changes to propagate across the network while preserving the autonomy of each participating organisation.

Understanding this structure is essential to understanding BGP. Before examining how BGP selects between competing routes, it is important to understand what exists inside the Autonomous Systems that originate, receive, and propagate those routes.

NETWORK INSIGHT · BGP SERIES

How the Internet Connects

Before understanding BGP, understand the network it was designed for: an Internet made from thousands of independently operated Autonomous Systems that exchange reachability and carry traffic between one another.

Internet Topology
CONTROL + DATA PLANE
Data traffic
BGP control plane
Active scenario
Internet Traffic Journey
Step 0 / 7
READY

Follow traffic across the Internet

Run the scenario to see how traffic moves between independently operated networks and where BGP fits into the process.

Selected Object

The Internet

The Internet is not one network. It is a collection of independently operated networks interconnected using common protocols.

Key Concepts

Inside an Autonomous System

ARCHITECTURE · INSIDE THE AS
What Exists Inside an Autonomous System?
An Autonomous System is not a single router. It is a collection of routers, links and routing functions operating under a common administrative and routing-policy framework.
AS
ARCHITECTURE
IGP
01 · INTERNAL REACHABILITY
IGP
OSPF, IS-IS and other IGPs provide internal reachability between routers and help resolve BGP next hops.
iBGP
02 · BGP INFORMATION
iBGP
iBGP distributes BGP reachability information between BGP speakers inside the same Autonomous System.
eBGP
03 · AS BOUNDARY
eBGP
eBGP exchanges reachability information between neighbouring Autonomous Systems.
FIB
04 · DATA PLANE
Forwarding
Once a route is selected and resolved, the forwarding plane uses the resulting information to move packets.
IMPORTANT DISTINCTION
BGP and the IGP perform different jobs. BGP determines which routes are preferred and distributes BGP reachability information. The IGP provides the internal IP reachability required to reach BGP next hops. The forwarding plane then moves the actual packet.
INSIDE AN AS
IGP Internal Reachability iBGP BGP Information eBGP AS Connectivity FIB Packet Forwarding
Network Insight · BGP Engineering Use Case

Inside an Autonomous System

BGP does not operate alone inside an enterprise network. Use this interactive view to see how eBGP, iBGP and the IGP work together to move routing information from an external network toward the routers that ultimately forward traffic.

Inside AS 65010
Control Plane
Autonomous System 65010
R1 AS 65010 Internal
R2 AS 65010 Core Router
R3 AS 65010 BGP Edge
ISP AS 65001 eBGP
Remote Prefix 10.10.10.0/24 External
eBGP
iBGP
IGP
Router Investigation
Simulated
R3#
show ip bgp summary
BGP router identifier 10.255.255.3 Local AS number 65010 Neighbor AS Relationship 10.255.255.1 65010 iBGP 10.255.255.2 65010 iBGP 192.0.2.1 65001 eBGP BGP state: Established

What You See

R3 has both an external eBGP relationship and internal routing relationships within AS 65010.

What It Means

BGP exchanges external reachability while the IGP provides the internal reachability required to reach BGP next hops.

Engineering Principle

eBGP connects Autonomous Systems, iBGP distributes BGP information within an AS, and the IGP provides internal IP reachability.

ARCHITECTURE · AUTONOMOUS SYSTEM

Inside an Autonomous System

An Autonomous System does not use BGP for every routing function. Internal reachability, external route exchange, path selection and packet forwarding are separate engineering functions that work together.

Inside the AS
IGP Provides internal reachability between routers and establishes the paths used to reach next-hop addresses.
Internal Routers Maintain routing information and provide connectivity across the Autonomous System.
CONTROL PLANE
BGP

BGP carries interdomain reachability information and applies routing policy to determine which available path should be used.

eBGP → RIB → Best Path → FIB
AS Boundary
eBGP Exchanges reachability information with routers belonging to another Autonomous System.
External Prefixes Routes learned from other ASs become candidates for local policy and best-path selection.
01
IGP

Answers the internal reachability question: How do I reach the next hop?

02
iBGP

Distributes BGP reachability information between routers inside the same Autonomous System.

03
eBGP

Exchanges routing information across an Autonomous System boundary.

04
FIB

Converts the selected routing decision into forwarding information used by the data plane.

Engineering Principle

BGP is the control-plane decision system, not the forwarding mechanism. The routing process selects a path; the FIB is then programmed so packets can actually follow that decision.

Inside an Autonomous System (AS), routers operate within a common administrative and routing-policy domain. The AS controls its internal topology, addressing, and routing decisions, allowing operators to engineer traffic, provide redundancy, and manage connectivity according to their own operational requirements. An AS may contain anything from a small collection of routers to thousands of devices spanning multiple regions, data centres, and network segments.

Internal routing is typically provided by an Interior Gateway Protocol (IGP) such as OSPF or IS-IS in service-provider environments, with protocols such as EIGRP also used in some enterprise networks. The IGP is responsible for providing reachability within the AS, while BGP handles the exchange of interdomain and, where required, internal BGP routing information. This distinction is important: BGP determines which route is preferred, while the IGP can provide the underlying reachability needed to reach the BGP next hop.

Because the routers within an AS are operated under a common administrative framework, the network can be engineered around its own requirements. Operators can use IGP metrics, areas or levels, summarisation, routing policy, redundancy mechanisms, and traffic-engineering techniques to influence how traffic moves through the network. The objective may be rapid convergence, efficient use of links, predictable forwarding, geographic resilience, or isolation of particular services and workloads.

The internal architecture of an AS varies considerably depending on its purpose and scale. Some networks use traditional core, distribution, and access layers, while others use provider backbones, regional architectures, data-centre fabrics, MPLS-based networks, or overlay technologies. These different designs can coexist within the same Autonomous System, with different routing protocols and mechanisms serving different roles.

From outside the AS, however, the internal topology is generally abstracted. External BGP peers do not normally need visibility into the AS’s complete internal IGP structure. Instead, the AS presents its external neighbours with BGP reachability information and applies its own policies to determine which routes are accepted, preferred, and advertised.

This separation between internal reachability and external routing policy is fundamental to understanding BGP. eBGP connects an AS to neighbouring Autonomous Systems, iBGP distributes BGP information within the AS, and the IGP provides the internal reachability required to support the resulting forwarding decisions.

BGP ARCHITECTURE

Inside an Autonomous System

An autonomous system is not a single router. It is a collection of routers and links working together. IGP provides internal reachability, iBGP distributes BGP information, and eBGP connects the AS to other networks.

Inside AS 65001
Click a router or link to inspect it
AS
AS64500
External AS
R1
R1
Edge
R2
R2
Core
R3
R3
Core
R4
R4
Edge
AS
AS64510
External AS
ARCHITECTURE VIEW

One AS, multiple routing roles

An autonomous system contains multiple routers. Different routing functions operate across those routers: IGP maintains internal reachability, iBGP distributes BGP information, and eBGP connects the AS to neighbouring autonomous systems.

What to notice
The purple links represent the internal routing domain. The cyan dashed links represent iBGP sessions. Orange links mark the boundaries where this AS communicates with another AS.
IGP
Internal reachability
iBGP
BGP information
eBGP
AS boundary

How BGP Routes Move Through the Network

ROUTING · BGP PROPAGATION
How Does a BGP Route Move Through the Network?
A BGP route does not simply appear everywhere at once. It is originated by a router, carried inside BGP UPDATE messages, propagated according to policy, evaluated by receiving routers, and eventually installed into the forwarding plane.
ROUTE
LIFECYCLE
NLRI
01 · ROUTE ORIGINATION
A Prefix Is Introduced
A router originates or learns a prefix and creates BGP reachability information for that destination.
UPDATE
02 · BGP UPDATE
Reachability Is Advertised
The router sends a BGP UPDATE containing the prefix and its associated path attributes to a neighbour.
PATH
03 · PROPAGATION
The Route Travels
Other BGP speakers receive the route and may advertise it onward, subject to BGP rules and routing policy.
RIB
04 · ROUTE EVALUATION
Paths Are Compared
A router evaluates available paths using BGP attributes such as Local Preference, AS_PATH, MED and other criteria.
FIB
05 · FORWARDING
The Selected Route Is Used
Once the best path is selected and the next hop is resolved, the resulting route can be installed for forwarding.
IMPORTANT DISTINCTION
BGP carries reachability information — not the user packet. BGP UPDATE messages distribute routing information through the control plane. The forwarding plane uses the resulting routing information to determine where actual packets should go.
ROUTE LIFECYCLE
NLRI Prefix UPDATE Advertisement PATH Propagation RIB Selection FIB Forwarding
Network Insight · BGP Engineering Use Case

Tracing a BGP Route Through the Network

Follow a BGP route from the moment an UPDATE is received through NLRI processing, RIB-IN, policy and routing state. The objective is to understand how BGP processes reachability information before the forwarding plane can use it.

BGP Route Lifecycle
Control Plane
Route Destination
10.10.10.0/24
Follow the route as routing information moves through the BGP control plane.
01
UPDATE
BGP message received
02
NLRI
Prefix identified
03
RIB-IN
Candidate route stored
04
POLICY
Import policy evaluated
05
RIB / FIB
Routing state installed
BGP Route Processing
NLRI 10.10.10.0/24
NEXT HOP 192.0.2.1
AS PATH 65001 65020
Route Investigation CLI
Simulated
R1#
show bgp update received
BGP UPDATE received NLRI 10.10.10.0/24 NEXT_HOP 192.0.2.1 AS_PATH 65001 65020 ORIGIN IGP Status: UPDATE RECEIVED

What You See

The router has received a BGP UPDATE containing reachability information for 10.10.10.0/24.

What It Means

The UPDATE is control-plane information. It describes how the router can reach a destination prefix.

Engineering Principle

A BGP route is processed by the control plane before the resulting routing information can be used for forwarding.

PROPAGATION · BGP ROUTE LIFECYCLE

How a BGP Route Moves Through the Network

A BGP route is not simply “sent” from one router to another. Reachability information is advertised, received, evaluated, stored and ultimately converted into a forwarding decision.

01
NLRI

A network prefix represents a reachable destination.

02
UPDATE

BGP advertises the prefix together with path attributes.

03
RIB-IN

The receiving router stores routes learned from its BGP peers.

04
BEST PATH

Policy and BGP attributes determine which candidate wins.

05
FIB

The selected route becomes forwarding information for packets.

Example NLRI
10.10.10.0/24 Reachable destination prefix
BGP UPDATE · Path Information
AS_PATH Path through autonomous systems
NEXT_HOP Next-hop information
LOCAL_PREF Local routing preference
MED Multi-exit discriminator
Engineering Principle

BGP carries reachability information, not user traffic. The UPDATE changes the control-plane view of the network. The resulting routing decision is then reflected in the forwarding plane through the FIB.

BGP routes are exchanged between BGP speakers and propagated according to the relationships between those speakers, their routing policies, and the rules of BGP. A route may enter an Autonomous System through an eBGP session, where the receiving router evaluates the advertisement and applies local policy before making the route available to its BGP process. The route may then be advertised to other BGP speakers within the AS using iBGP.

When a route is learned from an eBGP neighbour, its BGP attributes describe characteristics of the route and its path. Some attributes are received from the neighbour, while others may be modified or assigned through local policy before the route is advertised onward. For example, LOCAL_PREF can be set to influence the preferred exit point from the AS, while AS_PATH is modified when a route is advertised across an AS boundary. NEXT_HOP identifies the address that must be resolved to reach the destination, while MED can provide a neighbouring AS with information about a preferred entry point where the comparison is applicable.

Within an AS, iBGP can distribute BGP routes between internal speakers without adding the local AS to the AS_PATH. In common eBGP-to-iBGP propagation, the NEXT_HOP is preserved, meaning that internal routers may need the IGP to provide reachability to the BGP next hop. The IGP therefore plays a supporting role: it does not select the BGP route, but it provides the underlying IP reachability required to resolve the next hop and ultimately forward traffic.

The way routes propagate through an AS is also influenced by BGP policy and topology. Filtering can determine which routes are accepted or advertised, routing policy can modify attributes, and mechanisms such as route reflection can control how routes are distributed between iBGP speakers. As a result, not every BGP speaker necessarily receives every route, and different routers can have different sets of candidate paths from which to make their own best-path decisions.

Route reflectors are commonly used to scale iBGP deployments by reducing the number of individual peering relationships required. Rather than requiring every iBGP router to form a session with every other iBGP router, route reflectors can advertise routes between clients and other BGP speakers according to the route-reflection rules. Large networks may deploy multiple route reflectors for redundancy and operational resilience, with the design taking into account path visibility, loop prevention, policy, and convergence behaviour.

Once BGP selects a best path, that path becomes a candidate for installation into the router’s main routing table, subject to factors such as next-hop reachability, administrative preference, platform behaviour, and policy. If the route is installed, the forwarding plane can then use the resulting forwarding information to send packets toward the destination.

The key distinction is simple:

BGP determines which route is preferred. The IGP provides internal reachability to the required next hop. The forwarding plane moves the actual packet.

Understanding this separation is essential when following a BGP route from the moment it is advertised to the moment traffic is forwarded.

BGP ROUTE PROPAGATION

How BGP Routes Move Through the Network

A route begins as reachability information in one network. BGP carries that information between autonomous systems, adding context such as AS_PATH and other attributes as the advertisement moves through the Internet.

ROUTE ORIGINATION
BGP CONTROL PLANE
ORIGIN AS
BGP PROPAGATION
REMOTE AS
AS64500
ORIGIN
PREFIX
AS65001
TRANSIT
BGP SPEAKER
AS65002
TRANSIT
BGP SPEAKER
AS64510
REMOTE
LEARNED
AS_PATH
ROUTE PROPAGATION
REACHABILITY
PREFIX
10.10.0.0/16
ORIGINATED HERE
BGP UPDATE
FOLLOW THE ROUTE
STEP 1 / 4
A network originates a prefix and makes that destination available to BGP.

How BGP Selects a Path

DECISION PROCESS · BGP BEST PATH
How Does BGP Select a Path?
A BGP router can receive multiple routes to the same destination. Instead of forwarding traffic randomly, BGP evaluates the available paths through a defined decision process and selects the best path for installation and use.
BEST
PATH
RIB-IN
01 · CANDIDATE ROUTES
Multiple Paths Arrive
A router may receive several valid paths to the same prefix from different BGP neighbours.
POLICY
02 · ROUTING POLICY
Attributes Matter
Attributes such as Weight, Local Preference, AS_PATH, Origin and MED influence how available paths are evaluated.
COMPARE
03 · DECISION PROCESS
Paths Are Compared
BGP works through its decision criteria, eliminating less preferred candidates as the comparison progresses.
BEST
04 · BEST PATH
One Path Wins
The surviving candidate becomes the selected BGP best path for that destination on the router.
FIB
05 · ROUTING TABLE
Forwarding Uses It
After the route is selected and the next hop is resolved, the resulting information can be installed for forwarding.
IMPORTANT IDEA
BGP does not simply choose the shortest network path. It compares routes using BGP attributes and its decision process. A path with a longer AS_PATH, for example, can still be preferred if an earlier decision criterion gives it an advantage.
BEST-PATH MODEL
RIB-IN Candidates POLICY Attributes COMPARE Decision BEST Selected Path FIB Forwarding
Network Insight · BGP Engineering Use Case

How BGP Selects a Path

Multiple BGP routes can reach the same destination. BGP compares route attributes and applies its best-path process to determine which candidate becomes the preferred route for the destination.
BGP Best-Path Decision
Control Plane
DESTINATION  10.10.10.0/24
Path A
Candidate
LOCAL_PREF100 AS_PATH65020 65030 ORIGINIGP MED20 NEXT_HOP192.0.2.1
Path B
Candidate
LOCAL_PREF200 AS_PATH65040 65050 ORIGINIGP MED80 NEXT_HOP192.0.2.5
Path C
Candidate
LOCAL_PREF150 AS_PATH65060 ORIGINIGP MED10 NEXT_HOP192.0.2.9
Compare Attributes
SELECTED PATH: —
Best-Path Investigation CLI
Simulated
What You See
Three routes advertise reachability to the same destination. Each route carries a different set of BGP attributes.
What It Means
BGP does not simply choose the route with the shortest AS path. Earlier attributes in the decision process can eliminate a candidate before later attributes are considered.
Engineering Principle
Best-path selection is policy-driven. Local Preference can influence which exit an AS prefers before attributes such as AS Path and MED become relevant.
DECISION · BGP BEST PATH

How BGP Selects a Path

A BGP router can learn multiple paths to the same destination. The router does not simply choose the shortest physical path. It evaluates policy and path attributes in a defined decision process.

Path A
Selected
10.10.10.0/24
LOCAL_PREF 200
AS_PATH 65001 65020
MED 50
ORIGIN IGP
Path B
Candidate
10.10.10.0/24
LOCAL_PREF 150
AS_PATH 65002 65020
MED 20
ORIGIN IGP
Path C
Candidate
10.10.10.0/24
LOCAL_PREF 100
AS_PATH 65003 65020
MED 10
ORIGIN IGP
01
Policy Apply local routing policy
02
Weight Prefer higher local weight
03
Local Preference Prefer higher local preference
04
AS Path Compare path length
05
MED / Tie-breakers Continue until one path wins
WEIGHT Local router preference where supported.
LOCAL_PREF Controls preferred exit from the AS.
AS_PATH Provides path information and loop prevention.
ORIGIN Ranks how the route was originated.
MED Can influence which external entry point is preferred.
Engineering Principle

BGP chooses a path according to routing policy and attributes, not simply according to distance. This is why two routers can see the same destination and legitimately select different paths.

BGP can learn multiple routes to the same destination and must evaluate those candidate paths to determine which route it prefers. The exact decision process varies by implementation and configuration, but common BGP implementations evaluate a sequence of attributes and tie-breakers. On platforms such as Cisco IOS, for example, Weight is considered first, followed by LOCAL_PREF and other criteria in the configured best-path process.

LOCAL_PREF is commonly used to express the preferred exit point from an Autonomous System, with higher values preferred. Other attributes can then influence the decision, including locally originated routes, AS_PATH length, the BGP ORIGIN attribute, and MED where the comparison is applicable. Additional criteria can include whether the route was learned through eBGP or iBGP and the IGP cost to reach the BGP NEXT_HOP. If multiple paths remain equivalent, implementation-specific tie-breakers such as router ID may be used. Some platforms also consider factors such as route age or neighbour address during the final stages of selection.

The important point is that BGP does not simply choose the route with the shortest AS_PATH. The decision process is policy-driven, and an earlier attribute can determine the preferred route before later attributes are ever considered. A route with a longer AS_PATH can therefore be preferred over a shorter path because of LOCAL_PREF, Weight, local origination, or another earlier decision criterion.

These attributes provide operators with mechanisms for influencing routing behaviour. LOCAL_PREF can be used to select preferred exits from an AS, AS_PATH manipulation can influence how routes are perceived by neighbouring networks, and MED can provide a neighbouring AS with information about a preferred entry point when the comparison applies. Communities can also be used to communicate policy information, allowing routers to apply consistent actions to groups of routes.

The result is a distributed routing system in which each BGP speaker makes its own decisions based on the routes it has learned, the policies applied to those routes, and the capabilities and configuration of the implementation. Different routers do not necessarily select the same path because they may have different candidate routes, policies, next-hop reachability, or points of attachment to the network.

When a route changes or becomes unavailable, BGP exchanges UPDATE messages to communicate new reachability information or withdrawals. Other BGP speakers then reevaluate their available paths and policies. This process allows routing decisions to adapt to topology changes while preserving the independent policy control of each Autonomous System.

The result is a routing system designed for policy, scale, and interdomain control rather than simply selecting the shortest physical or AS-level path. That distinction is central to understanding why BGP is used to connect independently operated networks across the Internet.

NETWORK INSIGHT · BGP SERIES

How BGP Chooses a Path

A BGP router can learn more than one route to the same destination. The best-path process compares route attributes in sequence until a preferred path is selected.

Destination Prefix
10.10.10.0/24
PATH A
CANDIDATE
Next Hop 192.0.2.1
Weight 0
Local Preference 100
AS Path 65002 65010
MED 50
Learned via eBGP
PATH B
CANDIDATE
Next Hop 192.0.2.5
Weight 0
Local Preference 200
AS Path 65003 65010
MED 100
Learned via eBGP
PATH C
CANDIDATE
Next Hop 192.0.2.9
Weight 0
Local Preference 150
AS Path 65004 65010
MED 20
Learned via eBGP
BGP Decision Process
INTERACTIVE
1
Weight
Higher Weight is preferred when the platform supports this attribute.
2
Local Preference
Higher Local Preference is preferred within the AS.
3
Local Origin
Locally originated routes are preferred over routes learned from elsewhere.
4
AS Path
A shorter AS Path is preferred when earlier attributes tie.
5
MED
Lower MED is preferred when the comparison applies.
6
eBGP / iBGP
If routes remain tied, additional BGP decision criteria are considered.
7
Final Tie-Breakers
Router ID and other final criteria can resolve a remaining tie.
READY

Compare the candidate routes

BGP does not simply choose the route with the shortest AS Path. It evaluates attributes in sequence.

Current Result
No route selected

Bringing the BGP Picture Together

BGP becomes much easier to understand when the individual pieces are viewed as parts of one complete routing system.

The Internet is a network of independently operated Autonomous Systems, and BGP provides the interdomain routing mechanism that allows those networks to exchange reachability information. Inside an Autonomous System, different routing functions work together: the IGP provides internal reachability, iBGP distributes BGP information between internal BGP speakers, eBGP exchanges routes between Autonomous Systems, and the forwarding plane ultimately moves the packets.

From there, a BGP route follows a lifecycle. A prefix is originated or learned, advertised through BGP UPDATE messages, propagated according to routing rules and policy, and stored as routing information on receiving routers. When multiple paths are available, BGP evaluates their attributes and applies its decision process to determine which path becomes the best path.

That distinction between route information and actual traffic is fundamental. BGP operates primarily in the control plane. It determines which reachability information should be preferred; the resulting routing information is then used by the forwarding plane to determine where packets should go.

The most important lesson is therefore not to think of BGP as simply finding the shortest path. BGP is a policy-driven path-selection system. Attributes such as Weight, Local Preference, AS_PATH, Origin and MED can influence the decision, while the surrounding topology, routing policy and internal reachability determine how those routes can actually be used.

Once these relationships are understood, BGP stops looking like a collection of individual commands and starts to become a coherent system:

Autonomous Systems → BGP Updates → Route Propagation → Path Selection → Forwarding

The interactive environments throughout this article are designed to make those relationships visible. Rather than only reading about BGP, you can observe the routing process, follow routes through the network, inspect path attributes and see how changing a routing decision affects the resulting path.

BGP QUICK REFERENCE

BGP Best-Path Cheat Sheet

The key BGP attributes to remember when comparing multiple routes to the same destination.

CONTROL PLANE REFERENCE
Simplified decision flow
Weight → Local Preference → Local Origin → AS Path → Origin → MED → eBGP / iBGP → Tie-breakers
Attribute What it controls Rule Remember
1 Weight Preference on the local router Higher wins Cisco-specific
2 Local Preference Preferred exit point from the AS Higher wins Shared inside the AS
3 Local Origin Whether the route was originated locally Preferred Local route generation
4 AS Path Number of AS hops in the path Shorter wins Inter-AS path length
5 Origin How the route entered BGP IGP preferred IGP < EGP < Incomplete
6 MED Suggested entry point into an AS Lower wins Usually compared within the same neighboring AS
7 eBGP vs iBGP External versus internal path eBGP preferred Platform-dependent sequence
8 Tie-breakers Resolve routes still tied Platform-specific Router ID and other criteria
The important idea

BGP does not simply choose the shortest network path. It evaluates route attributes in sequence. Once an earlier attribute produces a clear winner, later attributes may never be considered.

For the labs

The interactive labs below let you change these attributes and observe how the selected BGP route changes in the control plane.

PUT BGP INTO PRACTICE

You've Seen How BGP Works.
Now Explore It Yourself.

You have followed the journey from Autonomous Systems and BGP route propagation through to the best-path decision process. Now take those concepts into an interactive environment and see what happens when the routing conditions change.

01 · EXPLORE Follow the routing process Explore BGP sessions, routes, attributes and topology inside the interactive environment.
02 · EXPERIMENT Change the conditions Alter routing attributes and observe how the BGP decision process responds.
03 · UNDERSTAND See the result Connect the theory from this article with the actual routing information produced by the simulator.
BGP Core Simulator

Build, inspect and experiment with BGP routing behaviour in the interactive simulator.

🚀 LAUNCH BGP CORE SIMULATOR
CONTINUE LEARNING
01 Follow the route 02 Inspect the attributes 03 Change the decision 04 Observe the result
Opens the interactive BGP Core Simulator in a new browser tab.
☕
Enjoyed the BGP learning environment?
Your support helps Network Insight continue developing interactive networking labs, simulators and technical learning content.
Support Network Insight
Computer Networks

Computer Networking: Building a Strong Foundation for Success

Computer Networking

Computer networking has revolutionized how we communicate and share information in today's digital age. Computer networking offers many possibilities and opportunities, from the Internet to local area networks. This blog post will delve into the fascinating world of computer networking and discover its key components, benefits, and prospects.

Computer networking is essentially the practice of connecting multiple devices to share resources and information. It involves using protocols, hardware, and software to establish and maintain these connections. Understanding networking fundamentals, such as IP addresses, routers, and switches, is crucial for anyone venturing into this field.

The Birth of Networking: In the early days of computer networking, it was primarily used for military and scientific purposes. The advent of ARPANET in the late 1960s laid the foundation for what would eventually become the internet. This pioneering effort allowed multiple computers to communicate with each other, setting the stage for the interconnected world we know today.

The Internet Era Begins: The 1990s marked a significant turning point in computer networking with the emergence of the World Wide Web. Tim Berners-Lee's creation of the HTTP protocol and the first web browser fueled the rapid growth and accessibility of the internet. Suddenly, information could be shared and accessed with just a few clicks, transforming the way we gather knowledge, conduct business, and connect with others.

From Dial-Up to Broadband: Remember the days of screeching dial-up modems? As technology progressed, so did our means of connecting to the internet. The widespread adoption of broadband internet brought about faster speeds and more reliable connections. With the introduction of DSL, cable, and fiber-optic networks, users could enjoy seamless online experiences, paving the way for streaming media, online gaming, and the rise of cloud computing.

Wireless Networking and Mobility: Gone are the days of being tethered to a desktop computer. The advent of wireless networking technologies such as Wi-Fi and Bluetooth opened up a world of mobility and convenience. Whether it's connecting to the internet on our smartphones, laptops, or IoT devices, wireless networks have become an indispensable part of our daily lives, enabling us to stay connected wherever we go.

Highlights: Computer Networking

Network Components

Creating a computer network requires a lot of preparation and knowledge of the right components used. One of the first steps in computer networking is identifying what features to use and where to place them. This includes selecting the proper hardware, such as the Layer 3 routers, Layer 2 switches, and Layer 1 hubs if you are on an older network. Along with the right software, such as operating systems, applications, and network services. Or if any advanced computer networking techniques, such as virtualization and firewalling, are required.

Diagram: Cloud Application Firewall.

Network Structure

Once the network components are identified, it’s time to plan the network’s structure. This involves deciding where each piece will be placed and how they will be connected. The majority of networks you will see today will be Ethernet-based. You will need a design process for more extensive networks. Still, for smaller networks, such as your home network, once physically connected, you are ready as all the network services are set up for you on the WAN router by the local service provider.

Network Design

To embark on our journey into network design, it’s crucial to grasp the fundamental concepts. This section will cover topics such as network topologies, protocols, and the different layers of the OSI model. By establishing a solid foundation, you’ll be better equipped to make informed decisions in your network design endeavors.

Assessing Requirements and Goals

Before exploring the technical aspects of network design, it’s essential to identify your specific requirements and goals. This section will explore the importance of conducting a thorough needs analysis, considering factors such as scalability, security, and bandwidth. By aligning your network design with your objectives, you can build a robust and future-proof infrastructure.

Choosing the Right Equipment and Technologies

With a clear understanding of your requirements, it’s time to select the appropriate equipment and technologies for your network. We’ll delve into the world of routers, switches, firewalls, and wireless access points, discussing the criteria for evaluating different options. Additionally, we’ll explore emerging technologies like Software-Defined Networking (SDN) and Network Function Virtualization (NFV) that can revolutionize network design.

Designing for Efficiency and Redundancy

Efficiency and redundancy are vital aspects of network design that ensure reliable and optimized performance. This section will cover load balancing, fault tolerance, and network segmentation strategies. We’ll explore techniques like VLANs (Virtual Local Area Networks), link aggregation, and the implementation of redundant paths to minimize downtime and enhance network resilience.

Securing Your Network

Network security is paramount in an era of increasing cyber threats. This section will address best practices for securing your network, including firewalls, intrusion detection systems, and encryption protocols. We’ll also touch upon network access control mechanisms and the importance of regular updates and patches to safeguard against vulnerabilities.

Firewall types
Diagram: Displaying the different firewall types.

 

 

Related: Additional links to internal content for pre-information:

  1. Data Center Topologies
  2. Distributed Firewalls
  3. Internet of Things Access Technologies
  4. LISP Protocol and VM Mobility.
  5. Port 179
  6. IP Forwarding
  7. Forwarding Routing Protocols
  8. Technology Insight for Microsegmentation
  9. Network Security Components
  10. Network Connectivity

Computer Networks

Key Computer Networking Discussion Points:


  • Introduction to computer networks and what is involved.

  • Highlighting the details of how you connect up networks.

  • Technical details on approaching computer networking and the importance of security.

  • Scenario: The main network devices: Are Layer 2 switches and Layer 3 routers.

  • The different types of protocols sued in computer networks.

Back to Basics: Computer Networks

A network is a collection of interconnected systems that share resources. Networks connect IoT (Internet of Things) devices, desktop computers, laptops, and mobile phones. A computer network will consist of standard devices such as APs, switches, and routers, the essential network components.

Network services

You can connect your network’s devices to other computer networks and the Internet, a global system of interconnected networks. So when we connect to the Internet, we secure the Local Area Network (LAN) to the Wide Area Network (WAN). As we move between computer networks, we must consider security.

You will need a security device between these segments for a stateful inspection firewall. You are probably running IPv4, so you will need a network service called Network Address Translation (NAT). IPv6, the latest version of the IP protocol, does not need NAT but may need a translation service to communicate with IPv4-only networks.

Network Address Translation

♦Types of Networks

There are various types of computer networks, each serving different purposes. Local Area Networks (LANs) connect devices within a limited geographical area, such as homes or offices. Wide Area Networks (WANs) span larger areas, connecting multiple LANs. The internet itself can be considered the most extensive WAN, connecting countless networks across the globe.

Computer networking brings numerous benefits to individuals and businesses. It enables seamless communication, file sharing, and resource access among connected devices. In industry, networking enhances productivity and collaboration, allowing employees to work together efficiently regardless of physical location. Moreover, networking facilitates company growth and expansion by providing access to global markets.

Computer Networking

Computer Networking Main Components


  •  A network is a collection of interconnected systems that share resources. The primary use case of a network was to share printers.

  • A network must offer a range of network services such as NAT.

  • Various types of computer networks, each serving different purposes. LAN vs WAN.

  • Protecting sensitive data, preventing unauthorized access, and mitigating potential threats are constant challenges.

Security and Challenges

With the ever-increasing reliance on computer networks, security becomes a critical concern. Protecting sensitive data, preventing unauthorized access, and mitigating potential threats are constant challenges. Network administrators employ various security measures such as firewalls, encryption, and intrusion detection systems to safeguard networks from malicious activities.

As technology continues to evolve, so does computer networking. Emerging trends such as cloud computing, the Internet of Things (IoT), and software-defined networking (SDN) are shaping the future of networking. The ability to connect more devices, handle massive amounts of data, and provide faster and more reliable connections opens up new possibilities for innovation and advancement.

Local Area Network

A Local Area Network (LAN) is a computer network that connects computers and other devices in a limited geographical area such as a home, school, office building, or closely positioned group of buildings. Ethernet cables typically connect LANs but may also be connected through wireless connections. LANs are usually used within a single organization or business but may connect multiple locations. The equipment in your LAN is in your control.

computer networking

Wide Area Network

Then, we have the Wide Area Network (WAN). In contrast to the LAN, a WAN is a computer network covering a wide geographical area, typically connecting multiple locations. Your LAN may only consist of Ethernet and a few network services.

However, a WAN may consist of various communications equipment, protocols, and media that provide access to multiple sites and users. WANs usually use private leased lines, such as T-carrier lines, to connect geographically dispersed locations. The equipment in the WAN is out of your control.

Computer Networks
Diagram: Computer Networks with LAN and WAN.

LAN

WAN

  • LAN means local area network.

  •   Itconnect users and applications in close geographical proximity (same building).

  •  LANs use OSI Layer 1 and Layer 2 data connection equipment for transmission.

  •   LANs use local connections like Ethernet cables and wireless access points.

  • LANs are faster, because they span less distance and have less congestion.

  • LANs are good for private IoT networks, bot networks, and small business networks. LANs use OSI Layer 1 and Layer 2 data connection equipment for transmission.

  • WAN means wide area network.

  • Itconnect users and applications in geographically dispersed locations (across the globe).

  • WANs use Layer 1, 2, and 3 network devices for data transmission.

  • WANs use wide area connections like MPLS, VPNs, leased lines, and the cloud.

  • WANs are slightly slower, but that may not be perceived by your users.

  • WANs use Layer 1, 2, and 3 network deviceWANs are good for disaster recovery, applications with global users, and large corporate networks.s for data transmission.

Virtual Private Network ( VPN )

We use a VPN to connect LAN networks over a WAN. A virtual private network (VPN) is a secure and private connection between two or more devices over a public network such as the Internet. Its purpose is to provide fast, encrypted communication over an untrusted network.

VPNs are commonly used by businesses and individuals to protect sensitive data from prying eyes. One of the primary benefits of using a VPN is that it can protect your online privacy by masking your IP address and encrypting your internet traffic. This means that your online activities are hidden from your internet service provider (ISP), hackers, and other third parties who may be trying to eavesdrop on your internet connection.

Example: VPN Technology

An example of a VPN technology is Cisco DMVPN. DMVPN operates in phases; there is DMVPN Pashe 1 to 3. For true hub and spoke, you would implement Phase 1; however, today, Phase 3 is the most popular, offering spoke-to-spoke tunnels. The screenshot below is an example of DMVPN Phase 1 running an OSPF network type of broadcast.

DMVPN

Computer Networking

Once the network’s components and structure have been determined, the next step is configuring computer networking. This involves setting up network parameters, such as IP addresses and subnets, and configuring routing tables.

Remember that security is paramount, especially when connecting to the Internet, an untrusted network with a lot of malicious activity. Firewalls help you create boundaries and secure zones for your networks. Different firewall types exist for the other network parts, making a layered approach to security.

Once the computer networking is completed, the next step is to test the network. This can be done using tools such as network analyzers, which can detect any errors or issues present. You can conduct manual tests using Internet Control Message Protocol (ICMP) protocols, such as ping and traceroute. Testing for performance is only half of the pictures. It’s also imperative to regularly monitor the network for potential security vulnerabilities. So, you must have antivirus software, a computer firewall, and other endpoint security controls.

Finally, it’s critical to keep the network updated. This includes updating the operating system and applications and patching any security vulnerabilities as soon as possible. It’s also crucial to watch for upcoming or emerging technologies that may benefit the network.

packet loss testing
Diagram: Packet loss testing.

Lab Guide: Endpoint Networking and Security

Address Resolution Protocol (ARP)

The first command you will want to become familiar with is arp. 

At its core, ARP is a protocol that maps an IP address to a corresponding MAC address. It enables devices within a local network to communicate with each other by resolving the destination MAC address for a given IP address. Devices store these mappings in an ARP table for efficient and quick communication.

Analysis: What you see are 5 column headers explained as follows:

  • Address: The IP address of a device on the network identified through the ARP protocol is resolved to the hostname.

  • HWtype: This describes the type of hardware facilitating the network connection. In this case, it is an ethernet rather than a Wi-Fi interface.

  • HW address: The MAC address assigned to the hardware interface responding to ARP requests.

  • Flags Mask: A hex value translated into ASCII defines how the interface was set.

  • Iface: Lists the interface’s name associated with the hardware and IP address.


Analysis: The output contains the same columns and information, with additional information about the contents of the cache. The -v flag is for verbose mode and provides additional information about the entries in the cache. Focus on the Address. The -n flag tells the command not to resolve the address to a hostname; the result is seeing the Address as an IP.

Note: The IP and Mac address returned is an additional VM running Linux in this network. This is significant because if a device is within the same subnet or layer two broadcast domain as a device identified by its local ARP cache, it will simply address traffic to the designated MAC address. In this way, if you can change the ARP cache, you can change where the device sends traffic within its subnet.

Locally, you can change the ARP cache directly by adding entries yourself.  See the screenshot above:

Analysis: Now you see the original entry and the entry you just set within the local ARP cache. When your device attempts to send traffic to the address 192.168.18.135, the packets will be addressed at layer 2 to the corresponding MAC address from this table. Generally, MAC address to IP address mappings are learned dynamically through the ARP network protocol activity, indicated by the “C” under the Flags Mask column. The CM reflects that the entry was manually added.

Note: Additional Information on ARP

  • ARP Request and Response

When a device needs to communicate with another device on the same network, it initiates an ARP request. The requesting device broadcasts an ARP request packet containing the target IP address for which it seeks the MAC address. The device with the matching IP address responds with an ARP reply packet, providing its MAC address. This exchange allows the requesting device to update its ARP table and establish a direct communication path.

  • ARP Cache Poisoning

While ARP serves a critical purpose in networking, it is vulnerable to attacks like ARP cache poisoning. In this type of attack, a malicious entity spoofs its MAC address, tricking devices on the network into associating an incorrect MAC address with an IP address. This can lead to various security issues, including interception of network traffic, data manipulation, and unauthorized access.

  • Address Resolution Protocol in IPv6

While ARP is predominantly used in IPv4 networks, IPv6 networks utilize a similar protocol called Neighbor Discovery Protocol (NDP). NDP performs functions identical to ARP but with additional features such as stateless address autoconfiguration and duplicate address detection. Although NDP differs from ARP in several ways, its purpose of mapping IP addresses to link-layer addresses remains the same.

Computer Networking & Data Traffic

Computer networking aims to carry data traffic so we can share resources. The first use case of computer networks was to share printers; now, we have a variety of use cases that evolve around data traffic. Data traffic can be generated from online activities such as streaming videos, downloading files, surfing the web, and playing online games. It is also generated from behind-the-scenes activities such as system updates and background and software downloads.

The Importance of Data Traffic

Data traffic is the amount transmitted over a network or the Internet. It is typically measured in bits, bytes, and packets per second. Data traffic can be both inbound and outbound. Inbound traffic is data coming into a network or computer, and outbound traffic is data leaving a network or computer. Inbound data traffic should be inspected by a security device, such as a firewall, which can either be at the network’s perimeter or on your computing device. At the same time, outbound traffic is generally unfiltered.

To keep up with the increasing demand, companies must monitor data traffic to ensure the highest quality of service and prevent network congestion. With the right data traffic monitoring tools and strategies, organizations can improve network performance and ensure their data is secure.

 

The Issues of Best Efforts or FIFO

Network devices don’t care what kind of traffic they have to forward. Ethernet frames are received by your switch, which looks for the destination MAC address before forwarding them. Your router does the same thing: it gets an IP packet, checks the routing table for the destination, and forwards the packet.

Would the frame or packet contain data from a user downloading the latest songs from Spotify or significant speech traffic from a VoIP phone? It doesn’t matter to the switch or router. This forwarding logic is called best effort or FIFO (First In, First Out). Sometimes, this can be an issue when applications are hungry for bandwidth. 

Example: Congestion

The serial link is likely congested when the host and IP phone transmit data and voice packets to the host and IP phone on the other side. Packets queued for transmission will not be indefinitely held by the router.

When the queue is full, how should the router proceed? Are data packets being dropped? Voice packets? If voice packets are dropped, there will be complaints about poor voice quality on the other end. If data packets are dropped, users may complain about slow transfer speeds.

You can change how the router or switch handles packets using QoS tools. For example, the router can prioritize voice traffic over data traffic.

The Role of QoS

Quality of Service (QoS) is a popular technique used in computer networking. QoS can segment applications so that different types will have different priority levels. For example, Voice traffic is often considered more critical than web surfing traffic. Especially as it is sensitive to packet loss. So, when there is congestion on the network, QoS allows administrators to prioritize network traffic so users have the best experience.

Quality of Service (QoS) refers to techniques and protocols prioritizing and managing network traffic. By allocating resources effectively, QoS ensures that critical applications and services receive the necessary bandwidth, low latency, and minimal packet loss while maintaining a stable network connection. This optimization process considers factors such as data type, network congestion, and the specific requirements of different applications.

Expedited Forwarding (EF)

Expedited Forwarding (EF) is a network traffic management model that provides preferential treatment to certain types of traffic. The EF model prioritizes traffic, specifically real-time traffic such as voice, video, and streaming media, over other types of traffic, such as email and web browsing. This allows these real-time applications to function more reliably and efficiently by reducing latency and jitter.

The EF model works by assigning a traffic class to each data packet based on the type of data it contains. The assigned class dictates how the network treats the packet. The EF model has two categories: EF for real-time traffic and Best Effort (BE) for other traffic. EF traffic is given preferential treatment, meaning it is prioritized over BE traffic, resulting in a higher quality of service for the EF traffic.

The EF model is an effective and efficient way to manage computer network traffic. By prioritizing real-time traffic, the EF model allows these applications to function more reliably, with fewer delays and a higher quality of service. Additionally, the EF model is more efficient, reducing the amount of traffic that needs to be managed by the network.

Lab Guide: QoS and Marking Traffic

TOS ( Type of Service )

In this Lab, we’ll take a look at marking packets. Marking means we set the TOS (Type of Service) byte with an IP Precedence or DSCP value.

Marking and Classifcaiton take place on R2. R1 is the source of the ICMP and HTTP Traffic. R3 has an HTTP server installed. As traffic, both telnet and HTTP packets get sent from R1 and traverse R2, classification takes place.

Note:

To ensure each application gets the treatment it requires, we must implement QoS (Quality of Service). The first step when implementing QoS is classification,

QoS classification

We will mark the traffic and apply a QoS policy once it has been classified. Marking and configuring QoS policies are a whole different story, so we’ll stick to classification in this lesson.

On IOS routers, there are a couple of methods we can use for classification:

  • Header inspection
  • Payload inspection

We can use some fields in our headers to classify applications. For example, telnet uses TCP port 23, and HTTP uses TCP port 80. Using header inspection, you can look for:

  • Layer 2: MAC addresses
  • Layer 3: source and destination IP addresses
  • Layer 4: source and destination port numbers and protocol

QoS

♦Benefits of Quality of Service

A) Bandwidth Optimization:

One of the primary advantages of implementing QoS is the optimized utilization of available bandwidth. By classifying and prioritizing traffic, QoS ensures that bandwidth is allocated efficiently, preventing congestion and bottlenecks. This translates into smoother and uninterrupted network experiences, especially when multiple users or devices access the network simultaneously.

B) Enhanced User Experience:

With QoS, users can enjoy a seamless experience across various applications and services. Whether streaming high-quality video content, engaging in real-time online gaming, or participating in video conferences, QoS helps maintain low latency and minimal jitter, resulting in a smooth and immersive user experience.

♦Implementing Quality of Service

To implement QoS effectively, network administrators need to understand the specific requirements of their network and its users. This involves:

A) Traffic Classification:

Different types of network traffic require different levels of priority. Administrators can allocate resources by classifying traffic based on its nature and importance.

B) Traffic Shaping and Prioritization:

Once traffic is classified, administrators can prioritize it using various QoS mechanisms such as traffic shaping, packet queuing, and traffic policing. These techniques ensure critical applications receive the necessary resources while preventing high-bandwidth applications from monopolizing the network.

C) Monitoring and Fine-Tuning:

Regular monitoring and fine-tuning of QoS parameters are essential to maintain optimal network performance. By analyzing network traffic patterns and adjusting QoS settings accordingly, administrators can adapt to changing demands and ensure a consistently high level of service.

Computer Networking Components – Devices:

First, the devices. Media interconnect devices provide the channel over which the data travels from source to destination. Many devices are virtualized today, meaning they no longer exist as separate hardware units.

One physical device can emulate multiple end devices. In addition to having its operating system and required software, an emulated computer system operates as a separate physical unit. Devices can be further divided into endpoints and intermediary devices.

Endpoint: 

Endpoint is a device part of a computer network, including PCs, laptops, tablets, smartphones, video game consoles, and televisions. Endpoints can be physical hardware units, such as file servers, printers, sensors, cameras, manufacturing robots, and smart home components. Nowadays, we have virtualized endpoints.

Computer Networking Components – Intermediate Devices

Layer 2 Switches:

These devices enable multiple endpoints, such as PCs, file servers, printers, sensors, cameras, and manufacturing robots, to connect to the network. Switches allow devices to communicate on the same network. Switches attempt to forward messages from the sender so the destination can only receive them, unlike a hub that floods traffic out of all ports. The switch operates with MAC addresses and works at Layer 2 of the OSI model.

Usually, all the devices that connect to a single switch or a group of interconnected switches belong to a standard network. They can, therefore, exchange information directly with each other. If an end device wants to communicate with a device on a different network, it requires the “services” of a device known as a router. Routers connect other networks and work higher up in the OSI model at Layer 3. They use the IP protocol.

Routers: 

Routers’ primary function is to route traffic between computer networks. For example, you need a router to connect your office network to the Internet. Routers connect computer networks and intelligently select the best paths between them, and they hold destinations in what is known as a routing table. There are different routing protocols for different-sized networks, and each will have other routing convergence times.

routing convergence
The well-known steps in routing convergence.

We recently combined Layer 2 and Layer 3 functionality. So we have a Layer 3 router with a Layer 2 switch module inserted, or we can have a multilayer switch that combines the functions of Layer 3 routing and Layer 2 switch functionality on a single device.

Computer Networks
Diagram: Computer Networks with Switch and Routers.

Wi-Fi access points: 

These devices allow wireless devices to connect. They usually connect to switches but can also be integrated into routers. My WAN router has everything in one box: Wi-Fi, Ethernet LAN, and network services such as NAT and WAN. Wi-Fi access points provide wireless internet access within a specified area.

Wi-Fi access points are typically found in coffee shops, restaurants, libraries, and airports in public settings. These access points allow anyone with a Wi-Fi-enabled device to access the Internet without needing additional hardware. 

WLAN controllers: 

WLAN controllers are devices used to automate the configuration of wireless access points. They provide centralized management of wireless networks and act as a gateway between wireless and wired networks. Administrators can monitor and manage the entire WLAN, set up security policies, and configure access points through the controller. WLAN controllers also authenticate users, allowing them to access the wireless network.

In addition, the WLAN controller can also detect and protect against malicious activities such as unauthorized access, denial-of-service attacks, and interference from other wireless networks. By using the controller, administrators can also monitor the usage of the wireless network and make sure that the network is secure.

Network firewalls:

Then, we have firewalls, which are the cornerstone of security. Depending on your requirements, there will be different firewall types. Firewalls range from basic packet filtering to advanced next-generation firewalls and come in virtual and physical forms.

Generally, a firewall monitors and controls incoming and outgoing traffic according to predefined security rules. The firewall will have a default rule set so that some firewall interfaces are more trusted than others, blankly restricting traffic from outside to inside, but you need to set up a policy for firewalls to work.

A firewall typically establishes a barrier between a trusted, secure internal network and another outside network, such as the Internet, which is assumed not to be secure or trusted. Firewalls are typically deployed in a layered approach, meaning multiple security measures are used to protect the network. Firewalls provide application, protocol, and network layer protection.

data center firewall
Diagram: The data center firewall.
  • Application layer protection:

The next layer is the application layer, designed to protect the network from malicious applications, such as viruses and malware. The application layer also includes software like firewalls to detect and block malicious traffic.

  • Protocol layer protection: 

The third layer is the protocol layer. This layer focuses on ensuring that the data traveling over a network is encrypted and that it is not allowed to be modified or corrupted in any way. This layer also includes authentication protocols that prevent unauthorized users from accessing the network.

  • Network Layer protection

Finally, the fourth layer is network layer protection. This layer focuses on controlling access to the network and ensuring that users cannot access resources or applications they are not authorized to use.

A network intrusion protection system (IPS): 

An IPS or IDS analyzes network traffic to search for signs that a particular behavior is suspicious or malicious. If the IPS detects such behavior, it can take protective action immediately. In addition, the IPS and firewall can work together to protect a network. So, if an IPS detects suspicious behavior, it can trigger a policy or rule for the firewall to implement.

An intrusion protection system can alert administrators of suspicious activity, such as attempts to gain unauthorized access to confidential files or data. Additionally, it can block malicious activity if necessary; it provides a layer of defense against malicious actors and cyber attacks. Intrusion protection systems are essential to any organization’s security plan.

Cisco IPS
Diagram: Traditional Intrusion Detection. With Cisco IPS.

Computer Networking Components – Media

Next, we have the media. The media connects network devices. Different media have different characteristics, and selecting the most appropriate medium depends on the circumstances, including the environment in which the media is used and the distances that need to be covered.

The media will need some connectors. A connector makes it much easier to connect wired media to network devices. A connector is a plug attached to each end of the cable. RJ-45 connector is the most common type of connector on an Ethernet LAN.

Ethernet: Wired LAN technology.

The term Ethernet refers to an entire family of standards. Some standards define how to send data over a particular type of cabling and at a specific speed. Other standards define protocols or rules that the Ethernet nodes must follow to be a part of an Ethernet LAN. All these Ethernet standards come from the IEEE and include 802.3 as the beginning of the standard name.

Introducing Copper and Fiber

Ethernet LANs use cables for the links between nodes on a computer network. Because many types of cables use copper wires, Ethernet LANs are often called wired LANs. Ethernet LANs also use fiber-optic cabling, which includes a fiberglass core that devices use to send data using light. 

Materials inside the cable: UTP and Fiber

The most fundamental cabling choice concerns the materials used inside the cable to transmit bits physically: either copper wires or glass fibers. 

  • Unshielded twisted pair (UTP) cabling devices transmit data over electrical circuits via the copper wires inside the cable.
  • Fiber-optic cabling, the more expensive alternative, allows Ethernet nodes to send light over glass fibers in the cable’s center. 

Although more expensive, optical cables typically allow longer cabling distances between nodes. So you have UTP cabling in your LAN and Fiber-optic cabling over the WAN.

UTP and Fiber

The most common copper cabling for Ethernet is UTP. An unshielded twisted pair (UTP) is cheaper than the other two and is easier to install and troubleshoot. Many UTP-based Ethernet standards can use a cable length of up to 100 meters, which means that most Ethernet cabling in an enterprise uses UTP cables.

The distance from an Ethernet switch to every endpoint on a building’s floor will likely be less than 100m. In some cases, however, an engineer might prefer to use fiber cabling first for some links in an Ethernet LAN to reach greater distances.

Fiber Cabling

Then we have fiber-optic cabling, a glass core that carries light pulses and is immune to electrical interference. Fiber-optic cabling is typically used as a backbone between buildings. So fiber cables are high-speed transmission mediums. It contains tiny glass or plastic filaments as the medium to which light passes.

Cabling types: Multimode and Single Mode

There are two main types of fiber optic cables. We have single-mode fiber ( SMF) and multimode fiber ( MMF). Two implementations of fiber-optic include MMF for shorter distances and SMF for longer distances. Multimode improves the maximum distances over UTP and uses less expensive transmitters than single-mode. Standards vary; for instance, the criteria for 10 Gigabit Ethernet over Fiber allow for distances up to 400m, often allowing for connecting devices in different buildings in the same office park.

Network Services and Protocols

We need to follow these standards and the rules of the game. We also need protocols so we have the means to communicate. If you use your web browser, you use the HTTP protocol. If you send an email, you use other protocols, such as IMAP and SMTP.

A protocol establishes a set of rules that determine how data is transmitted between different devices in the network. The two protocols must talk to each other, such as HTTP at one end and HTTP at the other.

Consider protocol the same way you would speak the same language. We need to communicate in the same language. Then, we have standards that we need to follow for computer networking, such as the TCP/IP suite.

Types of protocols

We have different types of protocols. The following are the main types of protocols used in computer networking.

  • Communication Protocols

For example, we have routing protocols on our routers that help you forward traffic. This would be an example of a communication protocol that allows different devices to communicate with each other. Another example of a communication protocol would be instant messaging.

Instant messaging is instantaneous, text-based communication you probably have used on your smartphone. So here we have several instant messaging network protocols. Short Message Service (SMS): This communications protocol was created to send and receive text messages over cellular networks.  

  • Network Management

Network management protocols define and describe the various operating procedures of a computer network. These protocols affect multiple devices on a single network—including computers, routers, and servers—to ensure that each one and the network as a whole perform optimally.

  • Security Protocols

Security protocols, also called cryptographic protocols, ensure that the network and the data sent over it are protected from unauthorized users. Security protocols are implemented on more than just your network security devices. They are implemented everywhere. The standard functions of security network protocols include encryption: Encryption protocols protect data and secure areas by requiring users to input a secret key or password to access that information.

The following screenshot is an example of an IPsec tunnel offering end-to-end encryption. Notice that the first packet in the ping ( ICMP request ) was lost due to ARP working in the background. Five pings are sent, but only four are encapsulated/decapsulated.

Site to Site VPN

Characteristics of a network

Network Topology:

In a carefully designed network, data flows are optimized, and the network performs as intended based on the network topology. Network topology is the arrangement of a computer network’s elements (links, nodes, etc.). It can be used to illustrate a network’s physical and logical layout and how it functions. 

what is spine and leaf architecture

Bitrate or Bandwidth:

It is often referred to as bandwidth or speed in device configurations, sometimes considered speed. Bitrate measures the data rate in bits per second (bps) of a given link in the network. The number of bits transmitted in a second is more important than the speed at which one bit is transmitted over the link – which is determined by the physical properties of the medium that propagates the signal. Many link bit rates are commonly encountered today, including 1 and 10 gigabits per second (1 and 10 billion bits per second). Some links can reach 100 and even 400 gigabits per second.

Network Availability: 

Network availability is determined by several factors, including the type of network being used, the number of users, the complexity of the network, the physical environment, and the availability of network resources. Network availability should also be addressed in terms of redundancy and backup plans. Redundancy helps to ensure that the system is still operational even if one or more system components fail. Backup plans should also be in place in the event of a system failure.

A network’s availability is calculated based on the percentage of time it is accessible and operational. To calculate this percentage, divide the number of minutes the network is available by the total number of minutes it is available for over an agreed period and divide it by 100. In other words, availability is the ratio of uptime and full-time, expressed in percentage. 

Gateway Load Balancer Protocol

Network High Availability: 

High availability is a critical component of a successful IT infrastructure. It ensures that systems and services remain available and accessible to users and customers. High availability is achieved by using redundancies, such as multiple servers, systems, and networks, to ensure that if one component fails, a backup component is available.

High availability is also achieved through fault tolerance, which involves designing systems that respond to failures without losing data or becoming unavailable. Various strategies, such as clustering, virtualization, and replication, can achieve high availability.

Network Reliability:

Network reliability can be achieved by implementing a variety of measures, often through redundancy. Redundancy is a crucial factor in ensuring a reliable network. Redundancy has multiple components to provide a backup in case of failure. Redundancy can include having multiple servers, routers, switches, and other hardware devices. Redundancy can also involve having numerous sources of power, such as various power supplies or batteries, and multiple paths for data to travel through the network.

For adequate network reliability, you also need to consider network monitoring. Network monitoring involves using software and hardware tools to monitor the network’s performance continuously. Monitoring can detect and alert administrators of potential performance issues or failures. We have a new term called Observability, which accurately reflects tracking in today’s environment.

Network Characteristics
Diagram: Network Characteristics

Network Scalability:

A network’s scalability indicates how easily it can accommodate more users and data transmission requirements without affecting performance. Designing and optimizing a network only for the current conditions can make it costly and challenging to meet new needs when the network grows.

Several factors must be taken into account in terms of network scalability. First and foremost, the network must be designed with the expectation that the number of devices or users will increase over time. This includes hardware and software components, as the network must support the increased traffic. Additionally, the network must be designed to be flexible so that it can easily accommodate changes in traffic or user count. 

Network Security: 

Network security is protecting the integrity and accessibility of networks and data. It involves a range of protective measures designed to prevent unauthorized access, misuse, modification, or denial of a computer network and its processing data. These measures include physical security, technical security, and administrative security. A network’s security tells you how well it protects itself against potential threats.

The subject of security is essential, and defense techniques and practices are constantly evolving. The network infrastructure and the information transmitted over it should also be protected. Whenever you take actions to affect the network, you should consider security. An excellent way to view network security is to take a zero-trust approach.

Software Defined Perimeter and Zero Trust
Software Defined Perimeter and Zero Trust

Virtualization: 

Virtualization can be done at the hardware, operating system, and application level. At the hardware level, physical hardware can be divided into multiple virtual machines, each running its operating system and applications.

At the operating system level, virtualization can run multiple operating systems on the same physical server, allowing for more efficient resource use. At the application level, multiple applications can run on the same operating system, allowing for better resource utilization and scalability. 

container based virtualization

Overall, virtualization can provide several benefits, including improved efficiency, utilization, flexibility, security, and scalability. It can consolidate and manage hardware or simplify application movement between different environments. Virtualization can also make it easier to manage other settings and provide better security by isolating various applications.

Computer Networking

Characteristics of a Network



  • Network Topology– It is the arrangement of a computer network’s elements (links, nodes, etc.)

  • Bitrate or Bandwidth– Bitrate measures the data rate in bits per second (bps) of a given link in the network.

  • Network Availability– It calculate based on the percentage of time it is accessible and operational..

  •  High Availability– It ensures that systems and services remain available and accessible to users and customers.

  • Reliability– It can be achieved by implementing a variety of measures, often through redundancy.

  • Scalability– Indicates how easily it can accommodate more users and data transmission needs without affecting performance.

  • Security– It protect the integrity, accessibility of networks & data, tells you how well it protects itself against potential threats..

  • Virtualization– It helps to improved efficiency, utilization & flexibility, as well as improved security and scalability.

Computer Networking and Network Topologies

Physical and logical topologies exist in networks. The physical topology describes the physical layout of the devices and cables. A physical topology may be the same in two networks but may differ in distances between nodes, physical connections, transmission rates, or signal types.

There are various types of physical topologies you may encounter in wired networks. Identifying the kind of cabling used is essential when describing the physical topology. Physical topology can be categorized into the following categories:

Bus Topology:

In a bus topology, every workstation is connected to a common transmission medium, a single cable called a backbone or bus. In a previous bus topology, computers and other network devices were connected to a central coaxial cable via connectors, resulting in direct connectivity.

Ring Topology:

In a ring topology, computers and other network devices are cabled in succession, with the last device connected to the first to form a circle or ring. There are two neighbors for every device in the network, and there are no direct connections between them. When one node sends data to another, it passes through each node between them until it reaches its destination.

  • Star Topology: 

A star topology is the most common physical topology, where network devices are connected to a central device through point-to-point connections. It is also known as the hub and spoke topology. A spoke device does not have a direct physical connection to another. This topology can also be called the extended star topology. A device with its spokes replaces one or more spoke devices in an extended star topology.

Mesh Topology: 

One device can be connected to more than one other in a mesh topology. Multiple paths are available for one node to reach another. Redundant links enhance reliability and self-healing. In a full mesh topology, all nodes are connected. In partial mesh, some nodes do not connect to all other nodes.

Introducing Switching Technologies

All Layer 2 devices connect to switches to communicate with one another. Switches work at layer two of the Open Systems Interconnection (OSI) model, the data link layer. Switches are ready to use right out of the box. In contrast to a router, a switch doesn’t require configuration settings by default. When you unbox the switch, it does not need to be configured to perform its role, which is to provide connectivity for all devices on your network. After putting power on the switch and connecting the systems, the switch will forward traffic to each connected device as needed.

Switch vs. Hubs

Moreover, you learned that switches had replaced hubs since they provide more advanced capabilities and are better suited to today’s computer networks. Advanced functionality includes filtering traffic by sending data only to the destination port (while a hub always sends data to all ports).

Full Duplex vs. Half Duplex

With a full duplex, both parties can talk and listen simultaneously, making it more efficient than half-duplex communication, where only one can speak simultaneously. Full duplex transmission is also more reliable since it is less likely to experience interference or distortion. Until switches became available, communication devices were only half-duplexed with hubs. A half-duplex device can send and receive simultaneously, but not simultaneously send and receive.

VLAN: Logical LANs

Virtual Local Area Networks (VLANs) are computer networks that divide a single physical local area network (LAN) into multiple logical networks. This partitioning allows for the segmentation of broadcast traffic, which helps to improve network performance and security.

VLANs enable administrators to set up multiple networks within a single physical LAN without needing separate cables or ports. These benefits businesses need to separate data and applications between various teams, departments, or customers.

In a VLAN, each segment is identified by a unique identifier or VLAN ID. The VLAN ID is used to associate traffic with a particular VLAN segment. For example, if a user needs to access an application on a different VLAN, the packet must be tagged with the VLAN ID of the destination segment to be routed correctly.

In the screenshot below, we have an overlay with VXLAN. VXLAN, short for Virtual Extensible LAN, is an overlay network technology that enables the creation of virtual Layer 2 networks over an existing Layer 3 infrastructure. It addresses traditional VLANs’ limitations by extending network virtualization’s scalability and flexibility. By encapsulating Layer 2 frames within UDP packets, VXLAN allows for creating up to 16 million logical networks, overcoming the limitations imposed by the 12-bit VLAN identifier field.

VXLAN
Diagram: Changing the VNI

VLANs also provide security benefits. A VLAN can help prevent malicious traffic from entering a segment by segmenting traffic into logical networks. This helps prevent attackers from gaining access to the entire network. Additionally, VLANs can isolate critical or confidential data from other users on the same network. VLANs can be implemented on almost any network, including wired and wireless networks. They can also be combined with other network technologies, such as routing and firewalls, to improve security further.

Overall, VLANs are powerful tools for improving performance and security in a local area network. With the right implementation and configuration, businesses can enjoy improved performance and better protection.

Switching Technologies

Switching Technologies


  •  Switch vs. Hubs- Switches replaced hubs since they provide more advanced capabilities and are better suited to today’s computer networks.

  • Full Duplex vs. Half Duplex- In Half Duplex mode, Sender can send the data and also can receive the data but one at a time. In Full Duplex mode, Sender can send the data and also can receive the data simultaneously.

  •  VLAN: Logical LANs- VLANs are a powerful tool to help improve performance and security in a local area network.

IP Routing Process

IP routing works by examining the IP address of each packet and determining where it should be sent. Routers are responsible for this task and use routing protocols such as RIP, OSPF, EIGRP, and BGP to decide the best route for each packet. In addition, each router contains a routing table, which includes information on the best path to a given destination.

When a router receives a packet, it looks up the destination in its routing table. If the destination is known, the router will make a forwarding decision based on the routing protocol. The router will use a default gateway to forward the packet if the destination is unknown.

Routing Protocol
Diagram: Routing Protocol. ISIS.

To route packets successfully, routers must be configured appropriately and able to communicate with one another. They must also be able to detect any changes to the network, such as link failures or changes in network topology.

IP routing is essential to any network, ensuring packets are routed as efficiently as possible. Therefore, it is crucial to ensure that routers are correctly configured and maintained.

IP Forwarding Example
Diagram: IP Forwarding Example.

Routing Table

A routing table is a data table stored in a router or a networked computer that lists the possible routes a packet of data can take when traversing a network. The routing table contains information about the network’s topology and decides which route a packet should take when leaving the router or computer. Therefore, the routing table must be updated to ensure data packets are routed correctly.

The routing table usually contains entries that specify which interface to use when forwarding a packet. Each entry may have network destination addresses and associated metrics, such as the route’s cost or hop count. In addition to the destination address, each entry can include a subnet mask, a gateway address, and a list of interface addresses.

Routers use the routing table to determine which interface to use when forwarding packets. When a router receives a packet, it looks at the packet’s destination address and compares it to the entries in the routing table. Once it finds a match, it forwards the packet to the corresponding interface.

Lab Guide: Networking and Security

Routing Tables and Netstat

Routing tables are essentially databases stored within networking devices, such as routers. These tables contain valuable information about the available paths and destinations within a network. Each entry in a routing table consists of various fields, including the destination network address, next-hop address, and interface through which the data packet should be forwarded.

One of the fundamental features of Netstat is its ability to display active connections. Using the appropriate flags, you can view the list of established connections, their local and remote IP addresses, ports, and the protocol being used. This information is invaluable for identifying suspicious or unauthorized connections.

Get started by running the route command.

Analysis: Seem familiar? Yet another table with the following column headers:

    • Destination: This refers to the destination of traffic from this device. The default refers to anything not explicitly set.

    • Gateway: The next hop for traffic headed to the specific destination.

    • Genmask: The netmask of the destination.

      Note: For more detailed explanations of all the columns and results, run man route.

Run netstat to get a stream of information relating to network socket connections and UNIX domain sockets.

Note: UNIX domain sockets are a mechanism that allows processes local to the devices to exchange data.

  1. To clean this up, you can view just the network traffic using. netstat -at.

    • -a displays all ports, including IPV4 & IPV6

    • -t displays only TCP sockets

Analysis: When routes are created in different ways, they display differently. In the most recent rule, you can see that no metric is listed, and the scope is different from the other automatic routes. That is the kind of information we can use for detection.

The route table will send traffic to the designated gateway regardless of the route’s validity. Threat actors can use this to intercept traffic destined for another location, making it a crucial place to look for indicators of compromise.

How Routing Tables Work:

Routing tables utilize various routing protocols, such as OSPF (Open Shortest Path First) or BGP (Border Gateway Protocol), to gather information about network topology and make informed decisions about the best paths for data packets. These protocols exchange routing information between routers, ensuring that each device has an up-to-date understanding of the network’s structure.

Routing Table Entries and Metrics:

Each entry in a routing table contains specific metrics that determine the best path for forwarding packets. Metrics can include hop count, bandwidth, delay, or reliability. By evaluating these metrics, routers can select the most optimal route based on network conditions and requirements.

Summary: Computer Networking

It’s the backbone of modern communication, from browsing the internet to sharing files across devices. In this blog post, we delved into the fascinating world of computer networking, exploring its key concepts, benefits, and future prospects.

Section 1: What is Computer Networking?

Computer networking refers to connecting multiple computers and devices to facilitate data sharing and communication. It involves hardware components such as routers, switches, cables, and software protocols that enable seamless data transmission.

Section 2: The Importance of Computer Networking

Computer networking has revolutionized how we work, communicate, and access information. It enables efficient collaboration, allowing individuals and organizations to share resources, communicate in real-time, and access data from anywhere in the world. Whether a small local network or a global internet connection, networking plays a pivotal role in our digital lives.

Section 3: Types of Computer Networks

There are various types of computer networks, each serving different purposes. Local Area Networks (LANs) connect devices such as homes, offices, or schools within a limited area. Wide Area Networks (WANs) span larger geographical areas, connecting multiple LANs together. Additionally, there are Metropolitan Area Networks (MANs), Wireless Networks, and the vast Internet itself.

Section 4: Key Concepts in Computer Networking

To understand computer networking, you must familiarize yourself with key concepts like IP addresses, protocols (such as TCP/IP), routing, and network security. These concepts form the foundation of how data is transmitted, received, and protected within a network.

Section 5: The Future of Computer Networking

As technology advances, so does the world of computer networking. Emerging trends such as the Internet of Things (IoT), 5G networks, and cloud computing are reshaping the networking landscape. These developments promise faster speeds, increased connectivity, and enhanced security, paving the way for a more interconnected future.

Conclusion:

In conclusion, computer networking is a fascinating field that underpins our digital world. Its importance cannot be overstated, as it enables seamless communication, resource sharing, and global connectivity. Understanding the key concepts and staying updated with the latest trends in computer networking will empower individuals and organizations to make the most of this ever-evolving technology.

Diagram: Cloud Application Firewall.

Cisco CloudLock

Cisco CloudLock

Cloud applications have changed the way organizations store, access, and share information. Users can work with SaaS applications from corporate offices, branch locations, home networks, and mobile devices, while sensitive data can move between multiple cloud services without passing through the traditional corporate security perimeter.

This creates a different security challenge.

The question is no longer simply whether a user is connected to the network or whether a connection should be allowed. Security teams increasingly need to understand who is accessing the application, what they are doing, what data is involved, and whether that activity complies with security policy.

This is the security problem that Cisco CloudLock was designed to address.

Cisco CloudLock is a cloud-native Cloud Access Security Broker (CASB) that provides visibility and security controls around cloud applications, users, and data. Rather than attempting to recreate the traditional network perimeter around every SaaS application, CloudLock works with cloud services to provide a security and governance layer around activity taking place within them.

This becomes particularly important as organizations adopt multiple cloud applications. Security teams need to understand not only which applications are being used, but also how those applications are being used, what information is being shared, and where potential security risks exist.

CloudLock therefore brings together several important areas of cloud security, including data security, application security, user security, threat detection, and policy enforcement.

The broader objective is not simply to block cloud activity. It is to provide enough visibility and context for security teams to distinguish legitimate business activity from behaviour that may introduce risk.

Throughout this article, we will examine the architecture behind CloudLock, the security challenges created by direct-to-cloud access, the role of DLP and application-aware controls, and how the CASB model provides a different approach to protecting cloud applications and data.

Learning Objective
Understand how a cloud-native CASB connects user activity, cloud applications, data and security policy without relying exclusively on the traditional network perimeter.
Cloud Security Workflow
01 Visibility
02 Analysis
03 Policy
04 Response
Architecture Explorer
Cisco CloudLock
CloudLock operates as a cloud-native Cloud Access Security Broker. Select an architecture component or security domain to explore how it contributes to the overall cloud-security model.
Security Signals
Cloud Visibility API Integration Data Application Activity
Cloud Security Event Console
[READY] CloudLock architecture model initialised. [MODEL] Users → CloudLock → Security Policy [STATUS] Cloud visibility control available. [WAIT] Select a component or security domain.
Engineering takeaway: Cloud security is not simply about controlling connectivity. The important architectural shift is gaining visibility into the relationship between identity, applications, data, behaviour and policy beyond the traditional network perimeter.

Microservices Security

“The Road To Cisco Cloudlock Or Multiple Point Products”

Protecting a modern SaaS environment can require multiple security capabilities, including UEBA, DLP, application security, threat detection, identity controls, and compliance monitoring. Historically, organizations often addressed these requirements by deploying separate products for each capability and then integrating those products with individual cloud applications.

This approach can provide strong functionality, but it also introduces operational complexity. Security teams may need to manage multiple products, policies, integrations, dashboards, and data sources across an increasingly distributed environment.

As the number of cloud applications increases, maintaining consistent security policies across these individual control points becomes increasingly difficult.

The challenge is therefore not simply adding more security products. It is creating a security architecture that provides visibility across users, applications and data while allowing security policies to be applied consistently.

Cisco CloudLock provides an example of this approach through its cloud-native Cloud Access Security Broker (CASB)architecture, bringing cloud application visibility, user activity analysis, data protection, and policy enforcement into a cloud-focused security model.

The broader Cisco security architecture can then provide additional controls for secure access, identity, threat protection, and network security.

Challenge: Lack of Visibility

Cloud adoption changes the traditional security model. Applications and data are no longer necessarily hosted inside an organization’s data centre, and users may access SaaS applications directly from offices, branch locations, home networks, or mobile devices.

This creates a fundamental visibility challenge.

Security teams need to understand what is happening in the cloud, who is performing the activity, which application is involved, what data is being accessed, and whether that activity complies with security policy.

Traditional network controls can provide important visibility into network traffic, but they do not necessarily provide the application-level or data-level context required to understand activity occurring inside SaaS platforms.

The cloud therefore introduces a different security question.

Instead of asking only where a connection originated, security teams increasingly need to understand the relationship between identity, application, data, behaviour and policy.

Examples: Cloud Security Solutions.

Cisco CloudLock

Cisco Umbrella

Cisco Secure Cloud Analytics

Cisco Duo Security

These technologies address different parts of the wider cloud-security problem. The important architectural principle is that cloud security should not depend on a single control point. Identity, application, data, network, and threat controls may all contribute to the overall security model.

Challenge: Direct to the Cloud

Cloud computing provides users with direct access to applications, data, and services from almost anywhere. SaaS applications have accelerated this model because employees can work directly with cloud services without requiring applications to be hosted inside the corporate network.

As organizations adopt direct internet access, branch offices and remote users increasingly connect to cloud services instead of backhauling traffic through a central corporate security stack.

This changes the role of traditional security controls.

The traditional security stack was designed around a model where users, applications, and data were largely located behind a corporate perimeter. Cloud services challenge that assumption because the application may be external, the user may be remote, and the data may exist entirely within a SaaS platform.

This does not make traditional network security obsolete. Instead, it means network security must be complemented by controls that understand cloud applications, identities, user activity, and data.

The result is a shift from a purely network-centric security model towards a broader model based on identity, application, data, behaviour and policy.

Cisco Umbrella and Cisco Cloudlock

Cisco Umbrella and Cisco CloudLock address different parts of the cloud-security problem.

Umbrella provides cloud-delivered security capabilities for users connecting to the Internet and can provide visibility across network devices, office locations, and roaming users. This makes it particularly relevant to secure internet access and identifying or preventing malicious activity before it reaches users and devices.

CloudLock takes a different approach. It uses a 100 percent cloud-native, API-based approach. Rather than relying solely on visibility of network traffic, the CASB model focuses on activity occurring within cloud applications, including users, applications, data, and cloud-to-cloud interactions.

This distinction is important.

A user may access a SaaS application successfully over an encrypted internet connection while performing an action that violates organizational policy. Network-level controls may know that the user connected to the application, but a cloud security control needs to understand what the user did inside the application and what happened to the data.

Together, these approaches demonstrate an important principle of modern cloud security: protecting cloud environments requires visibility both around the connection and inside the cloud application.

Highlighting Cisco Cloudlock

Cisco CloudLock is a Cloud Access Security Broker (CASB) that helps organizations understand and protect cloud-based identities, applications, and data.

The value of the CASB model is not simply that it adds another security product. It provides a security control point for understanding activity that can otherwise be difficult to observe when applications and data are hosted outside the traditional corporate network.

CloudLock can therefore be viewed through three primary security domains: data security, application security, and user security.

Data Loss Prevention:

A Cisco Cloudlock Data Loss Prevention (DLP) capability can identify sensitive information within cloud environments and apply policies designed to reduce unauthorized sharing or exposure.

At this stage, the important architectural point is simply that cloud DLP provides visibility into the data being used within cloud applications and allows security policy to be applied to that activity.

The detailed DLP use cases and data-protection mechanisms are examined later in this article.

Automated Responses:

Cloud security becomes more effective when visibility can be connected to an appropriate response.

Through Cisco Cloudlock’s API-driven Cloud Access Security Broker (CASB) architecture, security events can be associated with actions within the monitored cloud application. Depending on the application and policy, responses can include generating alerts, restricting activity, protecting information, or taking action against cloud resources.

This creates a security workflow that moves beyond simple discovery:

Visibility → Analysis → Policy → Security Response

The objective is to identify risky activity and provide security teams with enough context to make an appropriate response without relying entirely on manual investigation.

Understanding CASBs – Security Control Point

CASB, the acronym for Cloud Access Security Broker, describes a security control point positioned around cloud services and applications. It is a security control point, providing visibility, policy enforcement, data protection, and security monitoring for cloud environments.

The importance of CASB becomes clearer when considering how cloud applications are used today. Users may connect from different locations and devices, applications may be delivered entirely through SaaS platforms, and sensitive information may move between multiple cloud services.

A CASB therefore helps security teams establish a consistent security view across these activities.

The principal CASB capabilities include:

  • cloud application visibility

  • data protection and DLP

  • policy enforcement

  • threat and behavioural analysis

  • access and identity controls

  • compliance monitoring

  • security response

Importantly, CASB solutions go beyond simply “permitting” or “denying” access. They can provide visibility into what users are doing inside cloud applications and apply policy to activities involving data and applications.

The cloud application itself does not necessarily need to change. Users continue accessing the SaaS service, while the CASB provides an additional security and governance layer around that activity.

CASB Categories:

CASB architectures can be implemented in different ways. Two important approaches are API-based CASB and log-based CASB.

A log-based approach typically consumes activity information from cloud applications or other monitoring systems. This provides valuable visibility, but the CASB is dependent on logs being generated, collected, and processed before meaningful analysis can occur.

An API-based approach communicates directly with supported cloud applications through their APIs. This allows the CASB to inspect cloud data and activity without requiring all user traffic to pass through a traditional proxy.

API-based CASB protection is particularly useful for cloud-to-cloud activity. For example, a user may move information between SaaS applications without that traffic ever travelling through the corporate network.

Cloudlock is an API-based CASB. Therefore, unlike a traditional proxy-based security architecture, it does not need to sit directly in the user traffic path to provide cloud security controls.

This has important architectural advantages. The security model does not require all cloud traffic to be forced through a central proxy infrastructure simply to gain visibility into cloud applications.

The result is a different approach: rather than attempting to recreate the traditional corporate perimeter around every cloud application, the security control works directly with the cloud application’s data, users, and APIs.

That distinction is central to understanding why CloudLock is fundamentally a cloud-native security control rather than simply another network firewall.

Learning Objective
Select a security domain, examine the signals available to the security team, and understand how those signals contribute to a contextual cloud-security decision.
Cloud Security Policy
Visibility → Analysis → Policy → Security Response
Investigation
Select a security domain
Select Data Security, Application Security or User Security to begin the investigation.
Identity
Application
Data
Behaviour
Investigation Context
What should the engineer examine?
Security Context
0 / 6 signals
Choose a domain and then select the security signals you would use to investigate that activity.
Security Investigation Console
READY
Cloud security investigation ready.
DATA → What needs protection?
APPLICATION → Where is it being used?
USER → Who is using it?
Engineer’s takeaway: Cloud security decisions become stronger when the security team combines multiple signals rather than evaluating data, applications or users in isolation. The goal is to build enough context to determine whether activity is consistent with policy and acceptable risk.

Cloud Security Concepts

A. Data Loss Prevention (DLP)

Let us start with DLP. Data Loss Prevention (DLP) is designed to prevent sensitive or regulated information from leaving an organization without authorization. This becomes particularly challenging in cloud environments, where users can access, copy, share, and distribute information across multiple SaaS platforms and external services.

Traditional security controls such as firewalls, email security, and endpoint protection are primarily concerned with protecting users, systems, and network traffic. DLP addresses a different problem: preventing authorized users from performing unauthorized data-handling actions.

This is an important distinction. An employee may legitimately have access to customer records, financial information, or intellectual property. The security problem begins when that legitimate access is used to move sensitive information somewhere it should not go.

Intentional and accidental data breaches are not uncommon.

Example: Google Cloud Sensitive Data Protection

Sensitive data protection

DLP in Action – Example of Threat:

  • Consider a financial services organization where an employee has legitimate access to large quantities of credit card numbers and personally identifiable information (PII). The employee may also have legitimate access to corporate email.

  • An attacker does not necessarily need to compromise the employee’s account. A malicious insider, or an employee acting accidentally, could simply attach sensitive information to an email and send it to a personal account.

  • Firewalls and email security solutions can’t necessarily prevent this type of activity because the user may be legitimately authenticated and the email service itself may be authorized.

  • They are not looking for that type of metadata. DLP, however, is specifically designed to identify sensitive information and apply policy when that information is being shared, copied, downloaded, or transferred.

With appropriately configured DLP policies, organizations can identify sensitive information, generate alerts, block unacceptable transfers, and create an audit trail for investigation.

“Generally speaking, it boils down to a lack of visibility”

This is particularly important in cloud environments. Traditional on-premises security controls have historically provided strong visibility into network traffic, but SaaS applications introduce a different model. Users can share files directly from cloud applications with external parties without that activity necessarily passing through the organization’s traditional network security stack.

The collaborative nature of cloud applications makes this both powerful and risky. A user can share a document with an external address, create a public link, or move information between cloud services without the data ever traversing the corporate network.

DLP and CASB technologies extend visibility into these environments. A security team can determine whether sensitive files are being shared externally, whether sharing violates organizational policy, and whether an action should be allowed, blocked, or reported.

The important point is that DLP is not simply about identifying sensitive information. Effective cloud DLP combines data classification, user identity, application context, activity, and policy to determine whether an action should be permitted.

 


 

B. Application Firewalls

Next, we have application firewalls. How does an application firewall differ from a “traditional firewall”? The fundamental difference is what the security policy is protecting.

A traditional network firewall primarily evaluates network traffic using attributes such as source and destination addresses, ports, protocols, and connection state. An application firewall moves the security decision closer to the application itself.

Application Firewall vs. Traditional Firewall.

Cloud applications introduce an important challenge for traditional network-based controls. A SaaS application may need to be accessible from many different networks and devices. Consequently, building security policy primarily around “Source IP” becomes increasingly restrictive and less useful.

A user could connect from a corporate office, a home network, a mobile connection, or another country. The application still needs to determine whether the user, request, session, or transaction should be trusted.

Your toolkit just became ineffective when it came to Layer 3 and Layer 4 security controls.

This does not mean that network firewalls have become irrelevant. Layer 3 and Layer 4 controls remain important for network segmentation, traffic filtering, and infrastructure protection. The issue is that they cannot, by themselves, provide all of the context required to make decisions inside modern cloud applications.

Application-aware security can consider factors such as:

  • the application being accessed

  • the identity of the user

  • the type of device

  • the requested action

  • the sensitivity of the data

  • the location or risk context

  • the behaviour associated with the session

The security model therefore moves beyond simply asking “Where did this traffic come from?” and begins asking “What is the user attempting to do, and should that action be permitted?”

Example: Distributed Firewalling

Distributed security controls illustrate how policy can be enforced closer to workloads, applications, and users rather than relying exclusively on a centralized perimeter.

The important architectural point is that cloud security is not achieved by simply extending the traditional perimeter into the cloud. Security controls need to operate at the appropriate layer and understand the application, identity, data, and context involved.

For CloudLock, this distinction is important because CloudLock is not primarily a replacement for a traditional network firewall. Its value comes from providing visibility and policy enforcement around cloud applications and the data contained within them.

 


 

C. Cloud Access Security Broker (CASB)

Users interact with cloud services such as SaaS applications, IaaS platforms, and PaaS environments from many different locations and devices. A Cloud Access Security Broker (CASB) provides a security control point around the organization’s use of those cloud services.

The key benefit is visibility and policy enforcement in environments that the organization does not directly own or operate.

CASB solutions can help protect cloud data, applications, and user activity regardless of where the user is or how they access the cloud application.

Where traditional security mechanisms often focus on the endpoint or network, a CASB focuses specifically on the organization’s use of cloud services.

CASBs can provide capabilities including:

  • visibility into cloud application usage

  • data loss prevention

  • policy enforcement

  • detection of risky behaviour

  • access control

  • compliance monitoring

  • protection of sensitive information

Importantly, CASB solutions go beyond simply “permitting” or “denying” access. They can provide visibility into what users are doing inside cloud applications and apply policy to activities involving data and applications.

The cloud application itself does not necessarily need to change. Users continue accessing the SaaS service, while the CASB provides an additional security and governance layer around that activity.

CASB Categories:

CASB architectures can be implemented in different ways. Two important approaches are API-based CASB and log-based CASB.

A log-based approach typically consumes activity information from cloud applications or other monitoring systems. This provides valuable visibility, but the CASB is dependent on logs being generated, collected, and processed before meaningful analysis can occur.

An API-based approach communicates directly with supported cloud applications through their APIs. This allows the CASB to inspect cloud data and activity without requiring all user traffic to pass through a traditional proxy.

API-based CASB protection is particularly useful for cloud-to-cloud activity. For example, a user may move information between SaaS applications without that traffic ever travelling through the corporate network.

Cloudlock is an API-based CASB. Therefore, unlike a traditional proxy-based security architecture, it does not need to sit directly in the user traffic path to provide cloud security controls.

This has several architectural advantages. The security model does not require all cloud traffic to be forced through a central proxy infrastructure simply to gain visibility into cloud applications.

Instead, the CASB can work with the cloud application’s own interfaces to understand data, users, application activity, and policy-relevant events.

This becomes particularly valuable when data moves between cloud services. A user might download information from one SaaS platform and upload it into another without that activity traversing the corporate network.

A traditional network-centric security model may have limited visibility into that cloud-to-cloud transaction. An API-based CASB can provide a different point of visibility by interacting directly with the supported cloud services.

The result is a different security model: rather than attempting to recreate the traditional corporate perimeter around every cloud application, the security control works directly with the cloud application’s data, users, and APIs.

That distinction is central to understanding why CloudLock is fundamentally a cloud-native security control rather than simply another network firewall.

ENGINEER'S MENTAL MODEL

How to Think About CloudLock

Cloud security is easier to reason about when visibility, analysis, policy and response are treated as a continuous engineering process rather than isolated security features.

Learning Objective
Use the five-stage model to move from cloud visibility to security response, then build a contextual decision using identity, application, data and behaviour signals.
Current Engineering Stage
1. Discover

Start with visibility. Identify cloud applications, users, data, access patterns and cloud activity. The objective is to understand what exists before attempting to control it.

The Four Questions an Engineer Should Ask
WHO?
Which user or identity is performing the activity?
WHAT?
What application and data are involved?
HOW?
What behaviour or context makes the activity normal or risky?
Build the Security Decision
0 / 4 selected
0 Context Score
A strong cloud-security decision requires context. Select Identity, Application, Data and Behaviour to build the decision model.
Cloud Security Decision Console
READY
Decision model ready. Select contextual signals.

Cloud Visibility

Cloud Security Visibility and Context

The three security capabilities described above address different parts of the cloud-security problem, but they share a common requirement: visibility with context.

Knowing that a user connected to a cloud application is useful, but it is not enough to determine whether the activity represents a security risk.

A modern cloud-security control needs to understand several pieces of information at the same time:

Identity: Who is performing the activity?

Application: Which cloud service or SaaS application is involved?

Data: What information is being accessed, uploaded, downloaded, or shared?

Behaviour: Is the activity consistent with the user’s normal behaviour?

Context: Where is the user connecting from, what device are they using, and does the activity present additional risk?

Policy: Is the requested action permitted by the organization?

Together, these elements create a more useful security model than simply allowing or denying a network connection.

For example, consider a user who normally accesses a small number of documents from a corporate laptop during working hours. The same user account suddenly downloads thousands of sensitive files from a new location and attempts to share them with an external account.

The network connection itself may be legitimate.

The identity may also be legitimate.

The application may be authorized.

But when identity, application, data, behaviour, and context are considered together, the activity becomes significantly more suspicious.

This is where cloud security moves beyond traditional perimeter thinking.

The security question is no longer simply:

“Can this user connect to the application?”

It becomes:

“Is this user performing an action that is consistent with policy and acceptable risk?”

This distinction is important because cloud security is increasingly concerned with what happens after access has been granted. A user can be authenticated, the application can be approved, and the network connection can be legitimate while the activity itself still violates organizational policy.

A CASB such as CloudLock helps provide the visibility required to evaluate this activity within the cloud environment. By combining information about users, applications, data, and activity, security teams can apply policy based on more than network location alone.

The resulting security workflow can be represented as:

Visibility → Analysis → Policy → Security Response

This provides the foundation for a more contextual approach to cloud security.

The traditional network perimeter still has an important role, but it cannot provide all of the context required to understand modern SaaS activity. Security controls must increasingly understand what is happening inside the cloud service, not simply whether traffic is travelling towards it.

That is the fundamental shift from network-centric security to cloud-aware security: the security decision is increasingly based on the relationship between identity, application, data, behaviour, context, and policy.

Cloud Security Decision Builder

Connect the Context. Make the Security Decision.

Cloud security decisions become stronger when identity, application, data and behaviour are considered together. Select the context an engineer would investigate before applying policy.

Learning Objective Build a contextual security decision by connecting identity, application, data, behaviour and risk context before determining the appropriate policy response.

1. Select Investigation Context

Choose the information available to the security team during a cloud-security investigation.

Select multiple context elements to construct the cloud-security decision chain.

Security Assessment

More relevant context produces a stronger basis for policy decisions.

Decision Confidence
0%
Awaiting investigation
Select the context available to the security team, then evaluate the decision.
Cloud Security Console
[READY] Cloud security decision workspace initialised. [WAIT] Select investigation context.
Engineer’s Takeaway A strong cloud-security decision is rarely based on one signal. Identity, application, data, behaviour and context provide the evidence required to determine whether activity is consistent with policy and acceptable risk.
rsz_1moving_thrugh_thr_layer

Network Connectivity

Network Connectivity

Modern applications depend on connectivity.

Whether a user is opening a web application, a Kubernetes workload is communicating with another service, a database is replicating across a data centre, or a cloud platform is reaching an on-premises system, the underlying requirement is the same: data must move reliably from one endpoint to another.

That sounds simple. In modern infrastructure, it rarely is.

A packet may pass through switches, routers, routing domains, security boundaries, load balancers, tunnels, overlays and cloud networks before reaching its destination. Along the way, the network must resolve neighbours, select routes, apply policy, enforce security controls, handle MTU constraints and establish the appropriate transport or application session.

Connectivity is therefore much more than having an IP address and a reachable interface.

A useful way to understand modern networking is as a chain of dependent decisions:

CONNECT → RESOLVE → ROUTE → SECURE → TRANSPORT → DELIVER → OBSERVE

Each stage depends on the others. An interface must be operational before traffic can leave a host. Neighbour discovery must succeed before the next hop can be reached. Routing must select a valid path. Security policy must permit the traffic. NAT, tunnelling or segmentation may alter how the packet travels. Transport protocols must establish communication where required, and the application must ultimately be available and responding.

A failure at any one of these stages can produce the same familiar symptom:

“The application is unreachable.”

The challenge for a network engineer is determining where the failure actually occurred.

Traditional networking is often taught as a collection of individual technologies: Ethernet, VLANs, IPv4, IPv6, ARP, TCP, UDP, OSPF, BGP, firewalls and NAT. These technologies remain fundamental, but production connectivity is created by their interaction.

A packet can move from a container through a virtual interface, across an Open vSwitch datapath, through a Kubernetes service, across a VXLAN overlay, through an EVPN-controlled fabric, into a WAN, across a cloud routing domain and eventually toward an application endpoint.

The individual protocols have not disappeared. They have become layers within a much larger connectivity system.

Modern networks also require an understanding of the relationship between the control plane and the data plane. The control plane determines what should happen. Routing protocols exchange information, calculate paths, apply policy and build routing state. The data plane executes those decisions using forwarding tables, neighbour information, ACLs, firewall rules, NAT state and switching or routing pipelines.

This distinction becomes particularly important when troubleshooting.

A routing protocol can be healthy while forwarding is incorrect. A route can exist while an ACL blocks the packet. A TCP session can fail even though IP connectivity works. A service can be unreachable even though every network hop appears healthy.

Control-plane correctness does not automatically guarantee application connectivity.

Modern connectivity failures are rarely caused by one technology in isolation. Incorrect addressing, VLAN configuration, missing ARP or IPv6 neighbour discovery, routing decisions, asymmetric paths, VRF segmentation, BGP or IGP policy, ACLs, firewalls, NAT, MTU problems, DNS, Kubernetes networking, cloud route tables, overlay tunnels and application health can all influence the final result.

This creates an important engineering principle:

Troubleshoot connectivity as a chain of dependencies, not as a collection of isolated devices.

Instead of asking only, “Is the router working?”, the better questions are:

Where is the packet now?

What is the next hop?

Which control plane made the decision?

What does the data plane actually do?

Which policy could stop the packet?

Where does the packet disappear?

What evidence proves the failure?

That mindset scales from a small LAN to a data-centre fabric, a WAN, a cloud environment or a Kubernetes platform.

This article takes a practical approach to understanding that connectivity chain. Rather than treating networking as a collection of static diagrams, the interactive sections allow you to follow what happens to traffic as it moves through a modern network.

You will examine how packets are encapsulated and forwarded, how routing and neighbour resolution influence the next hop, how security and transport affect connectivity, how routing control planes build forwarding state, and how cloud-native platforms introduce additional networking layers.

The later investigations deliberately introduce failures so that connectivity can be analysed from the perspective of an engineer troubleshooting a real system.

The objective is not simply to memorise protocols.

It is to develop a repeatable way of thinking:

What is the source? What is the destination? What is the next hop? Which decision was made? Where did the packet stop? Why did it stop? What evidence proves it?

Modern infrastructure is no longer a collection of isolated networks. It is a distributed connectivity fabric spanning hosts, switches, routers, security systems, WANs, data centres, cloud platforms, containers and applications.

Understanding how those layers interact is one of the most important foundations for modern network engineering.

The goal is simple:

Follow the packet. Understand the decision. Find the failure. Prove the result.

Highlights: Network Connectivity

Network Connectivity · Technical Learning Path

Connectivity Engineering Journey

Move from packet fundamentals through routing, cloud-native networking and finally into structured connectivity investigation.

01
Connectivity Foundations
→

Understand how a packet is created, encapsulated, switched, routed and delivered across a network.

Ethernet ARP / NDP Switching Routing
Interactive Lab Packet & Protocol Explorer
02
Addressing, Transport & Security
→

Follow the dependencies between addressing, neighbour discovery, ACLs, firewalls, NAT, MTU and transport.

IPv4 / IPv6 TCP / UDP ACL NAT
Interactive Lab Connectivity Decision Engine
03
Routing & Network Fabric
→

See how routing protocols become forwarding state and how VRFs, overlays and fabrics extend connectivity.

OSPF IS-IS BGP VXLAN / EVPN
Interactive Lab Routing & Fabric Explorer
04
Cloud-Native Networking
→

Trace traffic through namespaces, veth pairs, CNI networking, datapaths, services and policy.

Kubernetes CNI OVS NetworkPolicy
Interactive Lab Cloud-Native Network Explorer
05
Connectivity Investigation
→

Investigate an unreachable application by proving where the connectivity chain breaks and why.

Evidence Failure Domain Packet Path Root Cause
Capstone Investigation Network Failure Investigator
Live Connectivity Flow
Packet Moving Through the Network
Network Activity
ENDPOINT
ROUTER
CORE
SERVICE
APPLICATION
BACKUP
CLOUD
Network Connectivity · Foundation Map

How Connectivity Is Built

Before following an individual packet, understand the chain of decisions that allows an application to communicate. Select a layer to see what it contributes to the end-to-end connectivity path.

End-to-End Connectivity Stack
Select a layer
Application
Transport
IP
Resolve
Link
Switch
Route
Current Layer
07 / 07
SERVICE LAYER

Application

The application is the reason connectivity exists. A successful network path ultimately has to deliver traffic to a usable service such as HTTP, DNS, an API endpoint or a database.
Question
Is the service actually available?
Evidence
Response / timeout / application error
Decision
Deliver to the correct service
Next Dependency
Transport session
Engineering Clue
An application timeout does not automatically mean the network is broken. The failure may exist anywhere lower in the dependency chain.
Network Connectivity · Interactive Lab 01

Packet & Protocol Explorer

Follow one packet from application data through Ethernet, switching, routing and final delivery.

Ready
0 / 12
LIVE PACKET PATH
IPv4 · TCP · Ethernet
HOST
Client
10.10.10.10
SW
SW1
L2 Forwarding
R1
Router
L3 Routing
APP
Server
10.20.20.20
Packet waiting at source
Current Decision READY
00
Ready to send
Step through the packet path to see each connectivity decision.
Start by identifying the source, destination and required next hop.
Live Telemetry PACKET STATE
10.10.10.10
10.20.20.20
—
—
—
Application
Packet Lifecycle WAITING
01 Application
02 TCP
03 IPv4
04 ARP
05 Ethernet
06 Switch
07 Router
08 Route
09 New L2
10 Server
11 TCP
12 Application
Engineering principle: Layer 2 delivers across the local link; Layer 3 determines the routed path.

Network Connectivity

Modern network connectivity is not simply the ability to reach an IP address.

A successful network flow depends on a chain of decisions and transformations that begin at the endpoint and continue through switching, routing, security, transport and application services.

A useful engineering model is:

CONNECT → RESOLVE → ROUTE → SECURE → TRANSPORT → DELIVER → OBSERVE

Each stage can fail independently.

A host can have a valid IP address but no Layer 2 connectivity. A gateway can be reachable while the destination route is missing. A route can exist while a firewall blocks the flow. TCP can establish successfully while the application itself fails.

Understanding connectivity therefore requires understanding the complete forwarding path rather than testing a single protocol in isolation.

The Modern Connectivity Fabric

A modern enterprise flow may cross several network domains before an application response reaches the user:

Endpoint → Access Network → Switching → Routing → Security → WAN/Cloud → Platform → Application

The physical path may involve Ethernet or Wi-Fi at the edge, VLANs and trunks inside the local network, routed interfaces and VRFs through the infrastructure, firewalls and security policies at trust boundaries, and overlays such as VXLAN across a data-centre fabric.

The destination may then reside inside a cloud VPC, a Kubernetes cluster, a virtual machine, a container or a distributed application.

Connectivity is therefore better understood as a fabric of forwarding domains and control planes than as a single network.

End-to-End Connectivity Model
Layer / DomainPrimary FunctionTypical Technologies
EndpointGenerates and receives trafficOS networking, sockets, NIC
AccessProvides local attachmentEthernet, Wi-Fi, VLAN
SwitchingMoves frames within Layer 2MAC tables, 802.1Q, STP
RoutingSelects Layer 3 pathsOSPF, IS-IS, BGP, static routes
SegmentationSeparates routing domainsVRF, VLAN, tenant networks
SecurityApplies traffic policyACL, firewall, security groups
TransportEstablishes communicationTCP, UDP, QUIC
WAN / CloudExtends connectivity domainsVPN, SD-WAN, VPC, transit
PlatformConnects workloadsKubernetes, CNI, service networking
ApplicationProvides the actual serviceHTTP, TLS, DNS, APIs

The important point is that these layers are related but not interchangeable.

Routing does not replace firewall policy. A successful ping does not prove that an HTTPS application works. DNS resolution does not prove that the destination port is reachable.

Each layer provides evidence about a different part of the connectivity chain.

What Actually Happens to a Packet

When an application sends data, the application does not normally construct an Ethernet frame itself.

Instead, data is progressively encapsulated as it moves down the networking stack.

Application data

↓

TCP segment / UDP datagram

↓

IP packet

↓

Ethernet frame

↓

Physical or virtual transmission

At the destination, the process is reversed through decapsulation.

Frame → IP packet → Transport data → Application data

This distinction is important when troubleshooting because each layer exposes different failure conditions.

For example:

  • An Ethernet problem may prevent the frame from reaching the next hop.

  • An IP routing problem may send the packet toward the wrong destination.

  • A firewall may intentionally discard the packet.

  • TCP may fail even though IP connectivity exists.

  • TLS may fail after TCP succeeds.

  • The application may return an error even though every lower layer is functioning correctly.

Packet Anatomy

An IPv4 packet carried inside an Ethernet frame can contain information such as:

Ethernet

  • Source MAC address

  • Destination MAC address

  • 802.1Q VLAN tag, when present

  • EtherType

IPv4

  • Source IP address

  • Destination IP address

  • TTL

  • Protocol

  • Fragmentation fields

  • Header checksum

TCP

  • Source port

  • Destination port

  • Sequence number

  • Acknowledgement number

  • Window

  • TCP flags

  • MSS and other negotiated options

The fields are used for different decisions.

The destination MAC address is relevant to the local Layer 2 hop.

The destination IP address identifies the Layer 3 destination.

The TCP destination port identifies the transport service.

This is why a routed packet can change its Ethernet header at every Layer 3 hop while its destination IP normally remains unchanged from end to end.

Encapsulation and Decapsulation

Consider a client accessing:

10.20.30.40:443

The application generates data for an HTTPS session.

The host creates a TCP segment with:

Source Port → Ephemeral client port

Destination Port → 443

The TCP segment is placed inside an IP packet:

Source IP → Client address

Destination IP → 10.20.30.40

The IP packet is then placed inside an Ethernet frame.

If the destination is on another subnet, the Ethernet destination is normally the MAC address of the local next-hop gateway, not the MAC address of 10.20.30.40.

The router receives the frame, removes the Layer 2 header, examines the destination IP address, performs a forwarding lookup and constructs a new Layer 2 frame for the next link.

This process repeats at each routed hop.

The key engineering principle is:

Layer 2 delivers the frame to the next local hop. Layer 3 determines where the packet needs to go.

Switching and Layer 2 Connectivity

Before routing can occur, many network flows must first cross a Layer 2 segment.

Ethernet switches build forwarding decisions using learned MAC addresses.

When a frame arrives, a switch can conceptually perform this sequence:

Receive frame

→ Learn source MAC

→ Identify VLAN

→ Search destination MAC

→ Apply forwarding policy

→ Select egress interface

→ Transmit frame

The switch therefore maintains a forwarding database containing relationships such as:

MAC address → VLAN → switch port

This table is learned dynamically from observed traffic.

MAC Learning

Suppose a frame arrives from host A:

AA:AA:AA:AA:AA:01

on switch port 10.

The switch can learn:

AA:AA:AA:AA:AA:01 → Port 10

If host B is already known on port 20, traffic destined for B can be forwarded directly to port 20.

If the destination MAC is unknown, the switch may flood the frame within the relevant Layer 2 broadcast domain, subject to the VLAN and forwarding rules.

This is one reason large Layer 2 domains can become operationally complex.

Unknown unicast traffic, broadcast traffic and multicast traffic can all consume resources across the same domain.

VLANs and Trunks

VLANs provide logical Layer 2 segmentation.

An access interface normally associates an endpoint with a particular VLAN.

A trunk can carry multiple VLANs between network devices using IEEE 802.1Q tagging.

Conceptually:

Access Port

Endpoint → VLAN 20

Trunk

VLAN 10
VLAN 20
VLAN 30
VLAN 40

The VLAN identifier allows switches to keep otherwise shared physical infrastructure logically separated.

However, a VLAN is not a complete security boundary by itself.

When traffic must move between VLANs, a Layer 3 gateway or routing function is required.

Layer 2 Failure Domains

Layer 2 connectivity introduces its own failure modes.

Examples include:

  • Incorrect VLAN assignment

  • Trunk allowed-VLAN mismatch

  • Native VLAN mismatch

  • MAC learning problems

  • Layer 2 loops

  • STP convergence

  • Broadcast storms

  • Unknown-unicast flooding

  • Port security violations

  • Physical interface errors

A host can therefore have a perfectly configured IP address while remaining unreachable because its Ethernet frame never reaches the correct Layer 3 gateway.

Routing and Forwarding

Routing answers a fundamental question:

Where should this IP packet go next?

The answer is not normally determined by the application.

It is determined by the network’s routing and forwarding mechanisms.

A router can maintain many routes to different destinations. These routes may originate from:

  • Connected interfaces

  • Static configuration

  • OSPF

  • IS-IS

  • EIGRP

  • BGP

  • Policy-based mechanisms

  • Other routing sources

The routing system must determine which route should become the active path.

The forwarding system then uses that decision for individual packets.

Control Plane and Data Plane

The distinction between control plane and data plane is fundamental.

Control Plane

The control plane learns and calculates reachability.

Examples:

  • OSPF neighbour relationships

  • IS-IS adjacencies

  • BGP sessions

  • Static routes

  • Route policies

  • BGP path selection

The result contributes to the device’s routing information.

Data Plane

The data plane forwards individual packets.

It uses the resulting forwarding information to determine:

Destination → Prefix match → Next hop → Egress interface

The control plane can therefore be thought of as determining what should be reachable, while the data plane determines how each packet is actually forwarded.

RIB → Best Route → FIB

A simplified routing process looks like this:

Routing Information Sources

↓

RIB

↓

Best Route Selection

↓

FIB

↓

Longest Prefix Match

↓

Next Hop

↓

Adjacency

↓

Forwarding

The RIB represents the routing information used by the control plane.

The best-path process determines which route should be installed as the preferred route.

The resulting forwarding information is then programmed into the FIB or equivalent forwarding structure used by the data plane.

The exact implementation differs between operating systems and hardware platforms, but the conceptual separation is extremely useful when troubleshooting.

Longest Prefix Match

When a packet arrives, the router does not simply choose the route with the numerically smallest network address.

It performs a Longest Prefix Match against the destination IP address.

For example, imagine a routing table contains:

10.0.0.0/8

10.20.0.0/16

10.20.30.0/24

A packet destined for:

10.20.30.50

matches all three prefixes.

The most specific route is:

10.20.30.0/24

Therefore the /24 wins the forwarding lookup.

This mechanism allows broad summary routes to coexist with more specific paths.

Recursive Next-Hop Resolution

A routing entry may not always point directly to an outgoing interface.

A route can instead identify a next-hop IP address that must itself be resolved through another route.

For example:

10.50.0.0/16

→ Next hop 192.0.2.10

The router must determine how to reach 192.0.2.10 before it can forward traffic toward 10.50.0.0/16.

This is known as recursive next-hop resolution.

The final forwarding decision may therefore involve several pieces of information:

Destination prefix

→ Best route

→ Resolved next hop

→ Outgoing interface

→ Layer 2 adjacency

→ Frame transmission

ECMP

Modern networks frequently use Equal-Cost Multi-Path, or ECMP.

Instead of maintaining one usable path, a router may have multiple paths with equivalent forwarding cost.

Conceptually:

Destination

→ Path A

→ Path B

→ Path C

Traffic can then be distributed across those paths according to the platform’s hashing and load-balancing behaviour.

ECMP is widely used in data-centre, service-provider and cloud architectures because it provides both scalability and path redundancy.

It also introduces an important troubleshooting consideration:

Different flows may take different paths.

A problem affecting only one ECMP path can therefore produce intermittent or flow-specific connectivity failures.

Engineering Insight

Connectivity is a chain of independent decisions.

A useful troubleshooting mindset is to avoid asking only:

“Can I ping it?”

Instead ask:

Can I reach the local network?

Can I resolve the neighbour?

Does a route exist?

Which next hop was selected?

Is the packet permitted by policy?

Can the transport session establish?

Can the application complete its transaction?

Each answer narrows the failure domain.

A successful ping proves that a particular ICMP exchange succeeded.

It does not automatically prove that TCP/443, DNS, an API endpoint, authentication or the application itself will work.

The First Connectivity Decision

For every network flow, the infrastructure is ultimately trying to answer a sequence of questions:

Who is sending?

→ Source addressing

Where is the destination?

→ Destination addressing

Is the destination local?

→ Subnet decision

If not, where is the next hop?

→ Routing

Can the next hop be reached locally?

→ ARP / NDP / adjacency

Is the traffic allowed?

→ ACL / firewall / security policy

Can the transport session establish?

→ TCP / UDP / QUIC

Can the application communicate?

→ DNS / TLS / HTTP / application protocol

This layered decision process is the foundation for everything that follows in modern network connectivity.

The next stage is to examine what happens when the flow leaves basic Layer 2 and Layer 3 forwarding and encounters IPv4/IPv6 behaviour, transport protocols, MTU constraints, security policy and asymmetric paths.

Connectivity Decision Engine

Network Connectivity · Dependency Map

What Must Work Before the Application Can Connect?

Connectivity is a chain of dependencies. Select a component to see what it provides, what evidence proves it is working, and what kind of failure it can create.

Connectivity Dependency Chain
Click any dependency
Address → Resolve → Route → Permit → Translate → Fit → Connect → Serve
Dependency Detail
01 / 08
FOUNDATION

Addressing

The endpoint needs a valid IPv4 or IPv6 address and an appropriate network configuration before meaningful communication can begin.
Engineer asks
Does the endpoint have the expected address?
Evidence
Interface and address configuration
Depends on
Interface state
Next
ARP / NDP
Failure signature
Incorrect addressing can prevent local communication, create incorrect routing assumptions or send traffic toward the wrong network.
Network Connectivity · Interactive Lab 02

Connectivity Decision Engine

Follow an application connection through every dependency and deliberately introduce failures.

Healthy
1 / 10
End-to-End Connectivity Path
READY
01
NIC
Interface
Ready
→
02
ARP
ARP / NDP
Waiting
→
03
RIB
Route
Waiting
→
04
ACL
ACL Policy
Waiting
→
05
FW
Firewall
Waiting
06
NAT
NAT
Waiting
→
07
MTU
MTU / PMTUD
Waiting
→
08
TCP
TCP Session
Waiting
→
09
DNS
Name / Service
Waiting
→
10
APP
Application
Waiting
Current Investigation
01
Interface state
Confirm the source interface is operational before testing higher layers.
Evidence: interface is UP and has a valid address.
Inject Failure
Source
10.10.10.10
Destination
app.network.local
Connectivity Result
Awaiting test

Transport, Addressing and Security

The forwarding model explains how a packet moves through the network, but successful connectivity requires more than a valid route.

Once a packet has left the local switching domain, it can encounter addressing decisions, neighbour discovery, transport protocols, security controls, translation devices and path characteristics such as MTU.

This is where many real-world connectivity problems become more subtle.

IPv4 Connectivity

IPv4 provides the Layer 3 addressing model used by a large proportion of enterprise and internet-connected systems.

An IPv4 address consists of a 32-bit value represented in dotted-decimal notation, for example:

192.0.2.25

The address is interpreted together with a prefix length.

For example:

192.0.2.25/24

The /24 identifies the network prefix while the remaining bits identify the host within that prefix.

The host uses its local prefix to determine whether a destination is directly connected.

If the destination is local, the host attempts to resolve the destination’s Layer 2 address.

If the destination is remote, the host normally sends the packet toward its configured default gateway.

This creates the first major endpoint routing decision:

Destination in local subnet → resolve destination neighbour

Destination outside local subnet → resolve default gateway

ARP and IPv4 Neighbour Resolution

IPv4 hosts use Address Resolution Protocol (ARP) to map an IPv4 address to a local Layer 2 address.

A simplified process is:

Who has 192.0.2.1?

↓

192.0.2.1 is at AA:BB:CC:DD:EE:FF

The result is normally stored in an ARP cache for a period of time.

ARP operates only within the local Layer 2 domain.

A router does not normally forward an ARP request across routed interfaces.

This distinction is important when troubleshooting.

A host may successfully resolve its default gateway while still being unable to reach the remote destination because the actual problem exists farther along the routed path.

ARP also introduces its own failure modes:

  • Incorrect or stale neighbour information

  • Duplicate IP addresses

  • VLAN mismatch

  • Layer 2 isolation

  • ARP filtering

  • Proxy ARP behaviour

  • ARP inspection or security controls

An ARP problem therefore belongs to the local connectivity domain, not automatically to the remote destination.

IPv6 Connectivity

IPv6 expands the address space to 128 bits and changes several aspects of neighbour discovery and address configuration.

An IPv6 address might appear as:

2001:db8:100:20::25/64

IPv6 replaces ARP with Neighbor Discovery Protocol (NDP), which operates using ICMPv6.

NDP provides several functions, including:

  • Neighbor discovery

  • Router discovery

  • Address resolution

  • Duplicate Address Detection

  • Router Advertisement processing

  • Prefix discovery

Unlike IPv4 ARP, IPv6 neighbour discovery uses multicast rather than broadcast.

Solicited-Node Multicast

When an IPv6 interface needs to discover a neighbour, it can use a solicited-node multicast address derived from the target address.

The multicast group uses the low-order 24 bits of the IPv6 address.

Conceptually:

Target IPv6 address

↓

Low 24 bits

↓

FF02::1:FFxx:xxxx

This allows neighbour discovery to be more targeted than a general Layer 2 broadcast.

Stateless Address Autoconfiguration

IPv6 hosts can automatically configure addresses using Stateless Address Autoconfiguration (SLAAC).

Router Advertisements provide information such as:

  • IPv6 prefixes

  • Default router information

  • Address configuration behaviour

  • Other network parameters

DHCPv6 can also be used where additional configuration or managed address assignment is required.

A useful troubleshooting distinction is therefore:

Address exists

does not necessarily mean:

Default router exists

and neither necessarily means:

Remote IPv6 connectivity works

IPv6 introduces an additional operational requirement: security and monitoring systems must explicitly support IPv6.

A network that is carefully secured for IPv4 but poorly controlled for IPv6 can create an unintended parallel connectivity path.

Transport Connectivity

IP forwarding provides reachability between addresses.

Transport protocols provide communication between applications.

This distinction is critical.

A successful ICMP test does not prove that an application service is available.

For example:

Ping succeeds

but:

TCP/443 fails

The network may therefore be capable of forwarding packets while the specific service remains inaccessible.

TCP

TCP provides connection-oriented transport.

A typical connection begins with the three-way handshake:

Client → SYN

↓

Server → SYN/ACK

↓

Client → ACK

Only after the handshake has completed can the application exchange normal TCP payload.

This creates useful troubleshooting evidence.

If a SYN leaves the client but no response returns, possible causes include:

  • Routing failure

  • Packet filtering

  • Firewall policy

  • Destination host unavailable

  • Service not listening

  • Return-path failure

  • Asymmetric routing

  • Security device behaviour

If a SYN/ACK returns but the final ACK does not arrive at the server, the problem may exist in the reverse direction.

TCP therefore provides more detailed evidence than a simple ping test.

TCP Failure Signals

Several TCP behaviours can help identify the failure domain.

SYN timeout

Often indicates filtering, routing failure, host unavailability or a missing return path.

TCP RST

Usually indicates that the connection was actively rejected or reset by a host or intermediary.

Successful handshake followed by application failure

Suggests that Layer 3, Layer 4 and basic session establishment are working, moving the investigation toward TLS, authentication or the application itself.

Retransmissions

Can indicate packet loss, congestion, MTU problems, asymmetric paths or a poorly performing link.

High RTT

Can indicate physical distance, congestion, suboptimal routing or overloaded infrastructure.

The important point is that TCP provides another diagnostic layer between IP reachability and application functionality.

UDP and QUIC

UDP is connectionless and does not provide TCP-style delivery guarantees.

Applications can therefore implement their own reliability, ordering or session mechanisms.

Modern protocols such as QUIC use UDP as their transport substrate while implementing encrypted, reliable transport behaviour above it.

QUIC is particularly important because modern web traffic can use:

HTTP/3 → QUIC → UDP → IP

This means a network engineer troubleshooting application connectivity cannot assume that modern HTTPS traffic always uses TCP/443.

Protocol awareness matters.

MTU, MSS and PMTUD

Packet size is another major source of connectivity problems.

Every network path has a Maximum Transmission Unit (MTU).

For standard Ethernet, the commonly encountered IP MTU is:

1500 bytes

However, tunnels and overlays can reduce the effective payload capacity because additional headers are introduced.

For example:

Original packet

↓

GRE / VXLAN / IPsec encapsulation

↓

Additional headers

↓

Larger transmitted frame

If the underlying path cannot carry the resulting packet, fragmentation or packet loss can occur depending on the protocol and configuration.

TCP also negotiates a Maximum Segment Size (MSS), which helps control the amount of TCP payload placed into each segment.

Path MTU Discovery attempts to determine the largest packet that can traverse the path without fragmentation.

The Classic MTU Failure

One particularly useful diagnostic pattern is:

Small packets work

Large packets fail

This should immediately raise suspicion around:

  • MTU mismatch

  • MSS configuration

  • PMTUD

  • Fragmentation

  • ICMP filtering

  • Tunnel overhead

  • Overlay encapsulation

This is why a basic ping can be misleading.

A small ICMP packet succeeding does not prove that a large application transaction can traverse the same path.

Security and Connectivity

Security controls are part of the connectivity path.

A packet can have:

  • A valid source address

  • A valid destination address

  • A valid route

  • A functioning next hop

and still be intentionally dropped by policy.

This means routing and security must be investigated separately.

ACLs

An Access Control List evaluates traffic against defined criteria.

Typical matching fields can include:

  • Source address

  • Destination address

  • Protocol

  • Source port

  • Destination port

  • Direction

  • Interface or security context

A simplified policy might represent:

Source: 10.10.10.0/24

Destination: 10.20.20.0/24

Protocol: TCP

Destination Port: 443

Action: Permit

ACLs are generally stateless unless additional platform mechanisms provide state tracking.

That distinction matters.

An ACL can permit or deny packets based on their characteristics, while a stateful firewall can maintain connection state and make decisions based on whether traffic belongs to an established session.

Stateful Firewalls

A stateful firewall maintains information about active flows.

Conceptually:

Client → SYN → Firewall → Server

The firewall records the session.

When the return traffic arrives:

Server → SYN/ACK → Firewall → Client

the firewall can associate it with the existing connection state.

This is fundamentally different from evaluating every packet as an isolated event.

Stateful inspection introduces additional failure conditions:

  • Session state mismatch

  • NAT state mismatch

  • Return traffic using a different firewall

  • Expired session

  • Policy mismatch

  • Asymmetric routing

This is why a routing change can unexpectedly break an otherwise valid TCP session.

Asymmetric Routing

Consider a flow where the outbound path is:

Client → Firewall A → Server

but the return path is:

Server → Firewall B → Client

The routing may technically be valid in both directions.

However, if Firewall B does not have the corresponding session state, it may reject the return traffic.

The result can look like:

Forward path works

Return path fails

TCP never completes

This is an important distinction between routing reachability and stateful connectivity.

Asymmetric routing can occur because of:

  • ECMP

  • BGP path selection

  • Multiple WAN links

  • Multiple firewalls

  • Load balancers

  • Cloud routing

  • Policy-based routing

  • Data-centre fabric design

A connectivity investigation should therefore examine both directions of the path.

NAT and Address Translation

Network Address Translation changes addressing information as traffic crosses a translation boundary.

Common examples include:

Private IPv4 → Public IPv4

and:

Public IPv4 → Internal service

NAT can conserve IPv4 address space and provide publishing mechanisms, but it should not automatically be treated as a security control.

Security comes from explicit policy enforcement.

NAT also introduces state.

A translation device may maintain mappings such as:

Inside address:port

↓

Translated address:port

This state must remain valid for the duration of the flow.

NAT problems can therefore appear as:

  • Connection establishment failure

  • Return traffic dropped

  • Incorrect destination translation

  • Port exhaustion

  • Stale translation state

  • Protocol incompatibility

Identity and Application-Level Connectivity

Not every connectivity decision belongs in the network layer.

Modern applications increasingly make decisions using identity, application metadata and service-level information.

For example:

Client

↓

TLS

↓

Reverse Proxy / API Gateway

↓

Application

The gateway may inspect:

  • Hostname

  • URL

  • HTTP method

  • Authentication token

  • Application headers

  • Client identity

  • Service identity

This is different from IP routing.

An API gateway can decide:

Request for api.example.com

→ Service A

while the underlying network still performs ordinary Layer 3 forwarding between the client, gateway and service.

Trust Boundaries

Private addressing does not automatically mean trusted traffic.

An RFC1918 address such as:

10.10.20.50

may represent an employee workstation, a server, a container, a cloud workload or an untrusted system.

Security decisions should therefore be based on explicit policy and identity rather than simply assuming:

Private IP = Trusted

Similarly, application headers such as X-Forwarded-For should only be trusted when they originate from a known and controlled proxy chain.

IPv4 and IPv6 Transition

Modern networks often operate IPv4 and IPv6 simultaneously.

The simplest model is dual stack.

A host can have:

IPv4 address

and:

IPv6 address

and select an appropriate protocol based on application and operating-system behaviour.

Other technologies provide interoperability between IPv6-only and IPv4-only environments.

NAT64 and DNS64

NAT64 can allow an IPv6-only client to communicate with an IPv4-only destination.

DNS64 can synthesize an IPv6 representation of an IPv4 destination so that the client can initiate an IPv6 connection.

Conceptually:

IPv6-only client

↓

DNS64

↓

IPv6 representation

↓

NAT64

↓

IPv4 server

This is fundamentally different from ordinary IPv4 NAT because the mechanism provides protocol-family translation.

NPTv6

NPTv6 provides IPv6-to-IPv6 prefix translation.

It can be used where an organisation needs to translate one IPv6 prefix into another without performing IPv4/IPv6 protocol conversion.

This makes NPTv6 a very different technology from NAT64.

GRE and IPsec

GRE provides encapsulation.

It can carry one packet inside another packet and is commonly used to create logical tunnels across routed infrastructure.

GRE itself does not provide encryption.

IPsec provides security mechanisms such as authentication and encryption.

They can therefore be combined:

Original traffic

↓

GRE encapsulation

↓

IPsec protection

↓

Transport network

The exact design depends on the platform and deployment requirements.

Legacy Transition Technologies

Technologies such as 6to4 are historically important but should not normally be treated as modern default deployment mechanisms.

Understanding legacy technologies remains useful when troubleshooting older infrastructure or interpreting historical designs.

The Connectivity Failure Chain

At this point, the complete dependency chain becomes visible:

Layer 2

Can the host reach its local next hop?

↓

Layer 3

Does a route exist?

↓

Neighbour Resolution

Can the next-hop address be resolved?

↓

Security

Is the flow permitted?

↓

Transport

Can TCP, UDP or QUIC communicate?

↓

Application

Can the service actually complete the request?

↓

Performance

Are latency, loss, MTU or congestion affecting the transaction?

A failure at any earlier stage can prevent every stage above it from succeeding.

This is why troubleshooting from the application downward without understanding the underlying forwarding path can produce misleading conclusions.

Failure Clue

A particularly useful engineering technique is to classify the symptom before changing configuration.

Ping fails

Investigate addressing, Layer 2, routing, ICMP policy and return path.

Ping works but TCP/443 fails

Investigate service availability, ACLs, firewall policy, NAT and TCP state.

TCP connects but the application fails

Investigate TLS, DNS, authentication, application policy and backend dependencies.

Small packets work but large packets fail

Investigate MTU, MSS, PMTUD and tunnel overhead.

Outbound works but return traffic fails

Investigate asymmetric routing, stateful inspection and return-path routing.

IPv4 works but IPv6 fails

Investigate NDP, Router Advertisements, IPv6 routing and IPv6 security policy.

The symptom itself becomes evidence.

Engineering Perspective

Modern connectivity is therefore a layered decision system rather than a single routing problem.

The network must determine:

Who is communicating?

Where is the destination?

Which path should be used?

Can the next hop be reached?

Is the flow permitted?

Can the transport session establish?

Can the application complete the transaction?

Can the entire path sustain the required traffic?

Once these questions are separated, complex failures become much easier to isolate.

The next layer of the architecture is the control plane that builds those paths at scale — including OSPF, IS-IS, BGP, VRFs, data-centre fabrics, VXLAN/EVPN, WAN architectures and cloud routing.

Routing and Fabric Explorer

Network Connectivity · Routing Architecture

From Routing Protocols to the Modern Network Fabric

Modern networks combine routing protocols, forwarding tables, segmentation, overlays and external connectivity. Select a stage to see how the control plane becomes an actual forwarding path.

Modern Routing Architecture
Select a stage
→
→
→
→
Architecture Detail
01 / 06
CONTROL PLANE

OSPF · IS-IS · BGP

Routing protocols build the control-plane knowledge used to determine how destinations should be reached. Different protocols operate at different scopes and apply different path-selection and policy models.
Question
What paths are available?
Evidence
Neighbours, routes and policy
Produces
Routing information
Next
RIB best-path selection
Engineering Perspective
A routing protocol being established does not prove that application traffic will successfully reach its destination. Control-plane state must become usable forwarding state.
Network Connectivity · Interactive Lab 03

Routing & Fabric Explorer

Follow a destination prefix from routing protocols through the RIB and FIB into an underlay, overlay and tenant forwarding path.

Stable
Decision 1 / 6
HOST
Source
10.10.10.20
→
Destination Prefix
10.40.40.0/24
APP
01 · Control Plane Which routing information is available?
OSPF Evaluating
Interior Path
Provides an internal route toward the destination network.
BGP Waiting
Policy Path
Candidate path carries policy attributes and an AS path.
IS-IS Waiting
Fabric Path
Underlay reachability provides transport between fabric nodes.
02 · Routing State Control-plane information becomes forwarding state.
RIB
Routing Information Base
Best route selected
Competing routes are evaluated before the preferred route enters the local routing table.
FIB
Forwarding Information Base
10.40.40.0/24 → VTEP
The data plane uses the installed forwarding entry to determine where packets go.
VRF
Tenant Routing Context
VRF-CORP
The lookup occurs inside the appropriate routing domain rather than the global table.
03 · Fabric Forwarding Underlay transport + overlay tenant reachability.
LEAF-01 Ingress
Host Attachment
VLAN 120 · VNI 10120
SPINE-01 Underlay
IP Transport
ECMP next hop
LEAF-02 Egress
VTEP Decapsulation
VNI 10120 → VLAN
SERVER Endpoint
Application Network
10.40.40.20/24
Current Routing Decision
01
Compare available control-plane paths
The router begins by determining which routing sources know about 10.40.40.0/24.
Evidence: OSPF, BGP and fabric reachability are available.
Candidate Routes
Source Path Preference
OSPF 10.40.40.0/24 Best
BGP 10.40.40.0/24 Candidate
IS-IS 10.40.40.0/24 Fabric

Routing Control Planes and Modern Network Architecture

The previous sections established how a packet is constructed, forwarded, filtered and transported.

The next question is more fundamental:

How does a modern network know which paths should exist in the first place?

Individual routers can use static routes, but large networks require dynamic control planes that continuously exchange reachability information and calculate usable paths.

This creates another important separation:

Control plane = learns and calculates reachability

Data plane = forwards packets using the resulting information

Modern connectivity architectures build increasingly sophisticated control planes above relatively simple forwarding operations.

Interior Routing

Interior routing protocols operate within an autonomous system or administrative domain.

Two important examples are:

OSPF — Open Shortest Path First

IS-IS — Intermediate System to Intermediate System

Both can build a topology view and calculate paths using link-state information.

OSPF

OSPF routers establish neighbour relationships and exchange link-state information.

The resulting link-state database provides a view of the topology from which shortest-path calculations can be performed.

A simplified model is:

Interface

↓

OSPF adjacency

↓

Link-state database

↓

SPF calculation

↓

Routing table

↓

FIB

OSPF can also support multiple areas, route summarisation and different network designs.

When troubleshooting OSPF, useful evidence includes:

  • Interface state

  • IP addressing

  • Area configuration

  • Hello/dead timers

  • Authentication

  • MTU compatibility

  • Neighbour state

  • Link-state database

  • Route installation

A healthy OSPF adjacency does not automatically prove that the desired application traffic will work.

The route may still be filtered, overridden, or blocked by another policy layer.

IS-IS

IS-IS provides similar link-state functionality but has historically been particularly prominent in service-provider and large-scale network environments.

Its operation also revolves around:

Adjacency formation

→

Link-state information

→

Shortest-path calculation

→

Route installation

One advantage of understanding both OSPF and IS-IS is recognising the underlying engineering model rather than memorising protocol-specific commands.

The key concept is:

Distributed devices build a consistent view of reachability and independently calculate paths from that information.

BGP as a Connectivity Control Plane

BGP operates differently.

BGP is designed to exchange reachability information between autonomous systems and is also widely used internally in large networks.

A BGP route is more than a destination prefix.

It can include attributes such as:

  • AS_PATH

  • LOCAL_PREF

  • MED

  • NEXT_HOP

  • Communities

  • Origin information

  • Policy-related attributes

A simplified BGP decision chain is:

Prefix / NLRI

↓

Path attributes

↓

Import policy

↓

Best-path selection

↓

RIB

↓

FIB

BGP therefore influences which path becomes preferred.

It does not forward the user packet itself.

Once the BGP decision has resulted in an active route, the data plane performs the actual forwarding lookup.

BGP Policy

BGP becomes particularly powerful when policy is introduced.

An organisation may prefer:

Provider A

for normal internet traffic while using:

Provider B

as a backup.

The decision can be influenced using attributes such as LOCAL_PREF, AS_PATH manipulation, MED and communities, depending on the design.

This creates an important distinction:

Routing protocol

determines how reachability information is exchanged.

Routing policy

determines which paths are preferred, accepted, rejected or modified.

Forwarding

moves the actual packet.

Keeping these three concepts separate makes complex routing behaviour much easier to understand.

BGP Communities

Communities provide a mechanism for attaching policy information to routes.

Instead of treating every prefix independently, a network can classify groups of routes according to a policy requirement.

For example:

Prefix

  •  

Community

↓

Policy

↓

Preferred / rejected / modified path

Communities are widely used to implement scalable routing policy across service-provider, enterprise and cloud environments.

Route Reflectors

Large iBGP deployments can use route reflectors to reduce the requirement for a full mesh of internal BGP sessions.

Conceptually:

Client

↓

Route Reflector

↓

Other BGP clients

The route reflector distributes selected BGP information between clients while preserving the overall BGP control-plane model.

This is especially important in data-centre and service-provider environments where the number of routers can become large.

VRF and Routing Segmentation

A single physical router does not necessarily need to have one global routing table.

Virtual Routing and Forwarding (VRF) allows multiple independent routing tables to coexist on the same platform.

For example:

VRF-CORPORATE

10.10.0.0/16

VRF-GUEST

10.10.0.0/16

The same address space can therefore exist independently in different routing domains.

This is one of the most important concepts in modern network segmentation.

VRFs can be used for:

  • Customer separation

  • Management networks

  • Guest networks

  • Production environments

  • Development environments

  • Multi-tenant infrastructure

  • Service-provider VPNs

A packet entering one VRF is normally evaluated against that VRF’s routing and forwarding information rather than the global table.

VRF and Security

VRF provides routing separation, but routing separation is not automatically equivalent to complete security.

Additional policy may still be required:

VRF

→ routing isolation

Firewall / ACL

→ traffic policy

Identity / application controls

→ service-level policy

This layered approach is common in modern enterprise architectures.

Data Centre Connectivity

Traditional data centres often relied heavily on large Layer 2 domains.

Modern data centres increasingly favour routed architectures.

A common design is the leaf-spine fabric.

Leaf-Spine Architecture

Servers, appliances and workloads connect to leaf switches.

Leaf switches connect to multiple spine switches.

Conceptually:

Server

↓

Leaf

↙ ↓ ↘

Spine 1 — Spine 2 — Spine 3

This provides predictable path length and multiple equal-cost paths.

A typical flow between two racks may traverse:

Leaf → Spine → Leaf

rather than depending on a large Layer 2 topology.

The architecture works particularly well with ECMP because multiple spine paths can be used simultaneously.

Underlay and Overlay

Modern data-centre fabrics often separate the physical IP network from the logical tenant network.

The physical network is called the:

Underlay

The logical overlay provides:

Tenant connectivity

The underlay’s job is primarily to provide IP reachability between tunnel endpoints.

The overlay then creates logical networks above that physical transport.

This separation is fundamental to modern scalable data-centre networking.

VXLAN

VXLAN provides an overlay encapsulation mechanism that can carry Layer 2 Ethernet frames across a Layer 3 IP network.

A VXLAN tunnel endpoint is commonly referred to as a:

VTEP

The simplified process is:

Original Ethernet frame

↓

VXLAN encapsulation

↓

UDP

↓

IP underlay

↓

Remote VTEP

↓

VXLAN decapsulation

↓

Original Ethernet frame

VXLAN uses UDP as its transport and provides a much larger logical network identifier than traditional VLAN numbering.

The key idea is:

The physical network forwards IP packets.

The overlay provides logical tenant connectivity.

EVPN

VXLAN provides the encapsulation mechanism, but the network still needs a control plane to communicate information about endpoints and reachability.

This is where Ethernet VPN (EVPN) becomes important.

EVPN can distribute information such as:

  • MAC addresses

  • IP addresses

  • VTEP reachability

  • Ethernet segment information

  • Tenant route information

BGP is commonly used as the EVPN control plane.

The resulting architecture can therefore be represented as:

Underlay

OSPF / IS-IS / BGP

↓

IP reachability

↓

VTEP connectivity

↓

EVPN control plane

↓

VXLAN overlay

↓

Tenant network

This distinction is important:

VXLAN = encapsulation

EVPN = control-plane signalling

They solve related but different problems.

Multi-Tenancy

Modern infrastructure frequently needs to support multiple independent environments on shared physical infrastructure.

A tenant may require:

  • Independent IP addressing

  • Independent routing

  • Independent security policy

  • Independent application services

  • Controlled connectivity to shared services

A modern fabric can combine:

VRF

  •  

VXLAN

  •  

EVPN

  •  

Firewall policy

to provide scalable segmentation.

The physical infrastructure is shared while the logical connectivity remains separated.

WAN Connectivity

The same principles extend beyond the data centre.

A traditional WAN might connect:

Branch → MPLS → Data Centre

Modern architectures can combine:

Internet

MPLS

5G

Broadband

Private connectivity

into a software-controlled WAN.

SD-WAN

SD-WAN introduces policy-driven path selection across multiple WAN transports.

Instead of simply asking:

Which route exists?

the system can evaluate:

  • Latency

  • Packet loss

  • Jitter

  • Application identity

  • Link availability

  • Business policy

  • Security requirements

The resulting decision can be:

Voice traffic → low-latency path

Bulk backup → lower-cost path

Critical application → preferred private path

This represents a move from traditional reachability toward application-aware connectivity policy.

The underlying network still forwards packets using ordinary routing and forwarding mechanisms.

The difference is that a higher-level control system can influence which path is preferred.

Cloud Connectivity

Cloud networking introduces another layer of abstraction.

A workload may appear to communicate directly with another private IP address, but the actual path can include:

Workload

↓

Virtual NIC

↓

Subnet

↓

Cloud route table

↓

Security controls

↓

Transit / peering / VPN / private connectivity

↓

Remote network

Cloud platforms therefore implement many of the same fundamental networking concepts found in physical infrastructure.

The terminology changes, but the underlying engineering questions remain familiar.

Cloud Route Tables

A cloud subnet typically has associated routing behaviour.

A route may specify:

Destination prefix

→ Next-hop target

The target could represent:

  • Local subnet

  • Internet gateway

  • NAT gateway

  • Transit gateway

  • VPN attachment

  • Private service endpoint

  • Virtual appliance

The same fundamental principle still applies:

Destination → route lookup → next hop

Security Groups and Network ACLs

Cloud environments commonly provide multiple security layers.

A security group typically applies policy to workload interfaces or instances.

A network ACL may apply policy at the subnet boundary, depending on the platform.

These mechanisms should be understood independently from routing.

A correct route does not guarantee permitted traffic.

Cloud Peering

Network peering can provide private connectivity between separate cloud network domains.

However, peering is often not automatically transitive.

For example:

Network A ↔ Network B

and:

Network B ↔ Network C

does not necessarily mean:

Network A ↔ Network C

without an explicit routing or transit architecture.

This is why large cloud environments often use centralised transit or hub-and-spoke designs.

Network Connectivity Center

A connectivity hub can provide a central architecture for connecting multiple network domains.

Conceptually:

Branch

↘

Cloud / Transit Hub

↙

Data Centre

↘

Other Cloud

The exact implementation depends on the cloud platform, but the architectural principle is consistent:

centralise connectivity policy while keeping forwarding distributed.

Hybrid Connectivity

Hybrid environments combine physical and virtual infrastructure.

A typical flow might be:

On-Premises Client

↓

Enterprise Router

↓

Firewall

↓

VPN / Private Interconnect

↓

Cloud Router

↓

VPC

↓

Workload

The packet can therefore cross multiple control planes and security domains.

A failure anywhere in this chain can appear to the user as simply:

“The cloud application is unreachable.”

The engineer must break that symptom into smaller forwarding domains.

Route Leaking and Shared Services

Large segmented environments sometimes need controlled communication between VRFs or network domains.

For example:

Production VRF

and:

Security Services VRF

may both need access to a shared:

DNS / NTP / Authentication

environment.

Rather than merging the routing domains, selective route exchange can provide controlled reachability.

This is commonly referred to as route leaking.

The engineering objective is:

Share only what is required.

Uncontrolled route leaking can undermine the segmentation the VRFs were intended to provide.

Control Plane Convergence

Dynamic networks are not static.

Links fail.

Interfaces change state.

BGP sessions reset.

OSPF neighbours disappear.

Cloud routes change.

Overlay endpoints move.

The control plane must detect changes and converge toward a new forwarding state.

A simplified failure sequence is:

Link failure

↓

Neighbour / protocol detects failure

↓

Control-plane recalculation

↓

New route selected

↓

FIB updated

↓

Traffic uses alternate path

The time between the failure and the stable forwarding state is known as convergence time.

During convergence, packets may be:

  • Dropped

  • Rerouted

  • Delayed

  • Sent over a degraded path

This is why resilient architectures do more than provide redundant links.

They also require control planes capable of detecting and responding to failures predictably.

The Modern Routing Stack

A large network can therefore contain several routing layers simultaneously.

Physical underlay

↓

OSPF / IS-IS / BGP

↓

VRF routing

↓

EVPN control plane

↓

VXLAN overlay

↓

Security policy

↓

Application / service routing

Each layer solves a different problem.

The challenge for the engineer is knowing which layer owns the decision being investigated.

A VXLAN problem should not automatically be investigated as an application problem.

A BGP policy problem should not automatically be treated as a physical link failure.

A firewall state problem should not automatically be treated as a missing route.

Engineering Insight

Modern networks are increasingly built as multiple cooperating control planes.

A single application flow can depend on:

Host routing

→ LAN switching

→ IGP

→ BGP

→ VRF

→ EVPN

→ VXLAN

→ Firewall policy

→ Cloud routing

→ Application service discovery

The packet itself remains relatively simple.

The complexity comes from the distributed systems that decide where the packet should be allowed to travel.

This is one of the most important ideas in modern network engineering.

From Connectivity to Platforms

The network fabric does not stop at the cloud or data-centre boundary.

Modern applications increasingly run inside virtual machines, containers and Kubernetes clusters.

The next stage of connectivity therefore moves into the workload itself.

The engineer must understand how:

Application

↓

Container

↓

Network namespace

↓

Virtual interface

↓

CNI

↓

Node network

↓

Data-centre / cloud fabric

connects back into the wider network.

This is where traditional network engineering and cloud-native networking begin to converge.

Cloud-Native Network Explorer

Network Connectivity · Cloud-Native Foundations

Where Does a Kubernetes Packet Actually Go?

Cloud-native networking adds virtual interfaces, network namespaces, CNI datapaths, service abstraction and policy enforcement to the traditional networking model. Select a stage to see what happens at that boundary.

Cloud-Native Connectivity Path
Select a component
Workload
→
→
Node Datapath
→
→
Destination
→
→
East-West Traffic
Pod-to-pod and service-to-service communication remains inside the cluster or connected fabric.
North-South Traffic
Traffic crosses a cluster boundary through an ingress, gateway, load balancer or other external connectivity mechanism.
Component Detail
01 / 09
WORKLOAD

Pod / Network Namespace

A pod's application does not necessarily operate directly on the host's primary network interface. Its network namespace provides the workload with its own interfaces, addresses and routing context.
Engineer asks
Does the workload have a usable interface and address?
Evidence
Interface / address / route state
Provides
Workload network identity
Next
veth pair
Engineering Perspective
A Kubernetes connectivity problem may originate below Kubernetes itself. The pod depends on Linux networking, the host datapath and the underlying network before the application can communicate.
Network Connectivity · Interactive Lab 04

Cloud-Native Network Explorer

Follow pod traffic through Linux networking, the CNI, Open vSwitch, Kubernetes Services and NetworkPolicy before it leaves the cluster.

Healthy
Layer 1 / 7
POD
Source
frontend-7c9f
→
Service
api.production.svc
SVC
01 · Workload Application starts inside a network namespace.
POD-01 Active
frontend-7c9f
10.244.1.20 · TCP/8080
NETNS APP TCP
POD-02 Target
api-65d4
10.244.2.31 · TCP/8080
NETNS BACKEND READY
02 · Node Networking Traffic crosses the pod interface and node datapath.
vETH
veth Pair
Connects the pod namespace to the node network namespace.
Connected
CNI
CNI Plugin
Creates interfaces and programs connectivity for the workload.
Waiting
OVS
Open vSwitch
Flow-based datapath forwards traffic through the node.
Waiting
SVC
Kubernetes Service
Service abstraction selects a backend endpoint.
Waiting
ACL
NetworkPolicy
Policy determines whether the workload communication is permitted.
Waiting
03 · Service Delivery Cluster networking converts application intent into packet forwarding.
Service Virtual IP
10.96.20.50:443
The application connects to the Service address rather than directly selecting a pod.
Endpoint Selection
api-65d4 selected
The Service resolves the virtual destination to an available backend endpoint.
Network Result
Ready
Packet can continue toward the selected workload.
Current Network Decision
01
Pod network namespace
The application begins inside the pod network namespace and creates a TCP connection toward the Service.
Evidence: pod interface is present and the application has a valid source address.
Packet / Service State
Source
10.244.1.20
Destination
10.96.20.50
Protocol
TCP / 443
Backend
api-65d4

Cloud-Native Networking, Observability and Troubleshooting

Modern connectivity increasingly extends into the application platform itself.

A packet that begins at a user workstation may eventually reach a container running inside Kubernetes, pass through a virtual switch, traverse an overlay network and be delivered to a workload through a service abstraction.

The physical network may never directly see the application’s logical topology.

Understanding this environment requires extending traditional networking concepts into the virtual infrastructure.

Kubernetes Networking

Kubernetes introduces several networking requirements:

  • Pods need IP connectivity.

  • Pods normally need to communicate with other Pods.

  • Pods may need to communicate with external networks.

  • Applications need stable service identities.

  • Network policy must control allowed communication.

  • Ingress and load-balancing mechanisms must expose selected services.

The implementation is commonly provided by a Container Network Interface (CNI) plugin.

A simplified path is:

Application

↓

Pod network namespace

↓

Virtual Ethernet interface

↓

Node networking

↓

CNI

↓

Cluster network

↓

Data-centre / cloud network

The exact implementation depends on the CNI and platform.

Network Namespaces

Linux network namespaces provide isolated networking environments.

A container or Pod can have its own:

  • Interfaces

  • Routing table

  • IP addresses

  • Neighbour information

  • Network sockets

This creates a virtual networking boundary inside the operating system.

The host can then connect that namespace to the wider network using virtual interfaces.

veth Pairs

A common Linux mechanism is the virtual Ethernet pair, or veth pair.

A veth pair behaves like a virtual cable with two connected interfaces.

Conceptually:

Pod interface

↔

veth pair

↔

Host interface

Traffic leaving the Pod can therefore enter the node’s networking stack and continue toward another workload or external destination.

This is one of the fundamental building blocks behind container networking.

Container Network Interface

The CNI layer is responsible for connecting workloads to the network.

Depending on the implementation, it may provide:

  • IP address allocation

  • Interface creation

  • Routing

  • Overlay networking

  • Network policy

  • Encapsulation

  • Encryption

  • Load balancing

  • eBPF-based forwarding

Different CNIs implement these functions differently.

The important engineering concept is that Kubernetes does not itself define one single packet-forwarding architecture.

The networking behaviour depends heavily on the selected platform and CNI.

Kubernetes Services

Pods are ephemeral.

Their IP addresses can change as workloads are recreated.

Applications therefore normally communicate through a stable Service abstraction.

Conceptually:

Client Pod

↓

Service

↓

Service IP / virtual address

↓

Endpoint selection

↓

Pod

The forwarding mechanism may use technologies such as:

  • kube-proxy

  • iptables

  • IPVS

  • eBPF

  • CNI-specific mechanisms

The result is a logical service endpoint above the individual workload addresses.

East-West and North-South Traffic

Kubernetes networking is often discussed in terms of two directions.

East-West

Traffic between workloads.

North-South

Traffic entering or leaving the cluster.

For example:

Pod → Pod

is east-west traffic.

While:

Internet → Load Balancer → Ingress → Service → Pod

is north-south traffic.

These paths can have completely different security and forwarding behaviour.

Kubernetes Network Policy

NetworkPolicy provides workload-level traffic controls.

A policy might express:

Pod A

may communicate with:

Pod B

on:

TCP/443

while other traffic is denied.

This moves security policy closer to the workload.

The resulting model can include multiple independent security layers:

Cloud firewall

↓

Node firewall

↓

CNI policy

↓

Application authentication

A successful network route therefore does not automatically imply application permission.

Open vSwitch

Open vSwitch, commonly abbreviated OVS, is a software-based multilayer virtual switch used in many virtualised and cloud environments.

Its architecture can include several components.

Conceptually:

Management / Configuration

↓

OVSDB

↓

OpenFlow / Control

↓

OVS datapath

↓

Virtual / physical interfaces

OVS can provide switching, tunnelling, VLAN handling, flow-based forwarding and integration with virtualisation platforms.

Depending on deployment, packet processing can involve kernel datapaths, userspace processing, DPDK or hardware offload.

The exact forwarding path is therefore platform-dependent.

Flow-Based Forwarding

Unlike a simple physical switch MAC table, OVS can make decisions based on richer flow information.

A flow can match fields such as:

  • Ethernet addresses

  • VLAN

  • IPv4 / IPv6 addresses

  • Protocol

  • TCP / UDP ports

  • Tunnel metadata

The resulting action can include:

  • Forward

  • Drop

  • Modify

  • Encapsulate

  • Decapsulate

  • Output to another interface

This makes software switching an important component of modern virtual network architectures.

Connectivity Testing

Connectivity testing should be performed from the perspective of the actual failure domain.

Testing from a network engineer’s laptop may produce a different result from testing directly from the affected server, container or cloud workload.

The most useful question is therefore:

Where should the test originate?

A good test sequence moves from lower-level reachability toward the application.

Interface

↓

Address

↓

Neighbour

↓

Gateway

↓

Remote route

↓

TCP / UDP

↓

TLS

↓

Application

This prevents the engineer from jumping directly to application assumptions.

ICMP and Ping

ICMP is useful for testing IP-level reachability and diagnosing network behaviour.

However:

Ping success ≠ application success

and:

Ping failure ≠ application failure

Some networks intentionally block ICMP while allowing application traffic.

Other networks may permit ICMP but block TCP or UDP services.

ICMP should therefore be treated as one measurement, not a universal connectivity test.

ICMP also plays important roles beyond ping, including error reporting and IPv6 neighbour discovery mechanisms.

Cisco IP SLA

IP SLA-style synthetic testing can measure characteristics such as:

  • ICMP reachability

  • Round-trip time

  • Jitter

  • Packet loss

  • Service response

This provides a repeatable baseline rather than relying on manual testing.

The important distinction is:

Synthetic measurement

does not necessarily equal:

Real application performance

An ICMP test can report excellent results while an application experiences slow database queries or TLS delays.

PowerShell Connectivity Testing

Windows systems provide useful native diagnostics.

For example:

Test-NetConnection

can test TCP connectivity to a destination and port.

A conceptual test is:

Destination → Server

Port → 443

The result can provide information about:

  • Name resolution

  • Remote address

  • Selected interface

  • Source address

  • Route information

  • TCP connection success

A failed TCP test does not automatically prove that the host is down.

The destination may be:

  • Filtering the port

  • Rejecting the connection

  • Behind a firewall

  • Using another service port

  • Experiencing a routing problem

The output should therefore be interpreted as evidence rather than a final diagnosis.

Packet Capture

Packet capture remains one of the most powerful troubleshooting techniques.

Tools such as tcpdump and Wireshark allow the engineer to observe what actually happened on the wire or virtual interface.

A capture can answer questions such as:

Did the packet leave?

Did the reply return?

Was the TCP handshake completed?

Are retransmissions occurring?

Are ICMP errors being generated?

Is the MTU causing fragmentation or loss?

A useful packet investigation often compares both directions:

Client capture

and:

Server capture

This can reveal where the packet disappears.

Reading a TCP Capture

A basic TCP exchange might appear as:

Client → SYN

Server → SYN/ACK

Client → ACK

Client → HTTP/TLS data

If the capture instead shows:

Client → SYN

Client → SYN

Client → SYN

with no response, the investigation should move toward routing, filtering, host availability or return-path problems.

If the capture shows:

SYN

SYN/ACK

ACK

followed by retransmissions, the problem is likely further into the transport or application path.

Packet capture turns an abstract connectivity complaint into observable evidence.

Network Discovery

Network discovery tools can identify reachable hosts, exposed services and network characteristics.

Nmap is commonly used for authorised network discovery and service enumeration.

It can help identify:

  • Open ports

  • Service responses

  • Host availability

  • Operating-system characteristics

  • Network filtering behaviour

Scanning should always be performed against systems and networks for which the operator has explicit authorisation.

Nmap and Python

Python can be used to automate network discovery workflows through libraries and subprocess integrations.

A typical automation model is:

Python

↓

Discovery task

↓

Nmap

↓

Structured results

↓

Analysis / reporting

This can turn repeated diagnostic work into a controlled engineering workflow.

Automation becomes particularly useful when the same validation must be performed across many hosts or environments.

Observability

Modern networks cannot rely only on reactive packet captures.

Large environments require continuous visibility.

A useful observability model includes three broad evidence types:

Metrics

Logs

Flows / packets

Each provides a different perspective.

Metrics

Metrics can expose:

  • Interface utilisation

  • Packet errors

  • Drops

  • CPU

  • Memory

  • Latency

  • Packet loss

  • Tunnel state

  • BGP session state

Metrics are useful for identifying trends and detecting degradation.

Logs

Logs provide event-level information.

Examples include:

  • Interface transitions

  • BGP neighbour changes

  • OSPF adjacency changes

  • Firewall denies

  • Authentication events

  • VPN failures

  • Configuration changes

Logs are particularly useful for correlating an outage with a specific control-plane or infrastructure event.

Flow Telemetry

Flow telemetry provides information about conversations without necessarily capturing every packet payload.

A flow record may include:

Source IP

Destination IP

Source Port

Destination Port

Protocol

Bytes

Packets

Start / End time

This can answer questions such as:

Who is communicating with whom?

How much traffic is being exchanged?

Which service is consuming bandwidth?

Did the traffic stop after a routing event?

Flow telemetry is therefore complementary to packet capture.

Control-Plane Observability

The forwarding plane may appear healthy while the control plane is degraded.

For example:

BGP session down

may eventually result in:

Route withdrawn

↓

FIB changes

↓

Traffic rerouted

↓

Application latency increases

An application monitoring system may simply report:

“Service degraded.”

Network telemetry can reveal the actual cause.

This is why modern observability should correlate:

Application

  •  

Transport

  •  

Network

  •  

Control Plane

  •  

Infrastructure

Synthetic Connectivity Testing

Synthetic monitoring can continuously test important paths.

For example:

Branch → SaaS application

Cloud → Data centre

User → API

Cluster → Database

A synthetic probe can measure:

  • DNS resolution

  • TCP establishment

  • TLS negotiation

  • HTTP response

  • Latency

  • Availability

This is much more useful than relying on a single ping monitor because it tests the actual service path.

The Connectivity Decision Engine

The entire article can now be reduced to a practical decision engine.

When a flow fails, ask:

1. Is the interface operational?

↓

2. Does the endpoint have the expected address?

↓

3. Can the local neighbour be resolved?

↓

4. Is the default gateway reachable?

↓

5. Does the routing table contain the destination?

↓

6. Which route wins?

↓

7. What is the next hop?

↓

8. Is the traffic permitted?

↓

9. Is NAT or translation involved?

↓

10. Can the transport session establish?

↓

11. Is the MTU sufficient?

↓

12. Does DNS resolve correctly?

↓

13. Does TLS establish?

↓

14. Does the application respond?

↓

15. Is performance acceptable?

This sequence prevents random troubleshooting.

Each step eliminates an entire class of possible failures.

Connectivity Troubleshooting Matrix

SymptomFirst Investigation
Interface downPhysical / virtual interface state
Same-subnet host unreachableVLAN, MAC learning, ARP/NDP
Gateway unreachableLocal addressing, VLAN, neighbour resolution
Remote subnet unreachableRouting table, next hop, return path
Ping failsRouting, ICMP policy, Layer 2/3
Ping works, TCP failsFirewall, ACL, service, NAT
TCP connects, application failsTLS, DNS, authentication, application
Small packets work, large packets failMTU, MSS, PMTUD
One direction worksAsymmetric routing, stateful firewall
Intermittent connectivityECMP, packet loss, unstable control plane
IPv4 works, IPv6 failsNDP, RA, IPv6 routing, IPv6 policy
Pod-to-Pod failsCNI, routes, NetworkPolicy
Pod works locally but not externallyService, ingress, node routing, cloud policy
Cloud one-way connectivityReturn routes, security groups, NACLs, transit
Application suddenly degradedControl-plane change, path change, loss, latency

The table should not be treated as a collection of commands.

It is a decision framework.

The objective is to move from symptom to evidence and from evidence to the smallest possible failure domain.

Modern Connectivity Fabric

At this point the complete architecture can be viewed as a layered fabric:

Endpoint

↓

Ethernet / Wi-Fi

↓

VLAN / Switching

↓

IP Routing

↓

VRF / Segmentation

↓

Security

↓

WAN / Internet / Cloud

↓

Overlay

↓

Virtual Network

↓

Container / Kubernetes

↓

Service

↓

Application

The physical and virtual infrastructure may be completely different, but the underlying engineering principles remain consistent.

There is always:

Addressing

Reachability

Forwarding

Policy

Transport

Service

Observation

Engineering Perspective

Modern connectivity engineering is increasingly about understanding interactions between systems rather than memorising individual technologies.

A packet may begin in a laptop, enter a VLAN, cross an access switch, reach a router, follow a BGP-selected path, pass through a firewall, cross a cloud interconnect, enter a VRF, traverse a VXLAN overlay, reach a Kubernetes node and finally arrive at a container.

To the application, this may look like:

“Connect to 10.20.30.40:443.”

Behind that simple request can be dozens of independent decisions.

The engineer’s job is to reduce that complexity into observable stages.

Where did the packet originate?

Where should it go?

Which control plane selected the path?

Which forwarding table processed it?

Which security policy evaluated it?

Did the return path behave correctly?

Did transport succeed?

Did the application respond?

Once these questions become habitual, network troubleshooting becomes less about guessing and more about proving what happened.

Connectivity Engineering Checklist

Before declaring a connectivity problem resolved, validate:

  • Interface state

  • IP addressing

  • VLAN / segment

  • ARP or NDP

  • Default gateway

  • Routing table

  • FIB / forwarding state

  • Next hop

  • Security policy

  • NAT / translation

  • Return path

  • MTU / MSS

  • TCP / UDP behaviour

  • DNS

  • TLS

  • Application response

  • Latency

  • Packet loss

  • Control-plane stability

  • Monitoring visibility

A change that fixes one layer but creates a failure at another is not a complete solution.

The best connectivity designs therefore combine correct forwarding, explicit security, resilient control planes and continuous observability.

Conclusion

Network connectivity has evolved from simple host-to-host communication into a distributed fabric spanning physical networks, virtual infrastructure, cloud platforms and application platforms.

The technologies may differ, but the fundamental questions remain remarkably consistent:

How is the destination identified?

How is the path selected?

How is the next hop resolved?

How is the traffic secured?

How is the transport session established?

How is the application reached?

How do we know when something fails?

Understanding these questions provides the foundation for designing, operating and troubleshooting modern networks.

The network is no longer simply the infrastructure underneath the application.

It is a distributed connectivity system that continuously calculates, enforces and observes how applications communicate.

Stage 05 · Engineering Investigation

Network Failure Investigator

The application is unreachable. Follow the connectivity chain, collect evidence, identify the first broken dependency and prove the root cause.

0 / 10 checks completed
Scenario: Application Unreachable

Client 10.20.10.25 is attempting to reach app.network.local at 10.30.20.50:443. The application team reports that the service is unavailable. Determine where the connectivity chain actually fails.

Connectivity Path

Awaiting investigation
PC
Client
10.20.10.25
SW
Access Switch
VLAN 20
R
Edge Router
VRF PROD
FW
Firewall
HTTPS
NAT
NAT Gateway
SNAT
APP
Application
10.30.20.50
CONNECT → RESOLVE → ROUTE → POLICY → TRANSLATE → MTU → TCP → SERVICE

Investigation Checks

Click each check to collect evidence

Evidence Console

No check selected
Select an investigation check WAITING
Click an investigation check to collect simulated engineering evidence.
Engineering interpretation: Start with the lowest dependency and work upward. The application symptom is not automatically the root cause.

Investigation Timeline

Live evidence
00:00
Investigation started. Application reported unreachable.

Submit Root-Cause Diagnosis

Fault Injection

Select another failure
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
Cisco Snort

Cisco Firewall with Cisco IPS

NETWORK INSIGHT · ENGINEERING GUIDE

Cisco Firewall + IPS: From Stateful Inspection to Snort 3 Threat Prevention

A modern firewall is no longer simply a barrier between an internal network and the Internet. It is an enforcement point that evaluates connection state, security policy, network context, application behaviour and, where deployed, deeper threat inspection before deciding what should happen to a flow.

Cisco Secure Firewall technologies combine stateful firewalling with additional inspection and intrusion prevention capabilities. Snort provides the inspection engine used to analyse traffic for protocol behaviour, signatures and other indicators of suspicious activity. The important engineering question is not simply which security features exist, but how traffic moves through these controls and how each stage contributes evidence to the final decision.

This guide therefore follows the security decision rather than treating firewalling and IPS as isolated technologies. We will start with the stateful firewall, move into Snort-based inspection, investigate a realistic security incident, and finish by examining how security teams correlate detection, prevention and operational evidence.

The engineering question When a connection is allowed, blocked or flagged, what evidence actually caused the security system to make that decision?
01 · SEE Follow a flow through state, zones, policy, NAT and inspection.
02 · OBSERVE See how IPS and Snort turn packets into security evidence.
03 · INVESTIGATE Trace an incident and isolate the actual security decision point.
04 · OPERATE Correlate detection, prevention, response and verification.
Cisco Secure Firewall + IPS

Integrated Threat Prevention Architecture

Modern firewall protection combines stateful access control with deep traffic inspection, threat intelligence and inline prevention. Select a stage to see what happens to traffic as it moves through the security stack.

Internet Traffic

Traffic enters the security boundary from an external network. The firewall begins evaluating the connection before the flow can reach protected internal resources.

Traffic
Firewall
Policy
IPS
Intelligence
Allowed
SECTION 01 · SEE
Firewall Decision Path Explorer
Click each stage to see what evidence is created.
STATEFUL FLOW
01
Packet
02
Zone
03
5-Tuple
04
State
05
Policy
06
NAT
07
Inspect
08
Decision
Engineering readout
A packet enters the firewall and becomes part of a flow that can be evaluated against security context and policy.
Evidence
Interface + packet metadata
01 · SEE · FIREWALL DECISION

The Stateful Firewall: From Packet to Security Decision

A firewall decision is not simply the result of matching an IP address and port against an access-control rule. A stateful firewall evaluates traffic in context, combining packet information, security-zone context, connection state, policy, translation and additional inspection before producing an enforcement result.

This distinction matters because the packet an engineer captures at one point in the network is only part of the story. The firewall may already have a connection record for the flow, may translate the addresses before forwarding the traffic, or may apply additional inspection after the initial policy evaluation.

The first engineering task is therefore to reconstruct the decision path: what entered the firewall, how it was classified, what state existed, which policy applied, what transformations occurred and what ultimately caused the traffic to be allowed or rejected.

The firewall decision path

01 · PACKET Traffic arrives Source, destination, protocol and port information enter the security device.
02 · CONTEXT Security zone Interface and zone information establish the security context.
03 · STATE Flow identified The firewall determines whether the connection already exists.
04 · POLICY Access decision Security policy determines the permitted handling of the traffic.
Conceptual stateful processing model
Packet
→
Zone
→
5-Tuple
→
State
→
Policy
→
NAT
→
Inspection
→
Action

Why stateful inspection matters

Stateful inspection maintains information about active connections rather than evaluating every packet as an unrelated event. For TCP traffic, for example, the firewall can use connection state to determine whether a packet belongs to an established session or represents an unexpected transition.

This creates an important troubleshooting dependency. If the application reports that a connection is established but the firewall has no matching state entry, the engineer has evidence that something in the expected flow is inconsistent. Conversely, seeing an established state does not automatically prove that the application is healthy; return traffic, inspection and downstream dependencies still need to be considered.

Security zones establish context

A firewall also evaluates where traffic comes from and where it is going. External, internal, DMZ and other logical security zones provide the context in which policy decisions are interpreted.

The same destination port can therefore represent very different security decisions depending on the source zone, destination zone, interface and configured policy. An engineer investigating a failure should always establish the traffic direction before interpreting an access-control result.

Questions to establish the context
Where did the packet enter? Identify the ingress interface and associated security context.
Where is it going? Establish the intended egress interface, zone and destination.
What flow is this? Confirm the source, destination, protocol and relevant ports.
What state exists? Determine whether the firewall recognises the connection.

Policy is only one part of the decision

Access-control policy is often the first place engineers look when traffic fails. That is sensible, but it is not sufficient. A rule permitting HTTPS does not by itself prove that the flow will successfully traverse the security stack.

The engineer must establish which policy entry actually matched the flow, whether the intended source and destination objects were used, and whether the policy result was consistent with the configured security intent.

If the rule is correct, investigation should continue rather than stopping at the access-control layer.

NAT changes the observed flow

Network Address Translation introduces another important evidence point. The address seen by the originating host may not be the address observed by the destination. During troubleshooting, engineers therefore need to distinguish the original flow from the translated representation.

A correct security policy combined with an incorrect translation can produce a failure that initially looks like a connectivity or routing problem. Translation records therefore belong in the same investigation chain as policy and state information.

Inspection can change the decision

Once the basic firewall decision has been established, additional inspection may evaluate application behaviour, protocol characteristics or security conditions. This is where traditional stateful firewalling begins to intersect with intrusion prevention and deeper traffic analysis.

The important operational distinction is that an allowed connection is not necessarily the end of processing. Depending on the platform and configured security policy, traffic may continue through additional inspection controls before the final action is complete.

Engineering evidence rule

Do not begin with the assumption that the firewall blocked the traffic. Establish the observed flow, security context, state, policy match, translation and inspection result in that order. Each observation removes another possible explanation from the investigation.

What the engineer should be able to prove

By the end of this stage, the engineer should be able to explain the firewall decision using evidence rather than configuration alone.

Traffic identity The exact source, destination, protocol and ports are known.
Security context The ingress, egress and zone relationship is understood.
Connection state The firewall's understanding of the flow is confirmed.
Security decision The policy, translation, inspection and resulting action are explained.
Engineering Lab · Section 01
Stateful Firewall Decision Engine

Next, work through a live firewall flow and step through the decision pipeline. The lab will expose the changing state, policy evaluation, NAT context, inspection result and final action so the decision can be investigated rather than simply described.

Stateful Firewalling

Stateful Firewall Decision Engine

A stateful firewall does more than inspect individual packets. It evaluates the connection context, compares traffic against policy, performs required translation and inspection, and then determines whether the flow should continue.

›
›
›
›
›
›
›

Source — Packet Arrival

A packet enters the firewall interface and becomes part of the firewall's processing pipeline. The device identifies the traffic context before applying security policy.

Source 10.20.10.25
Destination 172.16.20.50
Protocol TCP / HTTPS
Ports 49152 → 443
Example flow: established HTTPS session permitted after state, policy and inspection checks.
Stateful Firewall Lab · SEE

From Packet to Security Decision

Step through a stateful firewall decision and watch the evidence accumulate: packet identity, security zone, 5-tuple, connection state, policy, NAT, inspection and final enforcement action.
Ready
Live Traffic Path
0 / 12
◉
CLIENT
10.20.4.15
Internal host
HTTPS client
◆
STATEFUL FIREWALL
FW-EDGE-01
Inside: 10.20.0.1
Outside: 198.51.100.10
▣
WEB SERVER
203.0.113.20
HTTPS service
TCP/443
Observed Flow
NEW
10.20.4.15:51520
→ 203.0.113.20:443
TCP / HTTPS
Translated Flow
NOT CREATED
Waiting for NAT decision
Engineering model: the firewall does not make a decision from the packet alone. It progressively adds context until the enforcement decision can be explained.
Decision Evidence
Live
Ingress Zone
Unknown
5-Tuple
Unknown
State
Unknown
Policy
Unknown
NAT
Unknown
Inspection
Unknown
Policy Engine
ACL / State
Rule OUT-HTTPS-01
Source zone INSIDE
Destination WEB / 443
Action Pending
Final Action
Enforcement
Current decision
PENDING
Firewall Decision Timeline
Evidence pipeline
01
PACKET
Packet enters the firewall on the inside interface.
02
ZONE
Firewall identifies the ingress and egress security context.
03
5-TUPLE
Source, destination, protocol and ports identify the flow.
04
STATE
The firewall checks whether the flow already exists in the state table.
05
POLICY
The security policy is evaluated against the observed flow and state.
06
NAT
Address translation is evaluated and the translated flow is created when required.
07
INSPECT
Additional stateful or application-aware inspection is applied.
08
DECIDE
The firewall determines whether the packet should be allowed or dropped.
09
FORWARD
An allowed packet is forwarded toward the destination.
10
REPLY
The return packet is matched against the existing state.
11
STATE
Return traffic is associated with the established connection.
12
COMPLETE
The flow is now explainable through policy, state, NAT and inspection evidence.
Engineering Readout
Live interpretation
Current Stage
Press Step Forward to begin
Investigation Progress
Engineering takeaway: a stateful firewall decision should be explainable through observable evidence rather than a simple allow/deny statement.
QUESTION 01 What packet actually entered the firewall?
QUESTION 02 Which security zone and connection state applied?
QUESTION 03 Which policy, NAT and inspection decisions changed the flow?
QUESTION 04 What evidence proves the final enforcement action?
SECTION 02 · OBSERVE
Snort 3 Threat Detection Pipeline
Select a processing stage and inspect the evidence it creates.
01
Packet
→
02
Decoder
→
03
Flow
→
04
Inspector
→
05
Rules
→
06
Detection
→
07
Action
What the engine is doing
Traffic enters the inspection pipeline as packets requiring analysis.
Evidence produced
packet metadata payload
02 · OBSERVE · THREAT DETECTION

Cisco IPS and Snort: From Traffic to Threat Detection

Stateful firewalling answers an important question: should this traffic be permitted through the security boundary? Intrusion prevention asks a different question: does the traffic itself contain characteristics that indicate malicious, anomalous or otherwise suspicious behaviour?

This distinction is critical when investigating security events. A flow can be permitted by the access-control policy and still trigger deeper inspection. Conversely, an IPS alert does not automatically mean that the connection was blocked. The configured inspection mode and resulting action must be established from evidence.

Snort provides a useful engineering model for understanding this deeper inspection process. Traffic moves through a sequence of processing stages where packets are decoded, associated with flows, interpreted by protocol inspectors, evaluated against detection logic and finally associated with an enforcement action.

The Snort inspection pipeline

01 · INPUT Packet Raw network traffic enters the inspection path.
02 · DECODE Decoder Protocol headers and packet structure are interpreted.
03 · CONTEXT Flow / Session Traffic is associated with the relevant connection.
04 · PROTOCOL Inspector Application and protocol behaviour can be examined.
05 · RULES Rule Matching Detection logic is evaluated against the observed traffic.
06 · DETECT Detection A security condition may be identified.
07 · ACTION IPS Action Alert, allow, drop or another configured response is applied.
08 · EVIDENCE Telemetry The event becomes evidence for operational investigation.
Engineering inspection model
Packet
→
Decoder
→
Flow
→
Inspector
→
Rules
→
Detection
→
IPS Action

Detection is more than signature matching

Signature-based detection is an important part of intrusion prevention, but modern inspection can use several forms of evidence. Protocol characteristics, application behaviour, flow context and other security conditions can contribute to determining whether traffic should be considered suspicious.

This creates a different troubleshooting model from traditional packet filtering. Instead of asking only which rule matched an address and port, the engineer needs to understand what the inspection engine observed and which condition caused the detection.

Signature Traffic characteristics match known detection logic or a defined attack pattern.
Protocol behaviour Protocol structure or application behaviour does not match expected characteristics.
Anomaly Observed activity deviates from an expected traffic or behavioural model.

Snort 2 and Snort 3 as engineering models

The evolution from Snort 2 to Snort 3 is useful for understanding how modern inspection engines organise processing. The older architecture provides a useful model of packet decoding, preprocessing, detection and output. Snort 3 expands this approach with a more modular architecture and greater emphasis on protocol inspectors and parallel processing.

Snort 2
Classic model

A useful conceptual model for understanding the traditional inspection pipeline.

  • Packet decoding
  • Preprocessing
  • Detection engine
  • Rule processing
  • Output and logging
Snort 3
Modern model

A more modular inspection architecture designed around inspectors, application awareness and improved processing organisation.

  • Modular inspectors
  • Protocol awareness
  • Application identification
  • Rule groups
  • Parallel resource utilisation

Protocol inspection creates deeper visibility

Packet headers tell the security system where traffic is going and which transport protocol is being used. Protocol inspection can provide a much richer view of what the traffic is actually doing.

For example, an HTTPS flow may be permitted because TCP port 443 is allowed, while deeper inspection evaluates additional characteristics of the session. The important engineering principle is that the transport port identifies a communication channel; it does not, by itself, prove that the application behaviour within that channel is benign.

Inline and passive inspection are different operational models

An IPS can operate in a position where it is able to influence traffic, or it can observe traffic and generate security events without directly enforcing the result. These modes produce different operational consequences.

In an inline design, a detection can potentially influence whether traffic continues. In a passive design, the detection becomes primarily observational evidence and another control may be required to prevent the activity.

Engineering evidence rule

An IPS alert is not the same thing as an IPS block. When analysing an event, correlate the flow, protocol, detection condition, rule or inspection result, timestamp and configured action. Only then can the engineer determine whether the IPS actually changed the fate of the traffic.

Security telemetry connects detection to investigation

Detection becomes operationally useful when it can be correlated with the surrounding network evidence. The source and destination of the flow, the firewall decision, the inspection event and the resulting action should form a coherent timeline.

This is particularly important when a legitimate application is accidentally classified as suspicious. Without the surrounding flow and application context, an engineer may respond to the alert while missing the actual cause of the service failure.

Evidence to correlate
Flow evidence Source, destination, protocol, ports and session timing.
Detection evidence Detection condition, rule context and observed protocol behaviour.
Action evidence Whether the system alerted, allowed, dropped or otherwise handled the traffic.

From detection to security decision

The complete security path is therefore broader than a simple packet-to-rule comparison. Traffic must first become understandable to the inspection engine, then gain flow and protocol context, then be evaluated against detection logic before a security action can occur.

That model also explains why security troubleshooting often requires multiple evidence sources. A packet capture may prove what was sent. A firewall record may prove how the flow was handled. An IPS event may explain what the inspection engine detected. Together, these observations provide a much stronger explanation than any single log entry.

Engineering objective
Explain the detection, not just the alert

The goal is to reconstruct the inspection path: what traffic entered, how the flow was identified, what the protocol inspector observed, which detection logic matched, what security condition was identified and what action followed.

Engineering Lab · Section 02
Snort 3 Inspection Lab

The next interactive lab turns this pipeline into a live investigation. Step through packet decoding, flow context, protocol inspection, rule matching, detection and IPS action to see exactly where security evidence is created.

SNORT 3 / THREAT DETECTION LAB
From Traffic to Threat Detection
Step a network packet through the Snort 3 inspection pipeline. Observe how decoding, flow tracking, protocol inspection, rule matching and detection combine to produce an IPS action.
READY · WAITING FOR PACKET
Live Snort 3 Inspection Pipeline
STAGE 0 / 7
01
PACKET
Raw network traffic enters the inspection path.
02
DECODER
Headers and protocol structure are decoded.
03
FLOW
Traffic is associated with a session or flow.
04
INSPECTOR
Protocol-aware inspection identifies application context.
05
RULES
Relevant detection rules are evaluated.
06
DETECTION
Evidence is classified as clean, suspicious or malicious.
07
IPS ACTION
Configured policy determines pass, alert or block.
Source
CLIENT
10.20.4.15:51520
→
Destination
WEB SERVER
203.0.113.20:443
TCP · HTTPS · SYN · APPLICATION FLOW 7F2A · INSPECTION PENDING
Click any pipeline stage to inspect its engineering meaning. Use Step Forward to follow the packet sequentially, or inject a detection condition from the controls on the right.
Inspection Context
LIVE
Protocol
TCP
Application
HTTPS
Flow State
NEW
Inspector
HTTP / TLS
Rule Group
WEB-THREAT
Mode
INLINE
Detection Controls
FAULT INJECTION
Protocol Valid
Decoder receives structurally valid traffic.
Threat Signature
Rule matching produces a detection.
Behaviour Anomaly
Protocol/application behaviour is suspicious.
IPS Prevention
Inline mode can block detected traffic.
Detection Timeline
NO EVENT YET
01
PACKET
Traffic enters the Snort inspection path.
WAIT
02
DECODER
Packet structure and protocol headers are evaluated.
WAIT
03
FLOW / SESSION
Traffic is associated with the application flow.
WAIT
04
PROTOCOL INSPECTOR
Application-aware context becomes available.
WAIT
05
RULE MATCHING
Relevant detection rules are evaluated.
WAIT
06
DETECTION
Detection evidence is classified.
WAIT
07
IPS ACTION
Configured prevention behaviour is applied.
WAIT
Live Engineering Readout
Ready to inspect traffic
Step into the pipeline to see what evidence becomes available at each stage.
Current IPS Verdict
UNINSPECTED
Engineering Takeaway
A packet is not a threat simply because it exists. Detection depends on progressively richer context: protocol structure, flow state, application behaviour and detection logic.
Cisco Snort 3

Snort 3 Inspection Pipeline

Snort 3 processes traffic through a sequence of decoding, flow, protocol and detection stages. Select a stage below to explore how traffic moves from raw packets toward a security decision.

›
›
›
›
›
›

Packet — Traffic Arrives

Network traffic reaches the inspection engine. Snort begins processing the packet so that protocol and security information can be extracted for subsequent inspection stages.

Earlier Architecture

Snort 2

Snort 2 used a more process-oriented architecture built around packet decoding, preprocessors and the detection engine. Its architecture could involve duplicated processing and memory overhead as deployments scaled.

Modern Architecture

Snort 3

Snort 3 introduces a more modular, multi-threaded architecture with shared configuration and reusable inspectors. This provides a more flexible foundation for protocol analysis and efficient traffic processing.

Engineering note: the exact inspection and enforcement path depends on the Cisco Secure Firewall deployment, configured policy and enabled inspection features. The diagram represents the conceptual Snort 3 processing model rather than a packet-by-packet implementation trace.
SECTION 03 · INVESTIGATE
Security Evidence Explorer
Change the investigation vantage point and see which evidence becomes useful.
INCIDENT MODE
Flow
10.20.4.15 → 203.0.113.20
Policy
HTTPS-OUTBOUND
State
ESTABLISHED
IPS Event
No match
Endpoint
Browser session
DNS
Resolved
NAT
Translated
Decision
ALLOW
Firewall vantage point: Start with the flow, state table, policy match and NAT evidence before assuming IPS is responsible.
03 · INVESTIGATE · SECURITY EVIDENCE

Security Investigation: Following Evidence Through the Firewall

Real security investigations rarely begin with a known technical cause. They begin with a symptom: an application is slow, a connection fails, users report intermittent access or a security alert appears at an unexpected time. The engineer must then work backwards from that symptom and determine which part of the security path actually changed the outcome.

This requires a different mindset from simply checking whether a firewall rule exists. A configured rule describes intended behaviour. Telemetry, packet captures, connection state, inspection events and application observations provide evidence of what actually happened.

The investigation therefore follows the traffic through the security stack rather than jumping immediately to a conclusion.

Start with the symptom

Incident scenario
Intermittent failure
Internal user reports intermittent HTTPS application failure

A client at 10.20.4.15 is attempting to reach an application at 203.0.113.20:443. Some requests succeed while others fail or time out. The firewall is known to permit HTTPS traffic, but an IPS event has also appeared around the time of several failures.

At this point there are several possible explanations. The presence of an IPS alert makes it interesting, but it does not make the IPS responsible. The investigation must establish what happened to the actual flow.

Follow the evidence chain

01 · CLIENT Endpoint What did the client actually send and receive?
02 · FIREWALL Flow Did the firewall recognise and track the session?
03 · POLICY Access Which security rule handled the connection?
04 · NAT Translation Was the source or destination transformed?
05 · IPS Inspection Did deeper inspection identify a security condition?
06 · APP Application Did the application ultimately receive and answer the request?

Build the timeline before changing anything

Intermittent problems are particularly dangerous because different requests can take different paths through the security system. An alert at 10:03:14 and an application timeout at 10:03:15 may be related, but the timestamps alone do not establish causation.

Start by constructing a timeline around a specific failed transaction. Record the client, destination, protocol, ports and timestamp. Then correlate the flow with firewall state, policy decisions, translation records and IPS events.

01 Identify Isolate one failed transaction and its exact flow tuple.
02 Correlate Match the transaction across security telemetry sources.
03 Compare Compare successful and failed requests for meaningful differences.
04 Prove Confirm the actual control that changed the traffic outcome.

Possible fault domains

The investigation should keep multiple hypotheses open until evidence eliminates them. A firewall or IPS incident can involve several layers that appear similar from the application's perspective.

ACL or policy mismatch
The traffic may be matching a different policy than the engineer expects, or a condition in the policy may produce a deny.
NAT failure
Translation may be missing, incorrect or inconsistent with the expected destination path.
Stateful session problem
The firewall may not have the expected connection state or may interpret subsequent traffic differently from the initial flow.
IPS detection
Deeper inspection may identify a signature, protocol condition or behavioural characteristic that changes handling.
Application inspection
Application or protocol behaviour may be interpreted differently from the basic transport flow.
External dependency
DNS, reputation or another downstream dependency may contribute to the observed failure.
Threat intelligence
A destination, domain or other indicator may have acquired a security classification that affects handling.
False positive
Legitimate application traffic may be incorrectly classified by a detection control.

Use packet capture as evidence, not as the whole investigation

Tools such as tcpdump and Wireshark are valuable because they show what traffic is actually visible at a capture point. They can establish whether packets were transmitted, whether responses returned and whether retransmissions or resets are present.

However, a packet capture from one interface cannot automatically prove what happened elsewhere in the security stack. A packet disappearing after the firewall does not by itself distinguish between policy enforcement, NAT behaviour, IPS action, routing or an upstream failure.

Capture location therefore becomes part of the evidence. Engineers need to understand where the packet was observed relative to the security controls being investigated.

Do not confuse correlation with causation

An alert near the failure is not automatically the cause

An IPS event occurring at approximately the same time as an application failure is useful evidence, but it does not prove that the IPS caused the failure. Confirm the affected flow, the detection condition, the configured action and the resulting packet behaviour before assigning causality.

This distinction becomes especially important when investigating false positives. A legitimate application can trigger an inspection condition while another dependency is responsible for the actual outage. Treating every security alert as the root cause can lead to unnecessary policy changes and can make the original problem harder to reproduce.

Compare successful and failed traffic

Intermittent failures provide an important opportunity: successful transactions can become the baseline against which failed transactions are compared.

Flow comparison Check whether source, destination, protocol and ports are identical between successful and failed requests.
State comparison Determine whether successful and failed sessions have the same expected connection state.
Policy comparison Confirm that both requests traverse the same intended security policy.
NAT comparison Check whether translation behaviour differs between working and failing transactions.
IPS comparison Determine whether only failed transactions trigger a detection or whether successful traffic produces the same event.
Application comparison Establish whether the application received the request and produced a response.
Engineering evidence

A strong incident record should allow another engineer to reconstruct the transaction without relying on assumptions. At minimum, establish the timeline, flow tuple, firewall state, policy result, NAT behaviour, inspection event, configured action and endpoint or application result.

Investigation principle
Follow the packet until the evidence stops

Do not stop at the first interesting log entry. Continue through the security path until you can explain where the expected behaviour changed. The strongest root-cause statement identifies the control, evidence and resulting traffic behaviour together.

From observation to fault isolation

The investigation model developed here can now be turned into an operational exercise. Instead of being told which component is faulty, the engineer should inspect the available evidence and determine whether the problem lies in policy, state, NAT, IPS inspection, application behaviour or an external dependency.

The objective is not simply to identify a suspicious event. It is to explain the complete chain from client request to security decision and prove which observation distinguishes the real fault from the competing hypotheses.

Engineering Lab · Section 03
Firewall + IPS Incident Investigation Lab

The next interactive lab presents the incident as an evidence problem. Inspect the client flow, firewall state, policy, NAT, IPS telemetry and application evidence, then isolate the fault and build a defensible root-cause explanation.

SECURITY INCIDENT / INVESTIGATION LAB
Follow the Evidence Through the Firewall
An internal user reports intermittent HTTPS failures. Investigate the same flow across the client, firewall, policy, NAT, IPS and application layers. The objective is not to guess the fault — it is to build enough evidence to isolate it.
INCIDENT OPEN · EVIDENCE REQUIRED
Live Incident Path
0 / 6 EVIDENCE POINTS
Endpoint
CLIENT
10.20.4.15
USER REPORT: HTTPS FAILURE
→
Security Edge
FW-EDGE
INSIDE → OUTSIDE
STATEFUL INSPECTION
→
Application
WEB SERVER
203.0.113.20:443
HTTPS SERVICE
FLOW  10.20.4.15:51520 → 203.0.113.20:443 / TCP  ·  SYMPTOM  intermittent HTTPS failure
01 Endpoint
USER REPORT
02 Flow
5-TUPLE
03 Policy
ACL MATCH
04 NAT
TRANSLATION
05 IPS
INSPECTION
06 Application
RESPONSE
Reported Symptom
START HERE
User Impact
“The application works sometimes, but HTTPS requests intermittently fail.”
Fault Injection
SCENARIO
Policy Decision
Does the security policy permit the flow?
NAT Translation
Can the destination flow be translated correctly?
State Table
Does the firewall have consistent flow state?
IPS Inspection
Does inspection detect a threat?
Investigation Confidence
0%
Collect evidence from multiple control points before declaring the fault domain.
Evidence Matrix
CORRELATE BEFORE CONCLUDING
Evidence Expected Observed Interpretation
CLIENT HTTPS request generated Pending Endpoint evidence not yet collected.
FLOW Consistent 5-tuple/state Pending Flow state has not yet been correlated.
POLICY HTTPS permitted Pending Policy result has not yet been confirmed.
NAT Valid translation Pending Translation evidence has not yet been confirmed.
IPS No blocking detection Pending IPS telemetry has not yet been correlated.
APPLICATION HTTPS response Pending Application-side behaviour has not yet been verified.
Investigator Readout
Incident ready
Start with the endpoint symptom, then move through the security path. A single log rarely proves the root cause.
EVIDENCE: none collected
Current Finding
UNRESOLVED
Engineering Principle
Correlation is not causation. An IPS alert, NAT entry or firewall deny becomes meaningful only when its timestamp, flow identity and relationship to the reported failure line up.
SECTION 04 · CORRELATE & OPERATE
Security Control Loop
A security decision is only useful when the engineer can verify its outcome.
01
Detect
Find the signal
02
Correlate
Join the evidence
03
Decide
Assess the threat
04
Prevent
Apply control
05
Verify
Prove the result
Operational readout
Detection is the starting point, not the conclusion. Establish what signal triggered the investigation and gather enough context to determine whether it represents a real security condition.
Investigation confidence
20%
04 · OPERATE · DETECTION & VERIFICATION

Operating the Security Stack: Detection, Prevention and Verification

Security operations do not end when an alert is generated or when a packet is blocked. Effective operation requires a continuous loop in which detection is correlated with context, a decision is made, a control is applied and the resulting behaviour is verified.

The firewall, IPS, threat intelligence, endpoint controls and application visibility should therefore be treated as parts of an operational system rather than isolated security products. Each control contributes a different form of evidence and each has limitations that must be understood during an investigation.

The operational question becomes: Can the security team explain what happened, why the control responded, what changed and whether the resulting security outcome is actually correct?

From detection to response

01 · DETECT Identify the signal A firewall, IPS, endpoint or network control produces an event. Output: security signal
02 · CORRELATE Add context Relate the event to flows, users, applications, timestamps and other telemetry. Output: evidence set
03 · DECIDE Assess the risk Determine whether the event represents a real threat, expected behaviour or a false positive. Output: action decision
04 · PREVENT Apply control Enforce the appropriate policy, inspection or containment response. Output: changed traffic state
05 · VERIFY Prove the result Confirm that the intended security outcome occurred without creating an unintended service failure. Output: validated outcome

Visibility across the security stack

No single telemetry source provides the complete operational picture. Firewall telemetry explains traffic handling, IPS telemetry explains detection, endpoint telemetry provides host-level context and packet capture provides direct evidence of network behaviour.

Secure Firewall / FMC Policy decisions, connection information, security events and operational visibility provide the firewall-side perspective.
IPS / Snort Inspection evidence helps explain protocol behaviour, detection conditions and security actions.
Threat intelligence Reputation and threat context can add information about destinations, indicators or observed activity.
Endpoint telemetry Host-level evidence can show which process, application or endpoint behaviour was associated with the network event.
Application controls URL, file and application visibility can add context beyond basic source and destination information.
Packet analysis tcpdump and Wireshark can provide direct evidence of packets, retransmissions, responses and connection behaviour.
Correlation model
Network Flow
→
Firewall
→
IPS
→
Threat Intel
→
Endpoint
→
Application

Policy tuning and false positives

Security controls must be tuned against observed behaviour. A policy that is too broad may create excessive alerts and unnecessary intervention, while a policy that is too narrow may leave important traffic insufficiently inspected.

The same principle applies to IPS detection. A detection that repeatedly identifies legitimate application behaviour can become operational noise if it is not investigated and tuned appropriately. At the same time, suppressing a detection without understanding why it triggered can remove useful protection.

+
Useful tuning

Start with evidence. Identify the traffic, understand the detection condition, establish whether the behaviour is legitimate and then determine whether a policy or detection adjustment is justified.

!
Dangerous tuning

Avoid disabling or broadly excluding a control simply because it generates an inconvenient alert. Removing a security signal without understanding its cause can hide the original problem.

Verification is part of the change

A security change is incomplete until the resulting behaviour has been verified. Blocking a malicious flow is useful, but the engineer should also confirm that legitimate traffic remains available and that the security telemetry reflects the intended outcome.

Verification should therefore reproduce the relevant traffic and compare the observed result against the expected security policy. This turns a configuration change into an engineering change with measurable evidence.

01 Retest traffic Reproduce the relevant flow after the control change.
02 Check telemetry Confirm logs, counters, events and state reflect the expected result.
03 Check application Verify that legitimate application behaviour remains functional.
04 Confirm security Prove that the intended threat or unwanted flow is now handled correctly.
Engineering evidence
A successful block is not enough

The strongest verification demonstrates both sides of the security requirement: the unwanted traffic is prevented and legitimate traffic continues to operate as intended. Evidence should connect the policy change, observed event, enforcement result and application outcome.

Operate the stack as a feedback loop

The four sections of this guide now form one continuous engineering model. First, understand how a stateful firewall turns a packet into a security decision. Next, understand how IPS inspection adds deeper traffic analysis. Then use those models to investigate an actual failure by following evidence across the security path.

Finally, operate the controls as a feedback loop: detect an event, correlate the surrounding evidence, decide what it means, apply the appropriate prevention or policy action and verify the resulting behaviour.

Engineering model
Detect → Correlate → Decide → Prevent → Verify

Security engineering becomes more reliable when every enforcement decision can be explained by evidence and every security change can be verified against real traffic. The objective is not simply to block threats; it is to understand the complete path from network activity to security decision and prove that the resulting system behaviour is correct.

Engineering Lab · Section 04
Threat Prevention Operations Lab

The final interactive lab turns the operational loop into a live exercise. Detect the event, correlate the evidence, decide how it should be handled, apply the prevention action and verify that the intended security outcome has actually been achieved.

SECURITY OPERATIONS / CONTROL LOOP LAB
Detect → Correlate → Decide → Prevent → Verify
Operate the security stack as an engineering control loop. Investigate a detection, correlate the available telemetry, choose a response, apply prevention and then prove that the resulting policy change actually works.
OPERATIONS READY · AWAITING EVENT
Security Control Loop
STAGE 0 / 5
01
DETECT
Identify the event and establish what actually triggered the alert.
02
CORRELATE
Link flow, identity, endpoint, application and security telemetry.
03
DECIDE
Determine whether the event represents a real threat or false positive.
04
PREVENT
Apply the smallest appropriate security control or policy change.
05
VERIFY
Re-test the flow and confirm the intended security outcome.
Security Stack
FIREWALL + IPS
FMC · SNORT · TALOS
→
Protected Service
HTTPS APPLICATION
203.0.113.20:443
Operational Controls
LIVE POLICY
IPS Prevention
Block confirmed malicious traffic inline.
URL Filtering
Enforce policy for suspicious destinations.
File Inspection
Inspect suspicious files and payload behaviour.
Policy Tuning
Narrow or adjust controls when evidence supports it.
Stack Health
TELEMETRY
Firewall Policy
ACTIVE
IPS Engine
MONITORING
Threat Intelligence
AVAILABLE
Endpoint Telemetry
CONNECTED
Verification
PENDING
Operations Timeline
WAITING FOR EVENT
01
DETECT
Alert or security event enters the operations workflow.
WAIT
02
CORRELATE
Flow, endpoint, policy and threat intelligence evidence are compared.
WAIT
03
DECIDE
The event is classified as threat, benign activity or false positive.
WAIT
04
PREVENT
Appropriate controls are applied without unnecessary policy expansion.
WAIT
05
VERIFY
The same traffic path is tested again and telemetry is checked.
WAIT
Live Operations Readout
Security operations ready
Start the control loop. The objective is to make a security decision, apply the smallest appropriate action and then prove the result.
EVIDENCE → none collected
Operational Outcome
UNRESOLVED
Verification confidence
0%
Engineering Takeaway
A security control is not operationally complete when the alert disappears. The change must be verified against the original traffic and expected service behaviour.
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
rsz_1dc_secreu_5

Data Center Security

Data Center Security — Engineering Guide

Modern data centers are no longer simple collections of physical servers connected to a small number of network segments.

They host business-critical applications, databases, APIs, virtual machines, containers, distributed platforms, cloud-connected services, and increasingly dynamic workloads.

As application architectures have become more distributed, the security model has had to evolve with them.

Traditional security architectures often relied heavily on perimeter firewalls, VLANs, IP addressing, and manually maintained access-control lists. These mechanisms remain important, but they are no longer sufficient by themselves.

Modern applications generate large amounts of east-west traffic between workloads inside the data center.

A web application may communicate with application services.

Application services may communicate with databases.

Microservices may communicate with dozens of other services.

Containers may appear and disappear dynamically.

Cloud workloads may communicate with on-premises infrastructure.

Management, monitoring, backup, identity, and security systems create additional communication relationships.

The result is a highly interconnected environment in which the traditional concept of a single security perimeter becomes increasingly difficult to apply.

From Network Security to Workload Security

Modern data center security therefore needs to answer a different question.

Instead of asking:

Which network is this server connected to?

we increasingly need to ask:

Which workload is this, what does it need to communicate with, and why?

This is the foundation of application-centric security.

Security policy can be associated with applications, workloads, identities, relationships, and risk rather than being permanently tied to physical network locations.

Cisco Application Centric Infrastructure (ACI) provides one example of this approach.

ACI allows application requirements to become part of the network policy model. Endpoint groups, contracts, filters, micro-segmentation, and Layer 4–Layer 7 service integration can be used to express and enforce communication relationships across the fabric.

Security as a Layered Architecture

Modern data center security should not be treated as a single technology.

It is better understood as a series of complementary layers:

Security architecture

↓

Segmentation

↓

Policy

↓

Enforcement

↓

Deep inspection

↓

Telemetry

↓

Detection

↓

Response

Each layer addresses a different problem.

Physical and infrastructure controls protect the underlying environment.

Segmentation reduces the size of security boundaries.

Policy defines authorised relationships.

Distributed enforcement prevents unauthorised communication.

Firewalls and other Layer 4–Layer 7 services provide deeper inspection.

Telemetry provides visibility into what is actually happening.

Analytics identify abnormal behaviour.

Response mechanisms allow compromised workloads to be contained.

The Data Center Security Engineering Model

This guide develops that model across four sections.

Section 1 — Security Architecture

Examines the different security layers that protect modern data centers, including physical, network, compute, storage, application, cloud, identity, observability, and resilience controls.

Section 2 — Segmentation and Policy

Explores how security requirements become enforceable communication relationships using concepts such as EPGs, ESGs, contracts, filters, and micro-segmentation.

Section 3 — Enforcement and L4–L7 Services

Examines how authorised and unauthorised traffic is enforced within the fabric and how deeper inspection can be integrated through firewalls, IPS, load balancers, service graphs, and policy-based redirect.

Section 4 — Visibility, Detection and Adaptive Defence

Moves beyond preventative controls into telemetry, behavioural analysis, security analytics, incident investigation, risk-based enforcement, containment, and adaptive security.

The Core Principle

The objective is not simply to prevent every possible connection.

The objective is to create an environment where:

Required communication is explicitly permitted, unnecessary communication is restricted, abnormal behaviour is visible, and compromised workloads can be contained before they become a larger incident.

That is the foundation of a modern, policy-driven data center security architecture.


Engineering Guide Structure

1. Security Architecture

Understand the layers that protect the modern data center.

2. Segmentation and Policy

Define which workloads should communicate and under what conditions.

3. Enforcement and L4–L7 Services

Enforce those relationships and introduce deeper inspection where required.

4. Visibility, Detection and Adaptive Defence

Observe the environment, identify abnormal behaviour, investigate incidents, and respond to changing risk.

The Complete Security Loop

Understand → Segment → Enforce → Inspect → Observe → Detect → Respond

Data Center Security Architecture

Engineering Guide · Data Center Security Interactive Contents

From Segmentation to Adaptive Defense

Use the four engineering sections below to move from security foundations and policy design through distributed enforcement, visibility, incident response and adaptive defense.

01
ARCHITECT
Build the security foundation
02
SEGMENT
Define workload relationships
03
ENFORCE
Apply distributed security policy
04
DETECT & RESPOND
Investigate and contain threats
Engineering path: Architect the environment → segment workloads → enforce policy → detect, contain and recover.
SECTION 01 · SECURITY FOUNDATIONS
Engineering Guide
Data Center Security Techniques
Build Security as a Layered Control System

Data center security is not a single firewall, ACL or security product. It is a layered engineering model spanning physical infrastructure, network segmentation, workloads, applications, identity, telemetry and incident response.

01
Protect
Physical infrastructure and critical assets
02
Segment
Reduce unnecessary workload communication
03
Verify
Use identity, context and behaviour
04
Observe
Detect, investigate and respond
What You Will Learn

How modern data center security combines segmentation, least privilege, identity, workload protection, observability and resilience rather than relying on a single perimeter control.

Engineering Focus

The objective is to make every communication path intentional, observable and enforceable — from physical infrastructure through application workloads.

Engineering Question
If a workload is compromised inside the data center, what prevents the attacker from moving laterally to the next application, database or security boundary?

1. Data Center Security Architecture

Data center security is not a single control or appliance.

A modern data center requires multiple security layers working together to protect physical infrastructure, networks, workloads, applications, data, identities, and operational processes.

The objective is to prevent unauthorised access, reduce the attack surface, detect abnormal behaviour, limit lateral movement, and maintain resilience when security controls fail or an incident occurs.

A useful way to approach data center security is to consider the environment as a series of interconnected security domains.

1.1 The Security Layers

A modern data center can include:

  • Physical security

  • Network security

  • Segmentation

  • Compute security

  • Storage security

  • Application security

  • Cloud and hybrid security

  • Identity and access control

  • Observability

  • Threat detection

  • Incident response

  • Resilience and recovery

These layers should not operate independently.

A compromised workload may generate network traffic.

Network telemetry may identify the behaviour.

Identity telemetry may identify the associated user or service.

Endpoint security may provide additional evidence.

Security analytics can correlate the events.

A response system can then contain the workload.

This is the basis of layered defence.

1.2 Physical Security

The physical environment remains the first security boundary.

Controls can include:

  • Controlled facility access

  • Badge authentication

  • Biometrics

  • Surveillance

  • Security personnel

  • Restricted data center areas

  • Rack security

  • Tamper detection

  • Secure cabling

  • Environmental monitoring

Physical security is particularly important because compromise of the physical infrastructure can undermine otherwise strong logical controls.

An attacker who gains direct access to infrastructure may be able to bypass network-based assumptions.

1.3 Network Security

The network provides the communication foundation for the data center.

Traditional controls include:

  • VLAN segmentation

  • VRF isolation

  • ACLs

  • Firewalls

  • Routing policy

  • Network security zones

  • IDS/IPS

  • VPNs

  • Encryption

  • Network telemetry

However, modern applications increasingly require security controls that understand workloads and application relationships rather than only addresses and interfaces.

1.4 East-West Security

Traditional perimeter security focuses heavily on north-south traffic.

Modern data centers also require strong east-west security.

For example:

WEB → APP

APP → DB

APP → CACHE

SERVICE → SERVICE

MONITORING → WORKLOAD

If an attacker compromises one workload, east-west controls determine how easily that attacker can move to other systems.

This makes internal segmentation a fundamental security requirement.

1.5 Compute Security

The compute layer introduces additional security boundaries.

Virtualisation platforms such as:

  • VMware ESXi

  • Microsoft Hyper-V

  • KVM

can provide workload isolation, but the hypervisor itself must also be protected.

Important controls include:

  • Secure boot

  • Host hardening

  • Patch management

  • Hypervisor security

  • VM isolation

  • Privileged-access controls

  • Host monitoring

Containerised environments introduce additional controls.

These can include:

  • Container image security

  • Runtime protection

  • Namespace isolation

  • Kubernetes network policy

  • Workload identity

  • Runtime behaviour monitoring

The objective is to ensure that compromise of one workload does not automatically provide unrestricted access to others.

1.6 Storage Security

Storage frequently contains the most valuable information in the environment.

Security controls can include:

  • Encryption at rest

  • Encryption in transit

  • Access control

  • Storage segmentation

  • Immutable backups

  • Protected snapshots

  • Replication

  • Backup isolation

  • Recovery testing

Ransomware resilience is particularly important.

A backup that is accessible through the same credentials and security boundaries as production systems may be vulnerable to the same compromise.

Security therefore needs to extend into the recovery architecture.

1.7 Application Security

Applications introduce another security layer.

Controls can include:

  • Web Application Firewalls

  • API gateways

  • Application authentication

  • Secret management

  • Secure CI/CD

  • Dependency scanning

  • Code security testing

  • Runtime protection

  • Application logging

Application security and network security should complement one another.

A secure network cannot compensate for an insecure application, and an application security control cannot replace appropriate network segmentation.

1.8 Cloud and Hybrid Security

Modern data centers increasingly operate across:

On-premises infrastructure

  •  

Private cloud

  •  

Public cloud

  •  

Kubernetes

  •  

SaaS

Security policy therefore has to extend beyond the physical data center.

Cloud environments introduce controls such as:

  • VPC/VNet segmentation

  • Security groups

  • Cloud firewalls

  • IAM

  • Workload identity

  • Private connectivity

  • Cloud logging

  • Cloud security posture management

  • Service-to-service policy

The important principle is consistency.

A workload should not become significantly less protected simply because it has moved from an on-premises environment into a cloud environment.

1.9 Zero Trust

Zero Trust changes the assumption that internal network location automatically implies trust.

Instead of:

Internal network = trusted

the model becomes:

Access must be explicitly authorised.

Important principles include:

  • Least privilege

  • Explicit authentication

  • Continuous verification

  • Identity-aware policy

  • Device posture

  • Workload identity

  • Encryption

  • Deny-by-default principles

Zero Trust therefore complements segmentation.

Segmentation limits communication.

Identity determines who or what is requesting access.

Risk determines whether the communication should remain trusted.

1.10 Identity-Driven Security

Identity provides context that IP addresses cannot.

A network address tells us where traffic is coming from.

Identity can tell us:

  • Which user is involved

  • Which workload is involved

  • Which service account is involved

  • Which device is involved

  • Which application is involved

  • What privileges are associated with the request

This enables more contextual security decisions.

For example:

User identity

  •  

Device posture

  •  

Application

  •  

Network location

  •  

Risk

can produce a much stronger security decision than IP address alone.

1.11 Observability

Security requires visibility.

Important telemetry sources include:

  • NetFlow

  • IPFIX

  • Packet capture

  • Firewall logs

  • DNS logs

  • Authentication logs

  • Endpoint telemetry

  • Application logs

  • Cloud logs

  • Kubernetes telemetry

  • Distributed tracing

Tools and platforms can include:

  • SIEM

  • SOAR

  • EDR/XDR

  • Prometheus

  • Grafana

  • OpenTelemetry

The objective is not to collect every possible event.

The objective is to collect enough meaningful evidence to understand:

What happened?

Who or what was involved?

What changed?

What was affected?

What should happen next?

1.12 Incident Response and Resilience

Prevention will never be perfect.

A mature security architecture therefore assumes that incidents will occur and prepares for them.

Important capabilities include:

  • Incident response plans

  • Security runbooks

  • Automated containment

  • Backup and recovery

  • Disaster recovery

  • Tabletop exercises

  • Recovery testing

  • Crisis communication

  • Forensic evidence collection

The architecture should allow security teams to move from:

Detection

to

Investigation

to

Containment

to

Recovery

without requiring the network to be redesigned during the incident.

1.13 Security Analytics

Modern environments generate too many events for manual analysis alone.

Analytics can identify:

  • Unexpected communication

  • Lateral movement

  • Privilege escalation

  • Abnormal traffic

  • Unusual authentication

  • Misconfiguration

  • Excessive permissions

  • Unused policy

  • Shadow workloads

  • Unexpected exposure

The value comes from correlation.

A single unusual connection may be harmless.

The same connection combined with:

  • unusual authentication

  • abnormal process activity

  • unexpected DNS queries

  • increased traffic

may become a high-value security signal.

1.14 Adaptive Security

Modern security architectures increasingly need to respond to changing conditions.

For example:

Normal workload

→ normal policy

Suspicious workload

→ increased monitoring

High-risk workload

→ restricted communication

Compromised workload

→ quarantine

This introduces a feedback loop between security telemetry and enforcement.

1.15 Engineering Model

A useful architecture is:

Physical security

↓

Network security

↓

Segmentation

↓

Workload security

↓

Application security

↓

Identity

↓

Observability

↓

Detection

↓

Response

↓

Recovery

No individual layer is sufficient.

The strength of the architecture comes from how these controls work together.

1.16 Section 1 Engineering Principle

The modern data center should therefore be treated as a distributed security system, not simply a collection of network devices.

The architecture must understand:

  • Where workloads are located

  • What those workloads represent

  • Who or what can access them

  • Which services they require

  • How they communicate

  • What normal behaviour looks like

  • How abnormal behaviour will be detected

  • How compromised workloads will be contained

This provides the foundation for the next stage:

How do we turn these security requirements into enforceable communication policy?

ENGINEERING EXPLORER · DATA CENTER SECURITY
Trace a Workload Through the Security Architecture
Follow a workload from identity and segmentation through policy enforcement, inspection, telemetry and response. Step through the architecture to see where each security decision is made.
Security Control Path
Stage 1 of 8
01
Workload
The application workload generates traffic toward another service.
ACTIVE
02
Identity
Workload identity, role and contextual attributes establish who is communicating.
WAITING
03
Segmentation
The workload is classified into the appropriate security boundary or group.
WAITING
04
Policy
Application relationship, contract, rule or security policy determines whether communication is permitted.
WAITING
05
Inspection
Selected traffic can be redirected through firewall, IDS/IPS, WAF or other security services.
WAITING
06
Telemetry
Flow, packet, endpoint, identity and application signals provide evidence about the communication.
WAITING
07
Detection & Decision
Correlation and analytics determine whether the observed behaviour remains trusted.
WAITING
08
Response
The architecture can allow, monitor, block, isolate or quarantine the workload.
WAITING
Current Security Layer
Workload

The workload is the starting point for the security decision. Modern data-center security begins by understanding what is communicating, rather than relying only on its IP address or VLAN.

Control
Workload classification
Security Question
What is this workload?
Evidence
Workload attributes
Decision
Identify
Architecture Progress 12%
Live Security Readout
Source WEB-01
Destination APP-01
Traffic HTTPS / TCP 443
Trust State Unknown
Action Classify
Security Decision Timeline
Live execution
Workload
Identity
Segmentation
Policy
Inspection
Telemetry
Decision
Response
NORMAL TRAFFIC

WEB-01 is making an expected HTTPS request to APP-01. The security architecture evaluates the communication progressively.

Anomalous east-west behaviour detected. The architecture must now evaluate risk and determine whether the workload should be monitored, blocked or isolated.

Segmentation and Security Policy

SECTION 02 · POLICY & SEGMENTATION
Engineering Guide
Segmentation, Policy and Security Enforcement
Turn Application Relationships into Security Policy

Modern data center security increasingly moves beyond the question of which subnet or VLAN a workload occupies. The engineering problem is to define which workloads should communicate, under which conditions, and what happens when that relationship is not permitted.

01 · CLASSIFY
Identify Workloads
Group endpoints according to application, role, identity and security context.
02 · DEFINE
Define Relationships
Specify the communication paths an application actually requires.
03 · ENFORCE
Apply Policy
Permit, restrict, inspect or isolate traffic according to explicit policy.
What You Will Learn

How EPGs, contracts, filters, security groups, micro-segmentation and cloud security boundaries translate application requirements into enforceable policy.

Engineering Focus

Good segmentation is not about creating as many zones as possible. It is about creating clear security boundaries with explicit communication relationships that can be understood, tested and maintained.

Engineering Question
If WEB, APP and DB workloads belong to different security groups, what explicit policy should allow — or prevent — each communication path between them?

2. Segmentation and Security Policy

Once the security architecture has been established, the next engineering question is:

Which workloads should be allowed to communicate, and why?

Traditional data center security often relied on VLANs, IP subnets, interfaces and ACLs.

These mechanisms remain useful, but modern applications require a more expressive model.

An application may contain multiple workload types, and those workloads may move across the infrastructure.

Security policy therefore needs to follow the application relationship, rather than simply the physical location of a server.

2.1 From Network Segmentation to Policy Segmentation

Traditional segmentation might look like:

VLAN 10 → Web

VLAN 20 → Application

VLAN 30 → Database

This creates useful boundaries, but it does not automatically define which communication is permitted.

A more complete model is:

WEB

↓

Application policy

↓

APP

↓

Application policy

↓

DB

The important question becomes:

What relationship exists between these workloads?

2.2 Designing Segmentation Around Application Relationships

Consider a three-tier application:

Web

↓

Application

↓

Database

The security policy may require:

  • Web can communicate with application services

  • Application can communicate with databases

  • Web cannot directly access databases

  • Management systems can access approved administrative interfaces

  • Monitoring systems can collect telemetry

  • Backup systems can access protected storage

This is much more precise than simply defining three VLANs.

The security architecture is now based on relationships.

2.3 Micro-Segmentation

Large security zones can create excessive trust.

If hundreds of workloads share the same security boundary, compromise of one workload may provide an attacker with many possible lateral-movement paths.

Micro-segmentation reduces these trust relationships.

Instead of:

Production → Production

we can define:

WEB → APP

APP → DB

MONITORING → WORKLOAD

BACKUP → STORAGE

Each relationship can be independently controlled.

2.4 Policy as the Security Contract

A useful way to think about security policy is as a contract between workloads.

The policy states:

This workload is allowed to communicate with that workload using these services.

For example:

APP → DB

Allowed:

TCP/5432

Not automatically allowed:

SSH

RDP

SMB

Other unnecessary services

This produces a least-privilege communication model.

2.5 Cisco ACI and Policy-Based Segmentation

Cisco ACI provides an application-centric policy framework.

Rather than configuring every security rule independently on physical interfaces, administrators can define groups of endpoints and relationships between those groups.

Important constructs include:

  • Endpoint Groups

  • Contracts

  • Filters

  • Endpoint Security Groups

  • Micro-segmentation

  • L3Out policy

  • Layer 4–Layer 7 service integration

These constructs allow policy to be represented in terms of applications and workloads.

2.6 Endpoint Groups

An Endpoint Group, or EPG, provides a mechanism for grouping endpoints that share common policy requirements.

An EPG can represent a logical application tier such as:

WEB-EPG

APP-EPG

DB-EPG

Security policy can then be applied to the relationships between these groups.

This provides a more scalable model than individually managing every endpoint.

2.7 Contracts

Contracts define communication relationships between EPGs.

For example:

WEB-EPG

↓

WEB-TO-APP contract

↓

APP-EPG

The contract can reference filters describing the traffic that is permitted.

This allows the policy to express both:

  • Who may communicate

  • What traffic is allowed

2.8 Filters and Least Privilege

A filter defines traffic characteristics such as protocol and ports.

For example:

TCP/443

or:

TCP/5432

The security model can therefore become:

Group

→ Contract

→ Filter

→ Permitted traffic

This is more meaningful than simply allowing an entire subnet to communicate.

2.9 EPGs, Contracts and the Security Boundary

The relationship between the endpoint group and contract becomes the security boundary.

For example:

WEB-EPG

can communicate with:

APP-EPG

because a contract exists.

However:

WEB-EPG

cannot directly communicate with:

DB-EPG

unless an appropriate policy relationship exists.

This creates an explicit application communication model.

2.10 Endpoint Security Groups

Endpoint Security Groups, or ESGs, provide an additional security-oriented abstraction within ACI.

They allow security classification to be separated from some of the forwarding relationships that historically constrained EPG-based designs.

This can provide greater flexibility when applying security policy across workloads.

The important concept is:

Security classification does not always have to map directly to a traditional network segment.

This becomes increasingly valuable in environments containing dynamic workloads.

2.11 Micro-Segmentation Across Distributed Workloads

Micro-segmentation becomes particularly useful when workloads that appear similar from a network perspective require different security treatment.

For example:

Production APP

and

Development APP

may share infrastructure but should not necessarily share identical security policy.

Similarly:

Windows workloads

and

Linux workloads

may require different treatment during a security incident.

Micro-segmentation provides additional classification mechanisms that can support these requirements.

2.12 L4–L7 Security Service Integration

Segmentation determines whether communication should occur.

Sometimes that is not enough.

A security architecture may also require:

  • Firewall inspection

  • IPS

  • Load balancing

  • Application security

  • Other L4–L7 services

This introduces a second question:

If the traffic is permitted, does it also require deeper inspection?

That distinction becomes the focus of Section 3.

2.13 Cloud Security Perimeters

Segmentation is not limited to the physical data center.

Cloud environments require similar principles.

For example, Google Cloud VPC Service Controls can establish security perimeters around supported cloud resources to help reduce the risk of unauthorised data movement.

The important principle is that cloud security boundaries should complement:

  • IAM

  • Network controls

  • Workload identity

  • Logging

  • Application security

No single cloud perimeter replaces identity or application-level authorisation.

2.14 Cloud Edge Protection

Cloud environments may also require edge protection.

Cloud security services can provide capabilities such as:

  • DDoS protection

  • WAF

  • Security policy

  • Threat detection

  • Edge traffic controls

These controls protect applications before traffic reaches the workload environment.

2.15 Hybrid Security

Hybrid architectures may contain:

Data center

↓

Cloud connectivity

↓

Cloud VPC

↓

Managed services

↓

Internet-facing applications

The security model therefore has to remain consistent across these boundaries.

Security policy should identify:

  • Which workloads communicate

  • Which services are exposed

  • Which identities are trusted

  • Which traffic is permitted

  • Where deeper inspection is required

2.16 Private Service Connectivity

Private connectivity mechanisms such as Private Service Connect can provide private access to supported services without requiring workloads to use public IP paths for that service relationship.

However, private connectivity should not be confused with authorisation.

A private connection answers:

How does the traffic reach the service?

Security policy still needs to answer:

Is this workload authorised to use the service?

Connectivity and authorisation are separate security concerns.

2.17 Traditional ACL-Based Security

Traditional ACLs remain useful.

They are particularly appropriate for:

  • Infrastructure filtering

  • Management-plane protection

  • Simple protocol restrictions

  • Layer 2 controls

  • Specific interface requirements

The problem occurs when ACLs become the only mechanism used to represent complex application security.

At that point, the configuration can become difficult to understand and maintain.

2.18 MAC ACLs

MAC-based filtering can be useful for Layer 2 security requirements.

It can control traffic based on source or destination MAC information.

This is a more granular mechanism than simply trusting an entire VLAN, but it remains a relatively low-level security control.

2.19 VLAN ACLs

VLAN-based access controls can provide filtering for traffic associated with particular VLANs.

They remain useful for specific infrastructure requirements, but they do not provide the same application-centric abstraction as workload groups and contracts.

2.20 Policy as a Layered Enforcement Model

A mature security architecture can therefore combine:

Traditional ACLs

  •  

EPGs

  •  

ESGs

  •  

Contracts

  •  

Filters

  •  

Micro-segmentation

  •  

L4–L7 services

The controls are complementary.

The objective is not to eliminate traditional networking controls.

The objective is to place each control at the appropriate architectural layer.

2.21 Engineering Design Principles

A modern segmentation architecture should follow several principles.

Start with communication requirements

Determine which workloads actually need to communicate.

Apply least privilege

Permit only the protocols and services required.

Minimise security zones

Avoid unnecessarily large trust boundaries.

Make policy application-centric

Express policy in terms of workloads and application relationships where possible.

Separate segmentation from deep inspection

A communication relationship being permitted does not mean that the traffic requires no further inspection.

Design for mobility

Policy should remain meaningful as workloads move.

Build quarantine capability

Compromised workloads should be capable of being isolated.

2.22 The Result: Policy-Driven Segmentation

The traditional security model can be represented as:

Interface → ACL → IP address → Rule

The application-centric model becomes:

Workload → Group → Contract → Filter → Enforcement

This allows the security architecture to follow the workload rather than simply following the physical topology.

The key engineering question becomes:

Who should communicate, what should they communicate with, and which traffic is actually required?

Once that policy has been established, the next challenge is enforcing it and introducing deeper inspection where necessary.

ENGINEERING LAB · MICRO-SEGMENTATION
Build the Security Policy
Select the workload relationship, application context and security controls. The policy engine evaluates the resulting communication and explains why traffic should be allowed, denied, inspected or quarantined.
Policy Builder
Construct communication intent
Source Workload
WEB-01
EPG: WEB
Role: Front-End
→
Destination Workload
APP-01
EPG: APP
Role: Application Tier
APP-WEB-CONTRACT
ACTIVE
Source classification WEB EPG
Application relationship HTTPS
Security context Trusted
Enforcement Permit
Policy Engine Decision
ALLOW
Expected WEB → APP HTTPS communication matches the security policy.
Risk Score 18 / 100
Decision Evidence
Source Group WEB
Destination APP
Application HTTPS
Identity Web Role
Context Trusted
Policy Path

The communication is evaluated against identity, segmentation, application relationship and risk before the final action is applied.

IDENTITY
→
SEGMENT
→
CONTRACT
→
RISK
→
DECISION
Security policy has detected a communication pattern that does not match the expected workload relationship.
Engineering Principle

Micro-segmentation is not simply creating more VLANs. The objective is to express which workloads may communicate, under which conditions, and with which security controls.

Data Center Security with Cisco ACI

SECTION 03 · ENFORCEMENT & INSPECTION
Engineering Guide
Data Center Security with Cisco ACI
From Security Policy to Distributed Enforcement

Once security relationships have been defined, the next engineering challenge is enforcement. Cisco ACI provides a policy-driven fabric model for segmentation and communication control, while dedicated security services can provide deeper inspection where required.

01 · CLASSIFY
Endpoint Groups
Represent workloads according to application and security role.
02 · AUTHORISE
Contracts
Define which communication relationships are permitted.
03 · ENFORCE
Fabric Policy
Apply distributed policy close to the relevant endpoints.
04 · INSPECT
Security Services
Steer selected traffic through firewalls or inspection services.
What You Will Learn

How EPGs, contracts, filters, micro-segmentation, uSeg/µEPG concepts and service graphs can be combined to enforce application-aware security policy.

Engineering Focus

ACI segmentation should not be treated as a replacement for every security appliance. Use the fabric for segmentation and policy enforcement, and dedicated security services when deeper inspection is required.

Engineering Question
Which traffic should be controlled directly by the fabric, and which traffic should be deliberately redirected through a firewall, IDS/IPS or other L4–L7 security service?

3. Data Center Security with Cisco ACI

Cisco ACI provides a policy-driven framework for implementing segmentation and security enforcement across the data center fabric.

Sections 1 and 2 established the architecture and policy model.

This section moves to the next question:

How is that policy actually enforced, and when do we need deeper security inspection?

ACI can enforce communication relationships between groups of endpoints through constructs such as EPGs, ESGs, contracts, and filters.

However, segmentation and policy enforcement should not be confused with complete deep-packet or application security inspection.

A modern architecture can therefore combine:

Workload identity → Segmentation → Contract → Filter → Traffic steering → Security service → Application

3.1 Application-Centric Security

Traditional security often begins with the physical or logical location of a device.

Application-centric security begins with the workload.

Instead of asking:

Which VLAN is this server connected to?

we ask:

What workload is this, what application does it belong to, and what should it communicate with?

ACI allows these application relationships to become part of the infrastructure policy model.

3.2 The ACI Allowlist Model

ACI uses an allowlist-oriented policy model.

Communication between endpoint groups requires appropriate policy.

For example:

WEB → APP

Allowed:

TCP/443

The existence of a policy relationship does not mean that all traffic between the workloads should be permitted.

Filters can restrict the relationship to the services actually required.

This supports least-privilege communication.

3.3 Segmentation Is Not a Next-Generation Firewall

This distinction is important.

ACI provides distributed policy enforcement inside the fabric.

It can determine:

  • Which endpoint groups are communicating

  • Whether a policy relationship exists

  • Which traffic is permitted

  • Which protocols and ports are allowed

However, deeper security functions may require dedicated services.

These can include:

  • Next-generation firewalls

  • IPS

  • Application security

  • Load balancers

  • Other L4–L7 services

Therefore:

ACI segmentation ≠ complete security inspection

Instead:

ACI segmentation + security services = layered enforcement

3.4 Contracts as Enforcement Policy

A contract establishes the policy relationship between endpoint groups.

For example:

APP-EPG

↓

APP-TO-DB

↓

DB-EPG

The contract can reference filters that define the permitted traffic.

This separates:

Relationship

from

Traffic definition

The policy therefore becomes easier to understand and reuse.

3.5 The Challenge with Static ACLs

Traditional ACLs can become increasingly complex as applications grow.

Rules may contain:

  • Source addresses

  • Destination addresses

  • Protocols

  • Ports

  • Interfaces

  • Exceptions

  • Temporary rules

As the environment changes, administrators may add additional rules without removing old ones.

This creates policy accumulation.

Over time, the ACL may still function but become difficult to understand.

A security policy that cannot be easily understood is difficult to audit and maintain.

3.6 Topology-Independent Policy

One of the important advantages of an application-centric policy model is that security relationships are not permanently tied to individual interfaces.

The conceptual model becomes:

Endpoint → Group → Policy → Contract → Filter

rather than:

Interface → ACL → Address → Rule

This allows policy to remain meaningful as workloads move within the fabric.

3.7 Micro-Segmentation

Large security zones can create excessive trust.

If hundreds of workloads share the same broad security boundary, compromise of one workload can provide an attacker with opportunities for lateral movement.

Micro-segmentation reduces these trust relationships.

Instead of:

Production → Production

we can define:

WEB → APP

APP → DB

MONITORING → WORKLOAD

BACKUP → STORAGE

3.8 EPGs and ESGs

EPGs provide a fundamental mechanism for grouping endpoints and applying common policy.

ESGs provide an additional security-oriented abstraction that can offer greater flexibility when classifying workloads for security policy.

The important engineering principle is that security classification does not always need to map directly onto a single traditional network segment.

3.9 Micro-Segmentation with Additional Endpoint Attributes

ACI micro-segmentation capabilities can provide more granular classification of endpoints.

This can be useful when workloads inside the same broader application environment require different security treatment.

For example:

Production APP

and

Development APP

may require different security policies.

Similarly:

Windows workloads

and

Linux workloads

may require different treatment during an incident.

3.10 Example: Workload Quarantine

Imagine an application environment containing both Windows and Linux workloads.

A security team identifies a vulnerability affecting the Windows workload population.

Instead of manually modifying policies for every individual host, the affected workloads can be classified into a more restrictive security policy where the architecture supports the required classification.

The resulting model is:

Normal workload

↓

Normal application policy

After compromise:

Affected workload

↓

Restricted communication

↓

Security / remediation services

This demonstrates an important security principle:

Containment should reduce the blast radius without requiring the entire application architecture to be redesigned.

3.11 L4–L7 Security Services

Segmentation determines whether communication should occur.

Deep inspection determines whether permitted traffic is safe or appropriate according to additional security criteria.

Potential security services include:

  • Firewalls

  • IPS

  • Load balancers

  • Application security platforms

  • Other L4–L7 services

This introduces the next layer of the architecture.

3.12 Cisco Secure Firewall Integration

Cisco security platforms can be integrated into ACI-based architectures where deeper inspection is required.

A dedicated firewall can provide capabilities beyond distributed fabric policy, depending on the platform and deployment.

These may include:

  • Stateful firewalling

  • Intrusion prevention

  • Threat inspection

  • Application-aware security

  • VPN services

  • Security logging

The architectural principle is:

ACI determines which traffic requires additional policy enforcement.

The security service performs the deeper inspection.

3.13 Policy-Based Redirect

Policy-based redirect provides a mechanism for steering selected traffic towards a service node.

Conceptually:

WEB → APP

Normal flow:

WEB → APP

Traffic requiring inspection:

WEB → Firewall → APP

This means that not every communication flow necessarily has to traverse the same security appliance.

Inspection can be applied according to application and security policy.

3.14 ACI L4–L7 Services

ACI can integrate Layer 4–Layer 7 services into the application policy model.

Potential services include:

  • Firewalls

  • IPS

  • Load balancers

  • Application delivery services

  • Other supported security appliances

This allows security functions to become part of the traffic-processing architecture.

3.15 Service Graphs

A service graph represents a logical processing path through integrated services.

For example:

Consumer

↓

Firewall

↓

IPS

↓

Load Balancer

↓

Provider

Each service can perform a different function.

The graph therefore describes the intended service chain rather than simply representing a physical sequence of network devices.

3.16 Selective Traffic Inspection

Not every flow necessarily requires the same level of inspection.

For example:

TrafficSecurity approach
WEB → APPApplication-aware inspection
APP → DBRestricted database traffic
Monitoring → WorkloadPermit required telemetry
Backup → StoragePermit approved backup services
Unknown → ProductionDeny
Quarantined → ApplicationRestrict

Inspection should therefore be based on:

  • Application requirements

  • Security risk

  • Performance

  • Capacity

  • Compliance

  • Operational requirements

3.17 Distributed Enforcement and Centralised Policy

ACI combines:

Centralised policy definition

with:

Distributed enforcement

This allows policy to be centrally managed while enforcement occurs within the fabric.

Dedicated L4–L7 services can then provide deeper inspection where required.

The architecture becomes:

APIC

↓

Policy

↓

ACI Fabric

↓

Distributed enforcement

↓

L4–L7 Security Services

↓

Inspection

This separation makes the overall security architecture easier to reason about.

3.18 Security Enforcement as a Layered Model

A complete enforcement architecture can therefore be represented as:

Endpoint classification

↓

Segmentation

↓

Contract

↓

Filter

↓

Traffic steering

↓

Deep inspection

↓

Telemetry

Each layer answers a different question.

LayerQuestion
EndpointWhat is communicating?
GroupWhat security class does it belong to?
ContractAre these groups allowed to communicate?
FilterWhich traffic is permitted?
RedirectDoes the flow require a service?
InspectionDoes deeper security analysis occur?
TelemetryWhat actually happened?

3.19 Example: Web Application Security

Consider:

WEB → APP → DB

The security policy may be:

WEB → APP

TCP/443 permitted.

APP → DB

Only required database traffic permitted.

WEB → DB

No direct communication.

Management → Workloads

Restricted to approved management systems.

Unknown → Production

Denied.

Selected application traffic can then be steered through appropriate security services.

3.20 Security Enforcement and Lateral Movement

Suppose an attacker compromises a web server.

Without effective segmentation:

WEB

↓

APP

↓

DB

↓

Management

↓

Backup

The attacker may have multiple paths to additional systems.

With application-centric segmentation:

WEB

↓

APP

↓

Policy boundary

↓

DB

Each relationship becomes another security decision.

If the workload is later identified as compromised, its policy can be restricted further.

3.21 Enforcement as Part of a Feedback Loop

Security enforcement should not operate independently of visibility.

A policy may state:

WEB can communicate with APP using TCP/443.

Telemetry may later show:

WEB has started communicating with unexpected destinations.

That behaviour becomes a security signal.

The architecture can then move towards:

Observe → Analyse → Restrict → Investigate

This connects directly with Section 4.

3.22 Engineering Design Principles

A modern enforcement architecture should:

  • Start with application relationships

  • Use least privilege

  • Separate segmentation from deep inspection

  • Use micro-segmentation where required

  • Steer appropriate traffic through security services

  • Avoid unnecessary inspection paths

  • Design for workload mobility

  • Provide quarantine capability

  • Collect telemetry from enforcement points

3.23 The Result: Policy-Driven Enforcement

The traditional model is:

Interface → ACL → Address → Rule

The application-centric model becomes:

Workload → Group → Contract → Filter → Service → Inspection

The network fabric enforces the communication relationship.

Dedicated security services provide deeper inspection.

Telemetry validates what actually occurred.

The result is a layered security architecture in which each technology performs a specific role.

ENGINEERING SIMULATOR · CISCO ACI · L4–L7 SERVICES
Trace Traffic Through a Service Graph
Select the services required by the security architecture, then step the application flow through the ACI fabric. The simulator shows where policy-based redirection inserts inspection services into the forwarding path.
Traffic Service Path
Stage 1 of 7
W
WEB
Source Workload
A
ACI FABRIC
Policy / Fabric
F
FIREWALL
Security Service
I
IDS / IPS
Inspection
L
LOAD BALANCER
L4–L7 Service
A
APP
Destination
Policy-Based Redirect: selected traffic can be classified by policy and redirected through an appropriate service node rather than requiring every traffic flow to traverse the same security appliance.
Service Controls
Click / tap to change
Security Contract
Permit the application relationship
Policy Redirect
Steer matching traffic into services
Firewall
Stateful security inspection
IDS / IPS
Threat detection / prevention
Load Balancer
Application delivery function
Forwarding Decision
FORWARD
WEB traffic is entering the ACI fabric and the selected service chain will determine its next hop.
Live Readout
Source WEB-01
Destination APP-01
Protocol HTTPS / 443
Current Node WEB
Next Function ACI Fabric
Service Chain Timeline
Packet execution
WEB workload generates HTTPS request
ACI policy classifies the traffic
Policy-based redirect selects service path
Firewall inspection
IDS / IPS inspection
Load-balancing function
APP workload receives traffic
Engineering Principle

ACI provides policy-driven traffic classification and can steer selected flows toward integrated L4–L7 services. The fabric's segmentation policy and dedicated inspection functions solve different security problems.

Inspection has been removed from the selected path. The traffic can still be forwarded when policy permits it, but the security architecture has lost a layer of inspection.

Visibility, Detection and Adaptive Defence

SECTION 04 · VISIBILITY & RESPONSE
Engineering Guide
Visibility, Detection, Response and Adaptive Defense
Detect the Anomaly, Decide the Risk, Contain the Threat

Segmentation and enforcement reduce the available attack surface, but security does not end when a policy is deployed. Modern data centers also need continuous visibility, correlated evidence, incident investigation and a controlled path from detection to containment and recovery.

01 · OBSERVE
Collect Evidence
Flow, endpoint, identity, application and security telemetry.
02 · DETECT
Correlate Signals
Identify unusual behaviour and changes from the expected baseline.
03 · RESPOND
Contain Risk
Block, isolate or quarantine affected workloads when justified.
04 · RECOVER
Validate & Restore
Remediate, restore services and verify the security boundary.
What You Will Learn

How flow telemetry, packet visibility, SIEM/SOAR, EDR/XDR, identity context and behavioural analysis can be combined to investigate east-west security events.

Engineering Focus

The objective is not simply to generate more alerts. It is to build a measurable control loop where evidence leads to a decision, the decision drives enforcement, and the result is verified.

Engineering Question
When a normally trusted workload suddenly communicates with an unexpected system, how quickly can the environment detect the change, determine its significance and contain the risk?

4. Visibility, Detection and Adaptive Defence

Sections 1–3 established the security architecture:

Security architecture → segmentation → policy → enforcement → inspection

However, preventative controls alone are not enough.

A policy can define what should happen.

Telemetry tells us what actually happened.

A firewall may permit a connection.

A workload may still behave abnormally.

A correctly segmented server may still become compromised.

Modern data center security therefore requires a continuous feedback loop:

Observe → Analyse → Detect → Investigate → Respond → Validate

4.1 From Security Policy to Security Observability

Consider a simple policy:

WEB → APP

Allowed:

TCP/443

From a policy perspective, the relationship is correct.

But telemetry might reveal:

  • A sudden increase in connections

  • Unexpected traffic volumes

  • Repeated failed connections

  • Communication with previously unused endpoints

  • Unusual connection timing

  • Unexpected external destinations

  • A workload communicating outside its normal application relationship

The policy has not necessarily changed.

The behaviour has changed.

This is why security architecture requires both policy enforcement and continuous observation.

4.2 The Security Telemetry Pipeline

A modern environment can generate telemetry from many layers:

Workload

↓

Network flow

↓

Packet / protocol

↓

Identity

↓

Application

↓

Infrastructure

↓

Security platform

↓

Analytics

No single telemetry source provides the complete picture.

4.3 Network Flow Visibility

Flow telemetry such as NetFlow and IPFIX can provide information about communication patterns including:

  • Source

  • Destination

  • Protocol

  • Ports

  • Volume

  • Packet counts

  • Timing

  • Direction

For example:

APP-01 → DB-01

TCP/5432

Normal

versus:

APP-01 → DB-17

TCP/5432

Unexpected

The second event may become a security investigation even if the network technically permits the traffic.

4.4 Packet-Level Visibility

Flow telemetry tells us that communication occurred.

Packet-level analysis can provide additional information about the communication itself.

Depending on the deployment, packet analysis can help identify:

  • Protocol behaviour

  • Application exchanges

  • Suspicious traffic patterns

  • Malformed packets

  • Unexpected protocols

  • Attack indicators

  • Session behaviour

Packet capture is particularly useful during incident investigation.

4.5 Identity-Aware Security

Network addresses are not sufficient security identities.

An IP address can represent one workload today and another tomorrow.

Modern environments therefore associate network activity with additional context.

Useful information can include:

  • User identity

  • Workload identity

  • Device identity

  • Application identity

  • Namespace

  • Kubernetes service

  • VM identity

  • Cloud resource identity

  • Security group

  • Endpoint classification

This allows security teams to move from:

10.10.20.15 connected to 10.10.30.20

towards:

Production application APP-01 attempted to access database service DB-01.

The second statement provides substantially more useful security context.

4.6 Security Analytics

Telemetry becomes more valuable when it is correlated.

Consider:

Event 1

Authentication succeeded.

Event 2

The user accessed a server.

Event 3

The server established a new outbound connection.

Event 4

The workload contacted an unusual destination.

Event 5

Traffic volume increased dramatically.

Each event might be harmless in isolation.

Together they may describe a potential compromise.

Security analytics attempts to identify these relationships.

The objective is to move from:

Thousands of independent events

to:

A smaller number of meaningful security stories.

4.7 Behavioural Baselines

Security systems need to understand normal behaviour.

An application server may normally:

  • Communicate with three application services

  • Use HTTPS

  • Connect to a known database

  • Generate predictable traffic

  • Operate continuously

  • Use known DNS services

This creates a behavioural baseline.

If the same workload suddenly:

  • Scans hundreds of hosts

  • Attempts SSH connections

  • Contacts an unfamiliar external service

  • Generates significantly more traffic

  • Attempts unexpected database access

the behaviour becomes anomalous.

An anomaly does not automatically mean compromise.

It means:

The workload’s behaviour requires investigation.

4.8 Detecting Lateral Movement

Lateral movement occurs when an attacker attempts to move from an initial compromised workload to additional systems.

A simplified attack path is:

Initial compromise

↓

Credential acquisition

↓

Discovery

↓

Service enumeration

↓

Additional connections

↓

Second workload

Segmentation can reduce these paths.

Telemetry can reveal them.

Analytics can correlate them.

Response mechanisms can attempt to contain them.

The resulting model is:

Prevent → Detect → Contain

4.9 East-West Traffic Analytics

Modern applications generate significant east-west traffic.

Examples include:

WEB → APP

APP → DB

APP → CACHE

SERVICE → SERVICE

MONITORING → WORKLOAD

Security analytics can model these relationships.

Normal:

APP-01 → DB-01

Abnormal:

APP-01 → DB-01

APP-01 → DB-02

APP-01 → DB-03

APP-01 → hundreds of hosts

The final pattern could indicate:

  • Scanning

  • Discovery

  • Malware propagation

  • Misconfiguration

  • Legitimate operational activity

Context determines the conclusion.

4.10 Security Graphs

A useful way to understand modern security is as a graph.

Nodes represent:

  • Users

  • Workloads

  • Applications

  • Databases

  • Services

  • Devices

  • Security systems

Edges represent:

  • Network communication

  • Authentication

  • Application dependencies

  • Policy relationships

  • Administrative access

This model can answer questions such as:

Which systems can this compromised workload reach?

or:

Which applications depend on this database?

or:

Which systems would be affected if this workload were quarantined?

Security therefore becomes a relationship-analysis problem rather than simply a log-analysis problem.

4.11 SIEM Integration

A SIEM can aggregate security events from multiple systems.

Potential sources include:

  • Firewalls

  • IDS/IPS

  • Network infrastructure

  • Servers

  • Identity platforms

  • Cloud platforms

  • Kubernetes

  • Endpoint security

  • Applications

The SIEM can provide:

  • Search

  • Correlation

  • Alerting

  • Investigation

  • Historical analysis

  • Reporting

The SIEM does not replace the underlying security controls.

It provides a central analytical layer.

4.12 SOAR and Automated Response

Detection becomes more valuable when it can trigger an appropriate response.

A response workflow might be:

High-risk alert

↓

Verify evidence

↓

Identify workload

↓

Check identity

↓

Review communications

↓

Apply containment

↓

Notify security team

↓

Record incident

Possible actions include:

  • Isolating a workload

  • Restricting communication

  • Disabling an identity

  • Blocking a destination

  • Increasing inspection

  • Opening an incident

  • Collecting forensic evidence

Automation must be carefully controlled.

A false positive that automatically isolates a critical production system can itself create an operational incident.

4.13 Dynamic Segmentation

Security state can change over time.

A workload that is healthy at 09:00 may become suspicious at 09:15.

The security architecture should therefore be capable of changing its posture.

4.14 Risk-Based Enforcement

A useful model is:

RiskExampleResponse
LowNormal behaviourAllow
MediumUnusual destinationMonitor
HighRepeated scanningRestrict
CriticalConfirmed compromise indicatorsQuarantine

This introduces a more flexible model than simply:

Allow / Deny

Security becomes increasingly risk-aware.

4.15 Identity, Device and Workload Context

Risk decisions become more useful when multiple dimensions are considered.

A security system can evaluate:

Identity

Who is requesting access?

Device

Is the device trusted and compliant?

Workload

Which application is generating the traffic?

Network

Where is the communication occurring?

Behaviour

Is the activity normal?

Threat intelligence

Is the destination or behaviour associated with known threats?

This creates contextual security decisions.

4.16 Continuous Verification

Authentication should not be treated as permanent trust.

An entity may initially be trusted and later become risky.

Security can therefore continuously evaluate:

  • Identity

  • Context

  • Policy

  • Behaviour

  • Device posture

  • Risk

This creates a feedback loop rather than a one-time access decision.

4.17 Threat Intelligence

Threat intelligence can add external context to security analysis.

Examples include intelligence relating to:

  • Malware infrastructure

  • Command-and-control systems

  • Phishing

  • Suspicious domains

  • Known malicious addresses

Threat intelligence becomes more valuable when combined with internal evidence.

For example:

Threat intelligence

  •  

DNS activity

  •  

Network flow

  •  

Endpoint telemetry

  •  

Identity context

can create a much stronger security signal.

4.18 Cloud Security Visibility

Cloud environments introduce additional security telemetry.

Security platforms can provide visibility into:

  • Resources

  • Identities

  • Configuration

  • Network exposure

  • Policy violations

  • Threat findings

  • Vulnerabilities

Hybrid environments are particularly challenging because a workload may communicate across:

Data Center

↓

Cloud VPC

↓

Managed service

↓

Internet-facing API

Network telemetry alone may not provide sufficient context.

Cloud security telemetry therefore needs to become part of the broader security architecture.

4.19 Kubernetes and Container Security

Containerised environments introduce additional security dimensions:

  • Namespace

  • Pod

  • Service

  • Service account

  • Network policy

  • Container image

  • Runtime behaviour

  • Cluster identity

A workload may therefore be represented as:

User

↓

Kubernetes workload

↓

Service

↓

Pod

↓

Container

↓

Network destination

Traditional IP-based monitoring alone can lose important application context because containers are often short-lived and addresses can change.

4.20 Runtime Security

Network controls cannot explain everything happening inside a workload.

Runtime security can provide visibility into:

  • Unexpected processes

  • File access

  • Privilege changes

  • Suspicious system calls

  • Unexpected network connections

  • Container escape indicators

  • Abnormal process behaviour

This complements network telemetry.

The resulting evidence becomes:

Network behaviour

  •  

Identity

  •  

Application behaviour

  •  

Runtime behaviour

4.21 Detection Engineering

Security detection should be engineered rather than simply enabled.

A detection might begin with:

Can we detect a production workload scanning a large number of internal hosts?

The engineering process becomes:

Define expected behaviour

↓

Identify telemetry

↓

Create detection logic

↓

Test against normal traffic

↓

Test against simulated abnormal behaviour

↓

Measure false positives

↓

Tune

↓

Deploy

↓

Monitor

This turns security analytics into an engineering discipline.

4.22 Measuring Security Effectiveness

Security should be measurable.

Useful questions include:

Coverage

Can we see the important workloads?

Policy coverage

Are critical workloads protected by appropriate segmentation?

Detection coverage

Can important attack behaviours be detected?

Response time

How quickly can a security event be investigated?

Containment time

How quickly can a compromised workload be isolated?

False positives

How many alerts require no action?

Recovery

How quickly can the affected service return to normal?

4.23 Incident Investigation Workflow

A repeatable investigation process can be:

1. Identify

Which workload, identity, or device generated the event?

2. Establish baseline

What normally happens?

3. Identify deviation

What changed?

4. Determine scope

What else communicated with the affected workload?

5. Determine impact

What systems or data may be affected?

6. Contain

Can the workload be isolated?

7. Investigate

What evidence explains the event?

8. Remediate

Remove the underlying cause.

9. Validate

Confirm that the environment has returned to an expected state.

10. Improve

Update policy, detection, architecture, or operational processes.

4.24 Example: Compromised Application Server

Consider the application architecture developed throughout this guide:

WEB → APP → DB

APP-01 normally communicates with:

  • WEB services

  • DB services

  • Monitoring

  • Approved infrastructure services

Security analytics detects that APP-01 has started scanning internal hosts.

The investigation identifies:

APP-01 → DB-01

Normal

APP-01 → Monitoring

Normal

APP-01 → Hundreds of internal addresses

Abnormal

The security team correlates:

  • Network flow

  • Endpoint telemetry

  • Authentication activity

  • DNS activity

  • Firewall events

The combined evidence increases the risk score.

The response becomes:

APP-01

↓

High-risk state

↓

Restricted policy

↓

Security investigation

If compromise is confirmed:

APP-01

↓

Quarantine

↓

Remediation

The complete lifecycle is now:

Prevent → Observe → Detect → Investigate → Contain → Recover

4.25 Adaptive Security

The final evolution is adaptive security.

Instead of treating policy as permanently static, the architecture can respond to changing conditions.

Normal

Risk = Low

Standard application policy.

Suspicious

Risk = Medium

Additional monitoring and inspection.

High Risk

Risk = High

Restrict communication.

Compromised

Risk = Critical

Quarantine workload.

This does not mean every decision should be automated.

It means the architecture has mechanisms capable of changing security posture when evidence justifies it.

4.26 The Complete Data Center Security Architecture

The four sections can now be combined.

Layer 1 — Security Architecture

Physical, network, compute, storage, application, cloud and identity controls.

↓

Layer 2 — Segmentation and Policy

EPGs, ESGs, contracts, filters and micro-segmentation.

↓

Layer 3 — Enforcement and Inspection

Distributed enforcement, policy-based redirect, service graphs, firewalls, IPS and other L4–L7 services.

↓

Layer 4 — Visibility and Adaptive Defence

Flow telemetry, packet visibility, identity, analytics, SIEM, detection, response and dynamic containment.

The complete architecture becomes:

Workload

↓

Identity / Classification

↓

Segmentation

↓

Policy

↓

Enforcement

↓

Inspection

↓

Telemetry

↓

Analytics

↓

Risk

↓

Response

↓

Policy adjustment

This is the modern data center security feedback loop.

4.27 Engineering Principles

A mature security architecture should:

  • Know the workload

  • Minimise trust

  • Enforce least privilege

  • Inspect according to risk

  • Observe continuously

  • Correlate context

  • Detect behaviour

  • Prepare containment

  • Automate carefully

  • Measure effectiveness

4.28 Final Engineering Perspective

Modern data center security is no longer a single firewall positioned at the network perimeter.

Applications are distributed.

Workloads move.

Users and services are increasingly identity-driven.

Cloud and on-premises infrastructure coexist.

East-west communication can be as important as north-south traffic.

Security must therefore become an architectural capability rather than a single appliance.

The model developed throughout this guide is:

Understand the workload

↓

Define its security relationships

↓

Segment the environment

↓

Enforce least privilege

↓

Inspect higher-risk traffic

↓

Observe actual behaviour

↓

Detect deviations

↓

Respond to changing risk

↓

Continuously improve policy

The objective is not simply to prevent every possible connection.

It is to create an environment where:

Required communication is explicitly permitted, unnecessary communication is restricted, abnormal behaviour is visible, and compromised workloads can be contained before they become a larger incident.

That is the foundation of a modern, policy-driven data center security architecture.

INCIDENT LAB · LATERAL MOVEMENT · RESPONSE
Investigate a Compromised Workload
Follow a realistic east-west security incident from normal application traffic through anomaly detection, risk escalation, policy enforcement and workload quarantine.
East-West Traffic Investigation
Stage 1 of 8
W
WEB-01
Front-End
Expected Role
A
APP-01
Application Tier
Expected Target
D
DB-01
Database Tier
Restricted Target
Incident Scenario
WEB-01 normally communicates with APP-01 over HTTPS. The investigation begins with an expected application flow.
Current Risk Score
18
LOW · Expected workload behaviour
Investigation Evidence
Source WEB-01
Destination APP-01
Protocol HTTPS / 443
Identity Web Role
Behaviour Expected
Incident Timeline
Detection → Response
T+00:00 Normal WEB → APP traffic
T+00:18 New east-west behaviour observed
T+00:24 WEB → DB connection attempted
T+00:27 Identity / behaviour mismatch detected
T+00:31 Risk score crosses investigation threshold
T+00:34 Security policy blocks lateral movement
T+00:38 Incident response initiated
T+00:42 WEB-01 quarantined
Analyst Investigation

Begin with the baseline. WEB-01 has an expected role and is communicating with APP-01 over HTTPS.

Expected Path
WEB → APP
Observed Path
WEB → APP
Policy State
Normal
Response
Monitor
Security posture: NORMAL — no containment required.
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
identity security

Identity Security

Identity Security

ENGINEERING GUIDE · IDENTITY SECURITY

Identity is no longer simply a login mechanism. It is a continuous security signal used to authenticate users and services, determine what they are allowed to access, evaluate risk, enforce least privilege and trigger a security response when behaviour changes.

Modern applications rarely operate inside a single network boundary. Users access cloud services from unmanaged or managed devices, applications communicate through APIs, workloads call other workloads, administrators operate across multiple platforms, and automated services use identities that may never have a human sitting behind them.

This changes the security problem. A network address can describe where a connection originates, but it does not reliably describe who or what is making the request, whether the device is trusted, whether the session is behaving normally, or whether the requested action is appropriate for that identity.

Identity Is Now a Security Control Plane

Traditional access control often begins with a simple question: Can this user log in?

Modern identity security has to go much further. A successful authentication event does not automatically mean that access should be granted. The security decision may depend on the user's role, authentication strength, device posture, application sensitivity, location, session behaviour, privilege level and current risk.

The resulting model is continuous rather than binary. Identity establishes who is making the request, authentication establishes confidence in that identity, context adds surrounding security information, risk evaluation determines how much trust should be granted, and policy decides what the identity is permitted to do.

Traditional Password
Modern Authentication
Context Identity + Device
Decision Risk + Policy

From Authentication to Continuous Trust

Authentication is the starting point, not the final security decision. A user may successfully authenticate and still represent a high-risk request. A stolen session token may appear valid. A privileged account may suddenly access systems it has never used before. A service identity may begin making API calls at an unusual rate. A healthy device may become non-compliant after authentication.

Identity security therefore combines authentication with context, authorization, behavioural signals and continuous monitoring. This creates the foundation for a Zero Trust approach in which access is evaluated according to the request and its associated evidence rather than being permanently trusted because a user is inside a particular network.

Identity Security Engineering Model
WHO → AUTHENTICATE → CONTEXT → RISK → POLICY → ENFORCE → MONITOR → RESPOND

The Identity Security Problem Has Changed

Attackers increasingly target identities because identities provide legitimate access to legitimate systems. Credential theft, password spraying, phishing, MFA fatigue, session hijacking, stolen OAuth tokens, privilege escalation and malicious application integrations can allow an attacker to operate using credentials that appear valid.

This makes identity security fundamentally different from simply protecting passwords. The security architecture must protect the identity itself, the credentials and authenticators used to establish trust, the sessions created after authentication, the privileges assigned to the identity and the applications and workloads that accept that identity.

01 · Authentication
Prove the Identity

Strong authentication establishes confidence that a user, administrator, service or workload is genuinely the identity presented to the system.

02 · Authorization
Limit the Identity

Authorization determines which resources, applications, APIs and actions the identity is permitted to access. Least privilege keeps that permission as narrow as practical.

03 · Governance
Control the Lifecycle

Identity governance manages how identities are created, changed, reviewed, privileged, disabled and ultimately removed from the environment.

04 · Detection
Detect Identity Abuse

Identity telemetry and behavioural analysis help identify suspicious sessions, privilege escalation, token abuse, unusual access patterns and compromised accounts.

What Identity Security Actually Protects

Identity security applies far beyond human users. Modern environments contain administrators, customers, contractors, applications, APIs, virtual machines, containers, service accounts, cloud workload identities and automated processes.

Each identity can become a pathway into sensitive resources. Protecting the identity therefore means controlling authentication, authorization, privilege, session behaviour and the relationships between identities and the resources they are allowed to use.

In a cloud environment, this may involve IAM roles, service accounts, workload identities, OAuth grants and temporary credentials. In a data center, it may involve Active Directory, LDAP, privileged access management and identity-aware network controls. In an application environment, it may involve JWTs, API authentication, service-to-service identity and policy enforcement at the application layer.

Identity as the New Security Perimeter

The traditional security perimeter was largely defined by network boundaries. Firewalls, VLANs, VPNs and security zones determined where users and systems could connect. These controls remain important, but they are no longer sufficient to establish trust.

A modern identity security architecture treats identity as a primary security control while continuing to use network, endpoint, application and cloud controls as additional enforcement layers.

The result is not the removal of the network perimeter. Instead, security decisions become distributed across identity providers, applications, APIs, endpoints, cloud platforms, network controls and security operations systems.

Engineering Question
If a previously trusted administrator suddenly authenticates from an unfamiliar device, requests privileged access and begins accessing systems outside their normal role, should authentication alone still be enough to allow the request?

The Engineering Approach

The remainder of this guide follows the complete identity security lifecycle: establish strong identity, authenticate it, understand its context, evaluate risk, apply authorization and policy, enforce the decision, monitor activity and respond when trust changes.

The objective is to move from static access control toward an adaptive security model in which identity becomes an active source of security intelligence.

Identity Security Foundations

SECTION 01 · FOUNDATIONS

Identity Security Foundations

Start with the identity itself: authentication, strong authentication, MFA, FIDO2, device posture and service identities. The objective is to understand what an identity actually represents before access decisions are made.
01
IDENTITY who exists?
AUTHENTICATE prove identity
MFA increase assurance
DEVICE assess posture
WORKLOAD service identity
SIGNAL generate evidence
Engineering Question
How do we establish enough confidence that an identity is genuine before allowing it to enter the access-control process?
You Will Learn
Authentication is only the starting point. Identity, device, authentication strength and workload identity all become security signals.
EXPLORE IDENTITY TRUST PIPELINE →
SECTION 01 · IDENTITY SECURITY FOUNDATIONS
Identity Security Foundations

Establishing trustworthy identities, strong authentication, device context and workload identity before making an access decision.

Engineering Principle
Authentication establishes confidence in an identity. Identity security determines what happens with that identity after authentication.

What Identity Security Actually Protects

Identity security begins with establishing confidence in the identities that interact with systems, applications and data. That identity may belong to a human user, administrator, customer, application, API, virtual machine, container or automated service.

The first engineering mistake is to treat authentication as the complete identity security problem. Authentication answers an important question — who or what is making the request? — but it does not determine whether that identity should be trusted with a particular resource or action.

A modern identity architecture therefore combines strong authentication with authorization, device context, behavioural signals, privilege management and continuous monitoring.

01 · HUMAN
User Identity
Employees, administrators, customers and contractors accessing applications and services.
02 · PRIVILEGED
Administrative Identity
Identities with elevated permissions that can modify systems, policy or sensitive data.
03 · APPLICATION
Application Identity
Software components authenticating to APIs, databases and other application services.
04 · SERVICE
Service Identity
Automated processes and background services operating without direct human interaction.
05 · WORKLOAD
Workload Identity
Virtual machines, containers and cloud workloads requiring controlled service-to-service access.
06 · MACHINE
Machine Identity
Devices and infrastructure systems participating in secure application and network operations.

Authentication Is Only the Beginning

Traditional security architectures often treated successful authentication as the point at which trust was established. A user entered a password, completed authentication and was then allowed to operate within a trusted environment.

Modern environments make that model increasingly difficult to defend. A valid identity may be compromised. A session token may have been stolen. A previously trusted device may become non-compliant. A privileged account may suddenly access an unfamiliar application. A service identity may begin making API requests at an abnormal rate.

The authentication event may still be technically valid while the activity itself is suspicious.

Security Shift

The question is no longer simply “Did this identity authenticate?” It becomes “Does this identity still represent an acceptable level of trust for this request?”

Strong Authentication

Strong authentication reduces the probability that an attacker can successfully impersonate an identity.

Passwords remain widely used, but passwords alone provide limited protection against phishing, credential theft, password reuse, password spraying and brute-force attacks.

Modern authentication architectures increasingly combine multiple forms of evidence, including knowledge factors, possession factors, biometric factors, cryptographic authenticators and contextual information about the device and request.

The objective is not simply to make login more complicated. The objective is to increase confidence that the identity presented to the system is genuinely controlled by the legitimate user or service.

Multi-Factor Authentication

Multi-factor authentication adds additional evidence to the authentication process. A password combined with a second factor is significantly stronger than a password alone, but MFA should not be treated as an automatic guarantee of trust.

Attackers increasingly use phishing, adversary-in-the-middle techniques, stolen session tokens and MFA fatigue attacks to manipulate or bypass authentication controls.

This means the security architecture must consider both authentication strength and the circumstances surrounding the authentication.

Authentication
Establish Identity Confidence

Use strong authentication mechanisms to establish confidence that the identity presented to the system is legitimate.

Context
Understand the Request

Consider device posture, application sensitivity, location, session characteristics and other relevant context.

Authorization
Limit What Identity Can Do

Apply least privilege so successful authentication does not automatically result in broad access.

Monitoring
Detect Changes in Trust

Monitor identity activity so unusual behaviour can trigger additional verification or security response.

FIDO2 and WebAuthn

FIDO2 provides a modern foundation for phishing-resistant authentication using public-key cryptography.

WebAuthn allows web applications to use authenticators such as platform credentials, security keys and passkeys. Instead of sending a reusable password to the application, the authentication process uses cryptographic credentials associated with the legitimate authenticator.

This changes the attack surface. A stolen password can potentially be replayed against another system, while properly implemented phishing-resistant authentication is designed to bind the authentication process to the legitimate origin and cryptographic credential.

Device Identity and Posture

Identity cannot always be evaluated independently from the device being used.

A valid administrator accessing a sensitive management application from a managed and healthy corporate device presents a different risk profile from the same identity accessing the application from an unknown or non-compliant device.

Device posture can include operating system version, security patch level, endpoint protection status, device management state, encryption status, secure boot state, browser characteristics and compliance status.

These signals can become part of the access decision. For example, a privileged administrator may be permitted to access a management application only when using a managed device with current security controls.

Service and Workload Identity

Modern applications introduce another major identity challenge: not every request originates from a human.

Applications communicate with APIs. Containers communicate with services. Cloud workloads access databases and storage. Automation systems perform administrative operations. CI/CD pipelines deploy infrastructure.

These processes require identities of their own.

Long-lived static credentials create significant risk because they can be copied, leaked or accidentally exposed. Modern architectures increasingly use short-lived credentials, service accounts and workload identity mechanisms to reduce that exposure.

Workload Identity Questions

For every important service identity, engineers should be able to answer: Who is the workload? What may it access? How long should that permission exist? Where should the identity be accepted? and what should happen if its behaviour changes?

Identity Telemetry

Identity security depends on visibility. Authentication events, MFA challenges, device posture, privilege changes, OAuth grants, API calls, session activity and administrative actions can all provide useful security signals.

These signals become significantly more valuable when correlated with endpoint, network, application and cloud telemetry.

A single failed login may not indicate a serious threat. A sequence of failed logins followed by a successful authentication, a new device registration, privilege escalation and access to sensitive systems creates a very different security picture.

Identity Security as a Foundation for Zero Trust

Zero Trust does not mean that every user is permanently blocked or that traditional network security becomes irrelevant.

It means that trust should not be granted simply because an identity, device or workload happens to exist inside a particular network boundary.

Identity becomes one of the primary signals used to establish trust, while device, application, network and workload controls provide additional enforcement layers.

A Zero Trust identity architecture therefore asks: who is requesting access, how strongly has that identity been authenticated, what device or workload is making the request, what resource is being accessed, what is the current risk and what permissions are actually required?

Engineering Question
A privileged administrator successfully authenticates, but the request comes from an unfamiliar device and is followed by unusual access to sensitive systems. Should authentication alone still be enough to allow the request?

Section 1 Summary

Identity security starts with strong authentication but cannot end there. Human users, administrators, applications, services and workloads all require controlled identities. Device posture and contextual signals can strengthen access decisions, while identity telemetry provides the evidence required to detect changes in trust.

The next engineering step is to determine what an authenticated identity is actually allowed to do. That moves the architecture from authentication into authorization, context, least privilege and adaptive access policy.

IDENTITY TRUST LAB · ADAPTIVE DECISION ENGINE

From Identity Signal to Access Decision

Change identity, authentication, device, context and behaviour signals and watch the policy engine recalculate the access decision in real time.

READY
LAB MODE
Identity
Authentication
Device
Context
Application
Behaviour Risk
Trust Evaluation Pipeline
LAB POLICY MODEL
01
ID
Identity
User
02
AU
Authenticate
MFA Verified
03
DV
Device
Managed
04
CX
Context
Expected
05
RK
Risk
Low
06
PL
Policy
Evaluating
07
→
Decision
Pending
Decision Engine
REAL-TIME
ALLOW
Trust Score 100 / 100
Policy Explanation
Identity is authenticated with strong MFA, the device is healthy, context is expected and current behaviour risk is low.
Identity Standard User
Application Standard
Context Expected
Risk Low
Evaluation Timeline
0 / 7 STAGES
01
Identity asserted
Determine which identity is requesting access.
WAIT
02
Authentication evaluated
Verify the strength and validity of authentication.
WAIT
03
Device posture checked
Evaluate whether the endpoint can be trusted.
WAIT
04
Context assessed
Location and environmental context are evaluated.
WAIT
05
Behaviour risk calculated
Current behaviour is compared against the policy model.
WAIT
06
Policy evaluated
Signals are combined to determine the required access level.
WAIT
07
Access decision returned
The policy engine produces an enforceable result.
WAIT
Engineering Telemetry
WHY IT MATTERS
Engineering Takeaway

Authentication is only the beginning.

A successful login does not automatically create trust. Identity, device, context and behaviour must continue to influence the decision.

LAB POLICY: Strong authentication + healthy device + expected context + low risk normally produces ALLOW.

Authorization, Context and Zero Trust

SECTION 02 · AUTHORIZATION, CONTEXT & ZERO TRUST

Authorization, Context and Zero Trust

Move beyond authentication by evaluating identity, context and risk before deciding what access should actually be permitted.

02
01 IDENTITY
02 AUTHENTICATE
03 CONTEXT
04 RISK
05 POLICY
06 DECISION
Engineering Question

When a valid identity becomes risky, should access remain allowed?

You Will Learn

How RBAC, ABAC, least privilege, conditional access, risk signals and just-in-time privilege turn identity into a Zero Trust decision.

SECTION 02 · AUTHORIZATION, CONTEXT & ZERO TRUST
Authorization, Context and Zero Trust

Turning an authenticated identity into a controlled, context-aware and continuously evaluated access decision.

Engineering Principle
Authentication establishes who the identity is. Authorization determines what that identity is allowed to do, while context and risk determine whether that permission should be granted under the current conditions.

Authentication vs Authorization

Authentication and authorization are related but fundamentally different security functions.

Authentication establishes confidence in an identity. Authorization determines which resources and actions that identity is permitted to access.

A successfully authenticated administrator might be permitted to manage a particular application but not access a production database directly. A developer may be permitted to read source code but not modify production infrastructure. A service identity may be permitted to call one API but not another.

This separation is essential because a valid identity should not automatically receive unrestricted access.

01
IDENTITY
02
AUTHENTICATE
03
CONTEXT
04
RISK
05
POLICY
06
DECISION

Least Privilege

Least privilege is one of the central principles of identity security. An identity should receive only the permissions required to perform its legitimate function.

The objective is not to create an environment where every request requires manual approval. Instead, access should be deliberately scoped so that a compromised identity has as little unnecessary capability as possible.

Least privilege applies to human users, administrators, applications, service accounts and workloads.

RBAC
Role-Based Access Control

Permissions are associated with defined roles and identities receive those roles according to their responsibilities. RBAC provides a practical way to standardise access across groups of users and services.

ABAC
Attribute-Based Access Control

Access decisions can use attributes associated with the identity, resource, device, request or environment. This allows policies to respond to more detailed context than role alone.

JIT
Just-in-Time Privilege

Elevated permissions can be granted for a limited period or specific task instead of remaining permanently assigned to the identity.

CONTEXT
Context-Aware Access

Access can consider device posture, application sensitivity, authentication strength, location, session behaviour and current risk.

Role-Based and Attribute-Based Access

RBAC provides a useful foundation because permissions can be associated with defined responsibilities rather than individual users.

However, roles alone may not provide enough context for modern access decisions.

ABAC extends the decision model by considering attributes such as user role, device state, resource classification, request type, application sensitivity and environmental conditions.

In practice, many mature architectures use a combination of role-based permissions and contextual policy rather than relying exclusively on one model.

Conditional Access

Conditional access introduces context into the authorization decision.

Instead of defining a single permanent rule such as “this user can access this application,” the policy can evaluate the circumstances surrounding each request.

Relevant signals may include authentication strength, device compliance, operating system, application sensitivity, user risk, session characteristics and other security context available to the policy engine.

A low-risk request from a trusted device may proceed normally, while the same identity from a high-risk context may require additional verification or be restricted.

Risk-Based Authentication

Risk-based authentication evaluates evidence surrounding an authentication or access request and adjusts the required security response accordingly.

Risk signals can include unusual login behaviour, unfamiliar devices, impossible or unexpected travel patterns, abnormal authentication frequency, suspicious session characteristics or other indicators of potential compromise.

The important engineering principle is that risk does not have to produce only two outcomes: allow or deny.

ALLOW
Normal context and acceptable risk.
STEP-UP
Require stronger or additional verification.
RESTRICT
Limit sensitive actions or resources.
DENY
Block access when risk exceeds policy.

Step-Up Authentication

Step-up authentication provides a middle ground between unrestricted access and complete denial.

A user may successfully authenticate to a normal application but require stronger verification before accessing a highly sensitive system or performing a privileged operation.

This allows security controls to increase authentication assurance when the sensitivity of the action or the risk of the request changes.

Example

A developer signs in normally and accesses development resources. When the same identity attempts to access production infrastructure, policy can require stronger authentication, verify device posture and apply additional authorization controls before allowing the privileged action.

Just-in-Time Privilege

Permanent administrative privileges increase the impact of compromised identities.

Just-in-time privilege reduces that exposure by providing elevated permissions only when they are required and for as long as they are required.

A typical workflow may involve a user requesting temporary elevation, satisfying an authentication or approval requirement, receiving the required privilege for a defined period and then automatically losing that elevated access when the period ends.

This creates a smaller standing privilege footprint and provides better auditability around sensitive operations.

Continuous Trust Evaluation

Zero Trust requires more than a strong initial authentication event. The security decision should be capable of changing when the evidence changes.

A device can become non-compliant. A user can begin behaving abnormally. A session can access resources outside its normal pattern. A previously safe workload can become compromised.

Continuous evaluation allows those changes to influence subsequent access decisions.

This does not necessarily mean re-authenticating every user for every request. Instead, security systems can use available telemetry and policy signals to determine when additional verification, restriction or denial is appropriate.

Identity as the New Security Perimeter

The traditional network perimeter assumed that location provided useful evidence of trust. A user inside the corporate network was often treated differently from a user outside it.

Cloud services, remote work, SaaS platforms, APIs and distributed applications have weakened that assumption.

Identity therefore becomes a primary security boundary, but it should not be viewed in isolation. Network segmentation, endpoint security, application controls, encryption and cloud security mechanisms continue to provide important enforcement layers.

Zero Trust Principle

Network location can provide context, but it should not be treated as sufficient proof of trust. The security decision should be based on identity, authentication strength, context, resource sensitivity and current risk.

Policy Must Become Enforceable

An identity policy has little value if it exists only as a written rule. The decision must eventually reach an enforcement point.

Depending on the architecture, enforcement may occur at an identity provider, application, API gateway, proxy, cloud platform, network control, endpoint or privileged access system.

This creates an important architectural separation: the system evaluating identity and risk does not necessarily have to be the same system enforcing the final decision.

A policy engine may determine that a request should be restricted, while an application, API gateway or network control performs the actual enforcement.

Engineering Question
If a valid administrator identity requests access to a sensitive production API from a non-compliant device, should the policy engine allow the request simply because authentication succeeded?

Section 2 Summary

Authorization transforms identity into controlled permission. RBAC, ABAC and least privilege establish the baseline, while conditional access, risk-based authentication, step-up authentication and just-in-time privilege add context and adaptability.

Zero Trust extends this model by treating trust as something that must be continually evaluated rather than permanently granted. The next engineering challenge is to apply those identity decisions across real applications, APIs, cloud platforms and infrastructure.

SECTION 02 · ADAPTIVE ACCESS DECISION LAB

Investigate an Identity Access Decision

Inject identity and security events, inspect the evidence they create, then determine whether the correct response is to allow, step-up, restrict or deny access.

MONITORING
SCENARIO RUN
Normal employee access
A standard user is accessing a normal business application from an expected location using a managed device.
EVENT 01 / 06
Identity Event Injection
SELECT AN EVENT
Policy Decision
CAUSE → EVIDENCE → ACTION
ALLOW
Current identity state is within the normal policy boundary.
Why did the policy engine decide this?
Authentication is valid and the current identity, device and context signals are consistent with normal access.
Choose the security response
Evidence Signals
CURRENT IDENTITY CONTEXT
Identity
Standard User
VALID
Auth
MFA Verified
STRONG
Device
Managed / Healthy
TRUSTED
Context
Expected Location
NORMAL
Behaviour
Normal Activity
LOW RISK
Privilege
Standard Access
NORMAL
Investigation Console
1 EVENT
00:01
Identity session established from expected context.
INFO
Engineering Telemetry
DECISION GUIDANCE
Investigation Result

Normal access should remain low-friction.

Adaptive access should not challenge every request. The objective is to increase control when evidence indicates that trust has changed.

92
Illustrative
trust index

Identity Threat Detection & Response

SECTION 03 · IDENTITY ENFORCEMENT

Identity Enforcement Across Applications & Cloud

Turn identity and risk decisions into enforceable controls across applications, APIs, cloud platforms and infrastructure.

03
01 IDENTITY
02 TOKEN
03 POLICY
04 ENFORCE
05 APPLICATION
06 AUDIT
Engineering Question

Where does the identity decision actually become an enforceable security control?

You Will Learn

How tokens, APIs, identity-aware proxies, cloud IAM, service perimeters and network controls turn identity decisions into enforcement.

SECTION 03 · IDENTITY ENFORCEMENT
Identity Enforcement Across Applications & Cloud

Turning identity and risk decisions into enforceable controls across applications, APIs, cloud platforms and infrastructure.

Engineering Principle
An identity decision has little security value until it reaches an enforcement point capable of allowing, restricting or denying the requested action.

From Identity Decision to Enforcement

Section 2 established how identity, context and risk can be used to make an authorization decision. Section 3 moves that decision into the systems that actually control access.

Modern identity enforcement is distributed. An identity provider may authenticate the user, a policy engine may evaluate risk, an API gateway may enforce authorization, an application may enforce business permissions and a cloud platform may control access to infrastructure resources.

These components do not have to be implemented by the same product. The engineering objective is to make sure that the identity context and security decision can travel reliably to the point where access is actually enforced.

01
IDENTITY
02
AUTHENTICATE
03
TOKEN / CONTEXT
04
POLICY
05
ENFORCE
06
AUDIT

Identity-Aware Applications

Applications increasingly participate directly in identity enforcement. Instead of relying entirely on network location, applications can receive identity information and use it when making authorization decisions.

A web application may authenticate through an external identity provider and then receive a signed identity token containing claims associated with the authenticated identity.

The application can then evaluate those claims against its own authorization policy.

This creates an important separation between authentication and application authorization. The identity provider can establish who the user is, while the application determines what that user can actually do within the application.

JWT and API Authentication

JSON Web Tokens are commonly used to carry signed claims between identity systems, applications and APIs.

A typical API request may contain an access token in an Authorization header. The receiving service validates the token according to its configured trust model, including signature, issuer, audience and expiration requirements where applicable.

Successful token validation establishes that the request contains an acceptable credential. It does not automatically mean that the identity has permission to perform every operation exposed by the API.

401
Authentication is missing or cannot be accepted.
403
Identity is known but is not authorized for the action.
ALLOW
Authentication and authorization requirements are satisfied.
STEP-UP
Additional verification or security context is required.

Identity-Based Application Authorization

Application authorization should be designed around the actions that an identity needs to perform rather than simply around the existence of the identity.

For example, a user may be permitted to view an account but not modify it. An administrator may be permitted to restart a service but not retrieve stored secrets. A service identity may be permitted to read a database record but not execute administrative operations.

This provides a second layer of control after authentication and prevents a valid identity from becoming a universal application credential.

Identity-Aware Proxy

An identity-aware proxy can place authentication and contextual access controls in front of applications without requiring every application to independently implement the complete authentication experience.

Google Cloud Identity-Aware Proxy is an example of this model. It can use authenticated identity and contextual information to control access to supported applications and services.

This can be particularly useful when applications are exposed across cloud or hybrid environments and network location alone is not a sufficient access boundary.

Important Distinction

An identity-aware proxy does not eliminate application authorization. The proxy can control whether a request reaches the application, while the application still needs to enforce permissions for actions and resources inside the application.

Google Cloud IAM

Google Cloud IAM provides authorization controls for Google Cloud resources through identities, roles and permissions.

IAM supports predefined roles as well as custom roles, allowing organizations to align permissions with operational responsibilities.

The engineering challenge is to avoid treating IAM roles as a substitute for every other security control. IAM governs access to supported cloud resources, while applications, APIs, endpoints and network controls may require their own authorization and enforcement mechanisms.

Audit logging is also important because an authorization model needs evidence showing which identities performed sensitive operations and when those operations occurred.

VPC Service Controls

VPC Service Controls provide a different security function from Google Cloud IAM.

Service perimeters can help reduce the risk of data exfiltration from supported Google Cloud services by establishing boundaries around protected resources and controlling access paths across those boundaries.

This is particularly relevant when valid credentials have been compromised. IAM may determine that an identity has permission to perform an operation, while a service perimeter can provide an additional boundary around where protected service data may be accessed.

VPC Service Controls should therefore be understood as a complementary control rather than a replacement for IAM, application authorization or network firewalling.

Vault and Secrets-Based Identity

Secrets management becomes another part of identity security when applications and infrastructure require credentials to access protected services.

HashiCorp Vault provides authentication methods, policy-based authorization and secret-management capabilities that can be used to control how applications and users obtain access to sensitive credentials.

A strong design avoids embedding long-lived secrets directly into application source code or configuration wherever practical. Instead, applications authenticate to the secrets platform and receive only the credentials or secrets required for their permitted operation.

Cisco ISE and Identity-Based Network Enforcement

Identity security can also influence network access decisions. Cisco Identity Services Engine provides identity-based access control capabilities that can incorporate authentication, authorization, device profiling and other contextual information.

This allows network access policy to be associated with identity and device context rather than relying solely on an IP address or switch port.

For example, a corporate device belonging to an authorized user may receive a different access policy from an unknown device even when both devices connect through the same physical network.

Identity-Driven Traffic Decisions

Identity-aware security can extend beyond simple allow or deny decisions.

An identity can influence which application endpoint receives a request, which API functions are exposed, which network segment is accessible or which security controls are applied.

A useful example is an application that receives a validated identity containing a role claim. The application can route an administrator to privileged functionality while routing a standard user to a restricted service.

The important distinction is that the decision is based on authenticated identity and authorization context rather than simply on source IP address, VLAN or physical network location.

APPLICATION
Application Policy

Controls actions, resources and business functions available to an authenticated identity.

API
API Authorization

Validates credentials and applies permissions to individual APIs, operations and protected resources.

CLOUD
Cloud Authorization

Controls access to cloud resources through identity, roles, permissions and additional security boundaries.

NETWORK
Network Enforcement

Applies identity and device context to network access where supported by the architecture and enforcement platform.

Authentication, Authorization and Enforcement Are Different Layers

One of the most important engineering principles is to avoid treating authentication, authorization and enforcement as the same function.

Authentication answers: Who are you?

Authorization answers: What are you allowed to do?

Enforcement answers: Where and how is that decision applied?

A mature architecture can therefore use an identity provider for authentication, a policy engine for authorization decisions and multiple enforcement points across applications, APIs, cloud platforms and network infrastructure.

Engineering Question
A user presents a valid identity token to an API. The token is authentic, but the user does not have permission to perform the requested administrative operation. Where should that decision be enforced, and what should the API return?

Section 3 Summary

Identity security becomes operational when identity and policy decisions reach real enforcement points. Applications can enforce permissions, APIs can validate identity tokens, cloud IAM can control resource access, service perimeters can provide additional data protection boundaries, secrets platforms can control access to credentials and network platforms can incorporate identity and device context into access policy.

The architecture is therefore distributed. No single identity system has to perform every security function. The important requirement is that authentication, authorization, context and enforcement remain aligned.

The final section moves from enforcement to the question that becomes critical when prevention fails: How do we detect that an identity has been compromised, investigate what it has done and respond before the compromise spreads?

SECTION 03 · IDENTITY ENFORCEMENT LAB

Identity-Aware Application Lab

Follow an authenticated identity from the identity provider through token validation, policy evaluation and application enforcement. The objective is to understand exactly where authentication ends and authorization begins.
READY · AWAITING REQUEST
Current Request
Valid User Token
A normal authenticated user requests a protected API resource.
Engineering Principle
Identity decisions must reach an enforcement point.
Authentication proves identity. Authorization determines permission. The application or policy enforcement point must enforce the result.
Identity Enforcement Path
STAGE 01 / 06
C
CLIENT
request
→
ID
IDENTITY
PROVIDER
identity
→
TK
TOKEN
claims
→
P
POLICY
ENGINE
decision
→
API
API
enforcement
→
DB
BACKEND
resource
Live Request Context
Identity
alex.user
Application
payments-api
Resource
/v1/payments
Method
GET
Policy Decision
LIVE
Current Result
ALLOW
Identity authenticated and required role is present.
HTTP 200 · ALLOWED
Token Claims
INSPECT
SUB
alex.user
ROLE
payments-reader
ISS
identity.example
STATE
VALID
Evidence
SIGNALS
Identity
VERIFIED
Signature
VALID
Role
PRESENT
Risk
NORMAL
Request Scenarios
SELECT A CASE
Enforcement Event Console
LIVE TRACE
Engineering Telemetry
RUNTIME
Stage
01 / 06
AuthN
VERIFIED
AuthZ
ALLOW
Enforcement
API
Response
200

Identity Threat Detection & Response

SECTION 04 · IDENTITY THREAT DETECTION & RESPONSE

Identity Threat Detection & Response

Detect compromised identities, correlate behavioural evidence and respond before stolen access becomes privilege escalation, lateral movement or persistent compromise.

04
01 OBSERVE
02 CORRELATE
03 INVESTIGATE
04 CONTAIN
05 REVOKE
06 RECOVER
Engineering Question

What evidence is strong enough to treat an identity as compromised?

You Will Learn

How identity telemetry, behavioural analysis, token activity and lateral-movement evidence drive investigation and response.

SECTION 04 · IDENTITY THREAT DETECTION & RESPONSE
Identity Threat Detection & Response

Detecting compromised identities, correlating behaviour and responding before stolen access becomes lateral movement, privilege escalation or persistent compromise.

Engineering Principle
Identity security cannot depend entirely on prevention. Assume that credentials, sessions or tokens can eventually be compromised, then design the architecture to detect abnormal identity behaviour and respond quickly.

Identity Security Does Not End at Authentication

Strong authentication reduces the probability of unauthorized access, but it cannot guarantee that an identity will never be compromised.

Credentials can be stolen. Sessions can be hijacked. Access tokens can be exposed. Users can approve malicious requests. Privileged identities can be abused by legitimate users or attackers operating through compromised systems.

This changes the engineering objective. Identity security must detect not only failed authentication but also suspicious behaviour occurring after authentication succeeds.

01
OBSERVE
02
CORRELATE
03
ASSESS RISK
04
INVESTIGATE
05
CONTAIN
06
REVOKE
07
RECOVER
08
VERIFY

Identity Threats

Modern identity attacks extend far beyond password guessing. Attackers increasingly target the authentication process, tokens, sessions, authorization relationships and trusted integrations.

CREDENTIAL
Credential Theft

Stolen usernames, passwords or credentials can allow attackers to authenticate as legitimate users.

AUTHENTICATION
MFA Fatigue

Repeated authentication prompts can be abused to pressure a user into approving an unexpected request.

TOKEN
Token Theft

A stolen access token or session credential can potentially allow access without repeating the original login process.

PRIVILEGE
Privilege Escalation

Attackers may attempt to obtain additional permissions after compromising an initial identity.

OAUTH
Malicious Integrations

Excessive or malicious application permissions can create an alternative route into protected data and services.

SESSION
Session Abuse

A compromised session may behave differently from the normal activity associated with the legitimate identity.

Identity Behaviour Analytics

Detecting identity compromise requires more than counting failed logins. Security teams need to understand what identities normally do and identify meaningful deviations from that behaviour.

Useful signals can include authentication patterns, device changes, resource access, privileged operations, application usage, token activity, API calls and unusual geographic or environmental context.

A single unusual event may not indicate compromise. Several related signals occurring together can provide much stronger evidence.

Identity Telemetry

Identity security therefore depends on collecting telemetry from multiple layers of the environment.

AUTHENTICATION
Login and MFA Events

Successful and failed authentication, MFA challenges, authentication method and session establishment.

DEVICE
Device and Posture

Device identity, compliance state, operating system and other available endpoint security context.

APPLICATION
Application Activity

Resource access, administrative actions, sensitive operations and application-level authorization events.

API
API and Token Activity

API calls, token use, authorization failures and unusual access patterns across protected services.

CLOUD
Cloud Audit Events

Administrative changes, resource access and identity activity recorded by cloud platforms.

NETWORK
Network Context

Connection patterns, destination changes and network activity that can provide additional evidence during investigation.

Detecting a Compromised Identity

Consider an administrator identity that normally authenticates during business hours from a managed workstation and accesses a small set of infrastructure systems.

The identity suddenly authenticates from an unfamiliar device, generates repeated MFA activity, accesses a new cloud application, attempts a privileged operation and then begins accessing systems that are outside its normal administrative scope.

No single event necessarily proves compromise. Together, however, the signals form a much stronger risk pattern.

Investigation Principle

Security analytics should correlate identity, device, application, cloud and network evidence rather than treating every security event as an isolated alert.

Identity-Based Lateral Movement

Once an attacker obtains a valid identity, the next objective may be to use legitimate access to reach additional systems.

This is why identity security and network segmentation should work together. Identity policy can restrict what the user or service is authorized to access, while network and workload controls can reduce the available paths between systems.

A compromised developer identity should not automatically provide unrestricted access to production systems. Likewise, a compromised service identity should not automatically be able to communicate with every workload in the environment.

Privileged Identity Monitoring

Privileged identities require particular attention because the consequences of compromise can be significantly greater.

Monitoring should focus on privileged authentication, elevation events, administrative changes, sensitive resource access and unusual behaviour associated with administrative sessions.

Just-in-time access, strong authentication, session monitoring and detailed audit trails can reduce both the likelihood and impact of privileged identity abuse.

Identity Threat Detection and Response

Identity Threat Detection and Response, often abbreviated as ITDR, describes the security practices and technologies used to identify and respond to threats involving identities and identity systems.

ITDR should not be treated as a replacement for SIEM, SOAR, EDR or network security. Instead, it complements those capabilities by providing identity-specific evidence and response actions.

A mature architecture can correlate identity events with endpoint, application, cloud and network telemetry to build a broader view of an incident.

SIEM, SOAR and XDR Integration

Identity telemetry can feed security operations platforms where it can be correlated with other security events.

A SIEM can centralize and correlate security logs. SOAR can orchestrate defined response workflows. XDR platforms can combine signals from multiple security domains.

The important architectural principle is correlation. An unusual identity event becomes more valuable when it can be associated with a suspicious endpoint event, an abnormal API request or unexpected access to a sensitive resource.

Responding to Identity Compromise

Response should be proportional to the evidence and the potential impact of the activity.

MONITOR
Continue observation when evidence is weak or ambiguous.
RE-AUTHENTICATE
Require stronger identity verification.
REVOKE TOKEN
Invalidate exposed or suspicious session credentials.
DISABLE IDENTITY
Prevent further authentication when compromise is sufficiently established.
ISOLATE
Restrict affected endpoints or workloads to contain impact.

Automated Response

Some identity responses can be automated when the evidence and response conditions are well understood.

Examples include revoking a session, requiring re-authentication, removing temporary privilege, disabling an account or triggering endpoint isolation.

Automation should be carefully designed because an incorrect security decision can disrupt legitimate users or critical services.

High-impact actions should therefore have clear conditions, appropriate confidence thresholds, auditability and recovery procedures.

Recovering a Compromised Identity

Containment is not the end of an identity incident. Recovery must establish confidence that the attacker no longer has usable access.

Recovery may include credential reset, token and session revocation, removal of unauthorized applications or permissions, review of privileged access, endpoint remediation and investigation of resources accessed during the compromise.

The organization should also determine how the compromise occurred and whether the same weakness exists elsewhere.

Identity Security and Resilience

Identity security should ultimately be part of the organization's resilience strategy.

Critical identities, authentication systems, privileged access paths and recovery mechanisms must remain available during an incident.

Backup authentication mechanisms, emergency access procedures, recovery accounts and documented incident workflows should therefore be tested rather than simply documented.

Putting the Identity Security Model Together

The four sections of this guide form a continuous engineering model.

First, the organization establishes trustworthy identities and strong authentication. Next, authorization and context determine what those identities should be allowed to access. Enforcement points apply those decisions across applications, APIs, cloud and infrastructure.

Finally, telemetry and behavioural analysis determine whether the identity continues to behave consistently with the expected security model.

Identity Security Engineering Model
IDENTIFY → AUTHENTICATE → CONTEXTUALISE → ASSESS RISK → AUTHORISE → ENFORCE → MONITOR → RESPOND
Final Engineering Question
If an identity was trusted yesterday but its behaviour changes today, should the security system continue trusting the identity simply because the original authentication was valid?

Section 4 Summary

Identity security must assume that prevention can eventually fail. Compromised credentials, tokens and sessions require continuous monitoring, behavioural analysis and coordinated response.

The strongest architecture connects identity telemetry with endpoint, application, cloud and network evidence. This allows security teams to detect abnormal behaviour, investigate the identity's activity, contain the compromise and restore trust.

The result is a security model in which identity is not simply a login mechanism. It becomes a continuously evaluated control signal that influences access, enforcement, detection and response.

SECTION 04 · IDENTITY INCIDENT LAB

Compromised Identity Investigation

Investigate a suspicious identity by correlating authentication, device, privilege, token, application and lateral-movement evidence. Build the incident picture before selecting the containment response.
INVESTIGATION OPEN · EVIDENCE COLLECTION
Incident
Suspicious administrative identity
Identity admin.ops normally operates from a known corporate environment. A sequence of unusual authentication, privilege and application events has been detected.
Current Risk
ELEVATED
2 correlated indicators
Investigation Timeline
01 / 06
01
Unusual Login
Administrative identity authenticates from an unfamiliar location and device.
PENDING
02
MFA Anomaly
Multiple authentication challenges are generated in a short period.
PENDING
03
Privilege Escalation
The identity requests or receives access beyond its normal operating pattern.
PENDING
04
OAuth / Token Activity
An unfamiliar application or token begins using the identity.
PENDING
05
Unexpected Application Access
The identity reaches applications outside its normal behavioural profile.
PENDING
06
Lateral Movement
Identity activity begins touching additional systems or privileged resources.
PENDING
Evidence Inspector
SELECTED EVENT
Identity
admin.ops
Source
unfamiliar-device
Signal
anomalous authentication
Severity
HIGH
Correlation
identity + device
Investigation Score
LAB SIGNAL
Compromise Confidence
58
Illustrative investigation score — not a production risk formula
Identity Investigation Console
CORRELATED EVENTS
Select Response
CONTAINMENT DECISION
INVESTIGATION COMPLETE
Response validated.
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
data center firewall

Cisco Secure Firewall with SASE Cloud

Cisco Secure Firewall with SASE Cloud

In today's digital era, network security is of paramount importance. With the rise of cloud-based services and remote work, businesses require a comprehensive security solution that not only protects their network but also ensures scalability and flexibility. Cisco Secure Firewall with SASE (Secure Access Service Edge) Cloud is a cutting-edge solution that combines the robustness of firewall protection with the agility of cloud-based security services. In this blog post, we will delve into the features and benefits of Cisco Secure Firewall with SASE Cloud.

Cisco Secure Firewall is an advanced network security solution designed to safeguard organizations from cyber threats. Built on industry-leading technology, it provides next-generation firewall capabilities, intrusion prevention, and application control. With granular security policies, deep visibility, and advanced threat intelligence, Cisco Secure Firewall empowers businesses to protect their networks from internal and external threats effectively.

SASE (Secure Access Service Edge) is a transformative approach to network security and connectivity. By converging networking and security functions into a unified cloud-based service, SASE offers organizations scalable and flexible security solutions. Cisco Secure Firewall with SASE Cloud takes advantage of this architecture, providing businesses with integrated security services that are delivered from the cloud. This enables seamless scalability, simplified management, and enhanced protection against evolving threats.

Cloud-Native Firewall: Cisco Secure Firewall with SASE Cloud leverages the power of cloud-native architecture, enabling organizations to easily scale their security infrastructure based on demand. It ensures consistent security policies across various locations and eliminates the need for hardware-based firewalls.

Advanced Threat Protection: With integrated threat intelligence and advanced analytics, Cisco Secure Firewall with SASE Cloud offers robust protection against sophisticated threats. It provides real-time threat detection and prevention, ensuring that businesses stay one step ahead of cybercriminals.

Simplified Management: The centralized management console allows organizations to effortlessly manage their security policies and configurations. From a single interface, administrators can efficiently deploy and enforce security policies, reducing complexity and enhancing operational efficiency.

As organizations continue to embrace digital transformation, the network landscape is constantly evolving. Cisco Secure Firewall with SASE Cloud future-proofs your network by providing a scalable and adaptable security solution. Its cloud-native architecture and integration with SASE enable businesses to stay agile and easily adapt to changing security requirements, ensuring long-term protection and resilience.

Highlights: Cisco Secure Firewall with SASE Cloud

Understanding the Cisco Secure Firewall

Cisco Secure Firewall is a cutting-edge network security appliance that provides advanced threat protection, secure connectivity, and simplified management. It combines next-generation firewall capabilities with intrusion prevention, application visibility and control, and advanced malware protection. With its comprehensive suite of security features, it offers a multi-layered defense against a wide range of cyber threats.

Key Cisco Secure Firewall Features:

– Advanced Threat Protection: The Cisco Secure Firewall employs advanced intelligence to detect and prevent sophisticated attacks, including malware, ransomware, and zero-day exploits. Its integrated security technologies work in tandem to identify and mitigate threats in real-time, ensuring your network infrastructure’s highest level of protection.

– Secure Connectivity: The Cisco Secure Firewall enables secure remote access and site-to-site connectivity with built-in VPN capabilities. It establishes encrypted tunnels, allowing authorized users to access network resources from anywhere while ensuring data confidentiality and integrity.

– Application Visibility and Control: Gaining visibility into network traffic and effectively managing application usage is crucial for optimizing network performance and ensuring security. The Cisco Secure Firewall offers granular application control, allowing administrators to define policies and prioritize critical applications while restricting or blocking unauthorized ones.

**Broken Firewall Rules**

One-third of your firewall rules are broken. You can use the Cisco AI Assistant for Security to identify and report policies, augment troubleshooting, and automate policy lifecycle management with the Cisco AI Assistant for Security. Also, take back control of your encrypted traffic and application environments. Cisco Talos lets you see and detect more across your infrastructure while ensuring security resilience across billions of signals.

**Advanced Clustering & HA**

This enabled you to drive efficiency at scale. Secure Firewall’s advanced clustering, high availability, and multi-instance capabilities allow you to scale, be reliable, and be productive. Finally, by integrating network, microsegmentation, and app security, Secure Firewall makes zero-trust achievable and cost-effective. It automates access and anticipates what comes next.

Knowledge Check: Cisco’s Firewalling

Cisco integrated its original Sourcefire’s next-generation security technologies into its existing firewall solutions, the Adaptive Security Appliances (ASA). In that early implementation, Sourcefire technologies ran as a separate service module. Later, Cisco designed new hardware platforms to support Sourcefire technologies natively.

They are named Cisco Firepower, later rebranded as Cisco Secure Firewall, which is the current implementation of Firewalling. In the new implementation, Cisco converges Sourcefire’s next-generation security features, open-source Snort, and ASA’s firewall functionalities into a unified software image. This unified software is called the Firepower Threat Defense (FTD). After rebranding, this software is now known as the Cisco Secure Firewall.

Example Security Technology: IPS IDS

Understanding Suricata

Suricata is an open-source network threat detection engine that offers high-performance intrusion detection and prevention capabilities. Built with speed, scalability, and robustness, Suricata analyzes network traffic and detects various threats, including malware, exploits, and suspicious activities. Its multi-threaded architecture and rule-based detection mechanism make it a formidable weapon against cyber threats.

Suricata boasts an impressive array of features that elevate its effectiveness in network security. Suricata covers various security needs, from protocol analysis and content inspection to file extraction and SSL/TLS decryption. Its extensive rule set allows for fine-grained control over network traffic, enabling tailored threat detection and prevention. Additionally, Suricata supports various output formats, making it compatible with other security tools and SIEM solutions.

Understanding SASE Cloud

Cisco SASE Cloud, short for Secure Access Service Edge Cloud, is a comprehensive networking and security platform that combines wide area networking (WAN) capabilities with robust security features. It offers a unified solution for remote access, branch connectivity, and cloud security, all delivered from the cloud. This convergence of networking and security into a single cloud-native platform allows organizations to simplify their infrastructure, reduce costs, and enhance agility.

SASE Cloud Key Points:

Enhanced Security: One of Cisco SASE Cloud’s standout features is its advanced security capabilities. By leveraging a combination of next-generation firewalls, secure web gateways, data loss prevention, and other security services, it provides comprehensive protection against cyber threats. With SASE Cloud, organizations can ensure secure access to applications and data from anywhere, anytime, without compromising security.

Scalability and Flexibility: Cisco SASE Cloud offers unmatched scalability and flexibility. As an organization grows, SASE Cloud can quickly adapt to evolving needs. Whether it’s adding new branches, onboarding remote employees, or expanding into new markets, the cloud-native architecture of SASE Cloud enables seamless scalability without the need for extensive infrastructure investments.

Simplified Management: Managing complex networking and security infrastructure can be daunting for IT teams. However, Cisco SASE Cloud simplifies this process by centralizing management and providing a single pane of glass for visibility and control. This streamlined approach allows IT teams to monitor and manage network traffic efficiently, apply security policies, and troubleshoot issues, improving operational efficiency.

Secure Access Anywhere & Anytime

Converged Networking and Security: Cisco SASE combines networking and security functions, such as secure web gateways, firewalls, and data loss prevention, into a single solution. This convergence eliminates the need for multiple standalone appliances, reducing complexity and improving operational efficiency.

Cloud-Native Architecture: Built on a cloud-native architecture, Cisco SASE leverages the scalability and flexibility of the cloud. This enables organizations to dynamically adapt to changing network demands, scale their resources as needed, and integrate new security services without significant infrastructure investments.

Enhanced User Experience and Security: With Cisco SASE, users can enjoy a seamless and secure experience regardless of location or device. Cisco SASE protects users and data from threats through its integrated security capabilities, including zero-trust network access and secure web gateways, ensuring a safe and productive digital environment.

Related: For additional pre-information, you may find the following helpful:

  1. SD WAN SASE
  2. SASE Model
  3. Zero Trust SASE
  4. SASE Solution
  5. Distributed Firewalls
  6. SASE Definition

Evolution of the Network Security

In the past, network security was typically delivered from the network using the Firewall. However, these times, network security extends well beyond just firewalling. We now have different points in the infrastructure that we can use to expand our security posture while reducing the attack surface.

You would have commonly heard of Cisco Umbrella Firewall and SASE, along with Cisco Secure Workload security, which can be used with your Cisco Secure firewall, which is still deployed at the network’s edge. Unfortunately, you can’t send everything to the SASE cloud.

You will still need an on-premise firewall, such as the Cisco Secure Firewall, that can perform standard stateful filtering, intrusion detection, and threat protection. This post will examine the Cisco Secure Firewall and its integration with Cisco Umbrella via the SASE Cloud. Firstly, let us address some basics of firewalling.

A. Redesigning Traditional Security:
Let’s examine the evolution of network security before we get into some inbound and outbound traffic use cases. Traditionally, the Firewall was placed at the network edge, acting as a control point for the network’s ingress/egress point. The Firewall was responsible for validating communications with rule sets and policies created and enforced at this single point of control to ensure that desired traffic was allowed into and out of the network and undesirable traffic was prevented. This type of design was known as the traditional perimeter approach to security.

B: Numerous Firewalling challenges:
Today, branch office locations, remote employees, and increasing use of cloud services drive more data away from the traditional “perimeter,” The cloud-first approach completely bypasses the conventional security control point.
Further, the overwhelming majority of business locations and users also require direct access to the Internet, where an increasing prevalence of cloud-based critical applications and data now lives. As a result, applications and data become further de-centralized, and networks become more diverse.

C: Conventional Appliance Sprawl:
This evolution of network architectures has dramatically increased our attack surfaces and did the job of protecting more complicated ones. So, we started to answer this challenge with point solutions. Typically, organizations have attempted to address these challenges by adding the "best" point security solution to address each new problem as it emerges. 

Because of this approach, we have seen tremendous device sprawl. Multiple security products from different vendors can pose significant management problems for network security teams, eventually leading to complexity and blind spots.

Consequently, our "traditional" firewall devices are being augmented by a mixture of physical and virtual appliances—some are embedded into the network. In contrast, others are delivered as a service, host-based, or included within public cloud environments. Regardless of the design, you will stall inbound and outbound traffic to protect.

**Basics of Firewalling**

A firewall is an entity or obstacle deployed between two structures to prevent fire from spreading from one system to another. This term has been taken into computer networking, where a firewall is a software or hardware device that enables you to filter unwanted traffic and restrict access from one network to another. The Firewall is a vital network security component in securing network infrastructure and can take many forms. For example, we can have a host-based or network-based Firewall.

Firewall types
Diagram: Firewall types. Source is IPwithease

Firewalling Types:

A. Host-based Firewall

A host-based firewall service is installed locally on a computer system. In this case, the end user’s computer system takes the final action—to permit or deny traffic. Every operating system has some Firewall. It consumes the resources of a local computer to run the firewall services, which can impact the other applications running on that particular computer. Furthermore, in a host-based firewall architecture, traffic traverses all the network components and can consume the underlying network resources until the traffic reaches its target.

B. Network-based Firewall

On the other hand, a network-based firewall can be entirely transparent to an end user and is not installed on the computer system. Typically, you deploy it in a perimeter network or at the Internet edge where you want to prevent unwanted traffic from entering your network. The end-user computer system remains unaware of any traffic control by an intermediate device performing the filtering. In a network-based firewall deployment, you do not need to install additional software or daemon on the end-user computer systems. However, it would help if you used both firewall types for a defense-in-depth approach.

The early generation of firewalls could allow or block packets only based on their static elements, such as a packet’s source address, destination address, source port, destination port, and protocol information. These elements are also known as the 5-tuple.

Example Technology Cisco Packet Filter

### Implementing Packet Filtering in Your Network

To effectively implement packet filtering, it’s crucial to have a clear understanding of your network architecture and traffic patterns. Begin by identifying the critical assets that need protection and the types of traffic that should be allowed. Develop a detailed access list, considering both inbound and outbound traffic.

C. Stateless Firewalling

When an early-generation firewall examined a particular packet, it was unaware of any prior packets that passed through it because it was agnostic of the Transmission Control Protocol (TCP) states that would have signaled this. Due to the nature of its operation, this type of Firewall is called a stateless firewall.

A stateless firewall is unable to distinguish the state of a particular packet. So, for example, it could not determine if a packet is part of an existing connection, trying to establish a legitimate new connection, or whether it is a manipulated, rogue packet. We then moved to a stateful inspection firewall and an application-aware form of next-generation firewalling.

D. Stateful Firewaling

The stateful inspection examines the TCP and UDP port numbers, while an application-aware firewall examines Layer 7. So now we are at a stage where the Firewall does some of everything, such as the Cisco Secure Firewall.

CBAC Firewall CBAC Firewall

**Firewalling Use Cases**

1.Inbound Use case

The Firewall picks up every packet, looks at different fields, examines for signatures that could signal an attack is in process, and then re-packs and sends the packet out its interfaces. Still, the technique is relevant. It tracks inbound traffic to tell if someone outside or inside is accessing the private applications you want to keep secure. So, looking at every packet is still relevant for the inbound traffic use case. 

While everything is encrypted these days, you need to decrypt traffic to gain security value. Deep Packet Inspection (DPI) is still very relevant for inbound traffic. So, we will continue to decrypt inbound traffic for complete application threat protection with the hope of minimal functional impact.

Example Technology: Sensitive Data Protection with Google Cloud

Sensitive data protection

2.Outbound Use Case

Then, we need to look at outbound traffic. Here, things have changed considerably. Some users need to catch up to a firewall and then go to applications hosted outside the protection of your on-premise security stack and network. These are applications in the cloud, such as SaaS applications, that do not like when the network devices in the middle interfere with the traffic.

Therefore, applications such as Office365 make an effort with their design to reduce the chances of the potential of any network and security device from peeking into their traffic. For example, you could have mutual certificate authentication with the service in the cloud. So, there are a couple of options here besides the traditional DPI use case for inbound traffic use case.

**Improving Security: Understanding the network**

Understanding Network Scanning

Network scanning involves exploring computer networks to gather information about connected devices, open ports, and system vulnerabilities. Cybersecurity professionals gain valuable insights into the network’s architecture, potential entry points, and security risks by utilizing various scanning techniques and tools.

There are different types of network scans, each serving a specific purpose. Port scans identify open ports and services running on them, while vulnerability scans aim to pinpoint weaknesses within network devices, applications, or configurations. Additionally, network mapping scans visually represent the network’s structure, aiding in better understanding and management.

Example: Cisco Secure Firewall 3100

Cisco has the Cisco Secure Firewall 3100, a mid-range model that can be an Adaptive Security Appliance (ASA) for standard stateful firewall inspection or Firewall Threat Defense (FTD) software.

So it can perform one or the other. It also has clustering, a multi-instance firewall, and high availability, which we will discuss. In addition, the Cisco Series Firewall throughput range addresses use cases from the Internet edge to the data center and private cloud.

Cisco Secure Firewall 3100 is an advanced next-generation firewall that provides comprehensive security and high performance for businesses of all sizes. Its advanced security features can protect an organization’s most critical assets, from data, applications, and users to the network infrastructure. Cisco Secure Firewall 3100 offers an integrated threat defense system that combines intrusion prevention, application control, and advanced malware protection. This firewall is designed to detect and block malicious traffic and protect your network from known and unknown threats.

Secure Firewall
Diagram: Cisco Secure Firewall. The source is Cisco.

Adaptive Security Appliance (ASA) and Firewall Threat Defense (FTD)

The platforms can be deployed in Firewall (ASA) and dedicated IPS (FTD) modes. In addition, the 3100 series supports Q-in-Q (stacked VLAN) up to two 802.1Q headers in a packet for inline sets and passive interfaces. The platform also supports FTW (fail-to-wire) network modules.

Remember that you cannot mix and match ASA and FTD modes. However, you can make FTD operate similarly to the ASA. For example, the heart of the Cisco Secure Firewall is Snort, one of the most popular open-source intrusion detection and prevention systems capable of real-time traffic inspection. 

**IPS Engine – Snort**

What’s powerful about the Cisco Secure Firewall is its high decryption performance due to the Crypto Engine. The Firewall has an architecture built around decrypting traffic and has impressive performance. In addition, you can tune your CPU cores to perform more traditional ASA functionality, such as termination IPsec and some stateful firewall inspection.

In such a scenario, we have an IPS engine ( based on Snort ) but give it only 10%. We can provide 90% of the data plane to traditional firewalling in this case. So, a VPN headend or basic stateful Firewall would use more data plane cores.

On the other hand, any heavy IPS and file inspection would be biased toward more “Snort” Cores. Snort provides the IPS engine to tailor the performance profiles to your liking. We have configurable CPU Core allocation, which can be set statically, not dynamically.

Secure Firewalling Features:

1.Secure Firewall Feature: Clustering

Your Secure Firewall deployment can also expand as your organization grows to support its network growth. You do not need to replace your existing devices for additional horsepower; you can add threat defense devices to your current deployment and group them into a single logical cluster to support additional throughput. 

A clustered logical device offers higher performance, scalability, and resiliency simultaneously. You can create a cluster between multiple chassis or numerous security modules of the same chassis. When a cluster is built with various independent chassis, it is called inter-chassis clustering.

2.Secure Firewall Feature: Multi-Instance

The Secure Firewall offers multi-instance capability powered by Docker container technology. It enables you to create and run multiple application instances using a small subset of a chassis’s hardware resources. You can independently manage the threat defense application instances as separate threat defense devices. Multi-instance capability enables you to isolate many critical elements.

3.Secure Firewall Feature: High Availability

In a high-availability architecture, one device operates actively while the other stays on standby. A standby device does not actively process traffic or security events. For example, suppose a failure is detected in the active device, or there’s any discontinuation of keepalive messages from the active device.

In that case, the standby device takes over the role of the active device and starts operating actively to maintain continuity in firewall operations. An active device periodically sends keepalive messages and replicates its configurations to a standby device. Therefore, the communication channel between the peers of a high-availability pair must be robust and with much less latency. 

Exploring SASE Cloud

One way to examine SaaS-based applications and introduce some cloud security is by using Cisco Umbrella with the SASE Cloud. The SASE Cloud can also have a cloud access security broker known as Cloudlock. The Cisco Umbrella CASB  is like a broker that hooks into the application’s backend to determine users’ actions. It does this by asking for the service via an Application Programming Interface (API) call and not by DPI.

Cisco Umbrella
Diagram: Cisco Umbrella. Source is Cisco

Cisco Cloudlock is part of the SASE cloud that provides a cloud-native cloud access security broker (CASB) that protects your cloud users, data, and apps. Cloud lock’s simple, open, and automated approach uses APIs to manage the risks in your cloud app ecosystem. With Cloudlock, you can more quickly combat data breaches while meeting compliance regulations.

Cisco Umbrella also has a firewall known as the Cisco Umbrella Firewall. We can take the Cisco Umbrella Firewall to improve its policy decision using information gleaned from the CASB. In addition, we map network flows to a specific user action via cloud applications and CASB solutions. So this is one area you can look into.

Extending the Firewall with SASE Cloud

Cisco Umbrella Firewall:

The SASE Cloud with Cisco Umbrella firewall is a good solution that can be combined with the on-premise Firewall. So, if you have FDT at the edge of your network, why would you need to introduce a Cisco Umbrella Firewall or any other SASE technologies? Or if you have a SASE cloud with a Cisco Umbrella, why would you need FDT?

First, it makes sense to process specific traffic locally. However, the two categories of traffic that Cisco Umbrella excels in beyond any firewall are DNS and CASB. Your edge firewall is less effective against some outbound traffic, such as dynamically changing DNS and undecryptable TLS connections. DNS is Cisco Umbrella’s bread and butter.

DNS Request Proceed The IP Connection

Knowledge Check: Cisco DNS-layer security.

DNS requests precede the IP connection, enabling DNS resolvers to log requested domains over any port or protocol for all network devices, office locations, and roaming users. As a result, you can monitor DNS requests and subsequent IP connections to improve the accuracy and detection of compromised systems, security visibility, and network protection. 

You can also block requests to malicious destinations before a connection is even established, thus stopping threats before they reach your network or endpoints. Cisco Umbrella under the hood can clean your DNS traffic and stop the attacks before they get to any malicious connection. 

SASE Cloud: Cisco Umbrella CASB.

Also, you can not decrypt SaaS-based applications and CASB on the edge firewall. The Firewall can’t detect if the user is carrying out any data exfiltration.

With SASE cloud, Cisco Umbrella, and its integrated CASB offering, we get better visibility in this type of traffic and apply a risk category to certain kinds of activity. So now we have an excellent combination. The cloud security stack does what it does best: processing cycles away from the Firewall.

**Cisco Umbrella Integration**

With the Cisco Secure Firewall, they have nice DNS redirection to the Cisco Umbrella Firewall. The on-premise Firewall communicates API to Cisco Umbrella and pulls in the existing DNS policy so the Umbrella DNS policies can be used with the current firewalling policies.  Recently, Cisco has gone one step further, and you can have a SIG tunnel between the Cisco Secure Firewall Management Center (FMC) and the Cisco Umbrella.

So there is a tunnel and have per tunnel IKE ID and bundle multiple tunnels to Umbrella.  Now, we can have load balance across multi-spoke tunnels with per-tunnel custom IKE ID. Once set up, we can have certain kinds of traffic going down each tunnel.

**Endpoint controls**

Then, we have the endpoint, such as your desktop computer or phone. We can collect a wealth of information about each network connection. This information can be fed into the Firewall via metadata. So you can provide both the Cisco Umbrella Firewall and the Cisco Secure Firewall. Again, for improved policy.

The Firewall, either the Cisco Secure Firewall or the Cisco Umbrella Firewall, does not need to decrypt any traffic. Instead, we can get client context discovery via passive fingerprinting using an agent on the endpoint. We can get a wealth of attributes you can’t get with DPI. So we can move from DPI to everything and augment that with all other components to get better visibility.

Summary: Cisco Secure Firewall with SASE Cloud

In today’s rapidly evolving digital landscape, organizations face the challenge of ensuring robust security while embracing the benefits of cloud-based solutions. Cisco Secure Firewall with SASE (Secure Access Service Edge) Cloud offers a comprehensive and streamlined approach to address these concerns. This blog post delved into the features and benefits of this powerful combination, highlighting its ability to enhance security, simplify network management, and optimize performance.

Understanding Cisco Secure Firewall

Cisco Secure Firewall serves as the first line of defense against cyber threats. Its advanced threat detection capabilities and deep visibility into network traffic provide proactive protection for organizations of all sizes. Cisco Secure Firewall ensures a secure network environment by preventing unauthorized access, blocking malicious content, or detecting and mitigating advanced threats.

Introducing SASE Cloud

On the other hand, SASE Cloud revolutionizes how organizations approach network and security services. SASE Cloud offers a scalable and agile solution by converging network functions and security services into a unified cloud-native platform. It combines features such as secure web gateways, data loss prevention, firewall-as-a-service, and more, all delivered from the cloud. This eliminates the need for costly on-premises infrastructure and allows businesses to scale their network and security requirements effortlessly.

The Power of Integration

When Cisco Secure Firewall integrates with SASE Cloud, it creates a formidable combination that enhances security posture while delivering optimal performance. The integration allows organizations to extend their security policies seamlessly across the entire network infrastructure, including remote locations and cloud environments. This unified approach ensures consistent security enforcement, reducing potential vulnerabilities and simplifying management overhead.

Simplified Network Management

One of the key advantages of Cisco Secure Firewall with SASE Cloud is its centralized management and control. Administrators can easily configure and enforce security policies, monitor network traffic, and gain valuable insights through a single glass pane of glass. This simplifies network management, reduces complexity, and enhances operational efficiency, enabling IT teams to focus on strategic initiatives rather than mundane tasks.

Conclusion

In conclusion, the combination of Cisco Secure Firewall with SASE Cloud provides organizations with a robust and scalable security solution that meets the demands of modern networks. By integrating advanced threat detection, cloud-native architecture, and centralized management, this potent duo empowers businesses to navigate the digital landscape confidently. Experience the benefits of enhanced security, simplified management, and optimized performance by adopting Cisco Secure Firewall with SASE Cloud.

SASE Model

SASE Model | Zero Trust Identity

Network Insight · Engineering Guide

SASE & Zero Trust: From Network Perimeter to Identity-Driven Security

Enterprise networks have changed. Users work from anywhere, applications increasingly run across multiple clouds, and business traffic no longer follows a predictable path through a central corporate data centre. Security therefore cannot depend on network location alone.

Secure Access Service Edge (SASE) brings networking and security closer to users, devices and applications through cloud-delivered services. Zero Trust adds the decision model: access is evaluated using identity, device posture, context, risk and policy rather than simply assuming that a trusted network location means a trusted user or session.

Engineering Question
If users, devices and applications are distributed everywhere, how should an enterprise connect, authenticate, enforce security and respond to risk?
CONNECT
→
IDENTIFY
→
ENFORCE
→
DETECT
What This Guide Examines

This guide treats SASE as an engineering architecture rather than a single product. It follows a request from the network edge through identity and policy decisions, into the security services that enforce those decisions, and finally into the telemetry and response systems used when behaviour becomes suspicious.

Engineering Progression
01
Architecture
02
Identity
03
Enforcement
04
Operations
Core model: SASE determines where networking and security services are delivered; Zero Trust determines whether a particular request should be trusted, restricted or denied.
Engineering Guide · Navigation

SASE & Zero Trust Engineering Path

Explore the guide as an engineering workflow — from architecture and identity through security enforcement and operational response.
ARCHITECT → IDENTIFY → ENFORCE → DETECT

SASE Architecture & the New Enterprise Network

Section 01 · Architecture

SASE Architecture & the New Enterprise Network

Understand why enterprise networking is moving from centralised perimeter infrastructure toward distributed, cloud-delivered connectivity and security.
Architecture
USER → EDGE → SASE PoP → SECURITY → APPLICATION
Engineering Question
If users and applications are distributed everywhere, where should networking and security enforcement actually happen?
Explore
Follow a request through the SASE architecture.
OPEN LAB
Section 01 · Architecture

SASE Architecture & the New Enterprise Network

Enterprise networks have changed fundamentally. Users no longer work from a small number of corporate offices, applications no longer reside exclusively inside private data centres, and business traffic increasingly crosses the public Internet before reaching cloud or SaaS services. SASE provides an architectural model for delivering networking and security capabilities closer to those users, devices and applications.

Engineering Principle

SASE is not a single security product. It is an architectural approach that combines distributed networking, cloud-delivered security enforcement and policy-driven access control so that security decisions can follow users, devices and applications rather than depending entirely on a traditional network perimeter.

The Internet Is Becoming the Enterprise Network

Traditional enterprise architecture was built around a relatively stable boundary. Users connected to offices, offices connected to private WAN infrastructure, and security controls were concentrated around the data centre or Internet edge. Firewalls, proxies, VPN concentrators and intrusion-prevention systems therefore occupied predictable positions in the network.

Modern organisations operate differently. Employees may connect from homes, branch offices, mobile networks, partner locations or temporary workspaces. Applications may be hosted in public cloud, private cloud, SaaS platforms or distributed application environments. The traffic path between a user and an application is therefore no longer determined simply by physical network location.

This creates a fundamental architectural problem: security controls must remain effective even when the user, device, application and network are distributed.

01 USER
02 DEVICE
03 NETWORK
04 CLOUD / INTERNET
05 APPLICATION

From the Data Centre Perimeter to Distributed Enforcement

A traditional security model often assumes that traffic can be brought back through a central enforcement point. This can provide strong control, but it can also introduce unnecessary routing complexity, additional latency and operational dependency on a small number of network locations.

SASE changes the architectural question from “How do we bring the user to the security perimeter?” to “How do we deliver the appropriate security controls close to the user and application?”

That distinction is important. SASE does not mean that the enterprise stops using firewalls, routing, segmentation or private connectivity. Instead, these capabilities become part of a broader distributed architecture in which policy and security enforcement can be delivered through cloud-based points of presence and other strategically positioned enforcement locations.

What SASE Combines

At its architectural core, SASE brings together two traditionally separate domains: network connectivity and security services.

Domain Typical Capability Engineering Role
Networking SD-WAN / intelligent routing Selects appropriate paths and connectivity based on application and network conditions.
Security SWG Applies security policy to Internet and web traffic.
Security FWaaS Provides distributed firewall policy without requiring a physical firewall at every location.
Access ZTNA Controls access to private applications using identity, device and policy context.
Data CASB / DLP Applies application and data protection controls to cloud traffic and sensitive information.
Visibility Telemetry and analytics Provides the evidence required to monitor performance, security events and policy decisions.

Networking and Security Become Policy-Driven

One of the most important changes introduced by SASE is the relationship between connectivity and security policy. Instead of treating routing, security and application access as completely independent systems, the architecture can make decisions using a common set of signals.

SASE Decision Architecture
IDENTITY → CONTEXT → POLICY → ENFORCEMENT → RESOURCE

Identity can describe who is making the request. Context can include device posture, location, application, network conditions and other relevant signals. Policy determines what should be permitted. Enforcement then applies the resulting decision to the traffic or access request.

This is the architectural bridge between SASE and Zero Trust. SASE provides the distributed networking and security architecture; Zero Trust provides the decision philosophy in which access is continuously evaluated rather than being implicitly trusted because a request originated from a particular network.

SD-WAN as Part of the SASE Architecture

SD-WAN is often associated with the networking side of SASE. Its role is to provide application-aware connectivity across available transport paths such as broadband, private circuits and cellular connectivity.

Rather than treating every packet as equivalent, an SD-WAN architecture can identify applications and use policy to select an appropriate path. Performance measurements such as latency, loss and jitter can also influence path selection.

However, SD-WAN alone is not SASE. SD-WAN primarily addresses connectivity and traffic steering, while SASE extends the architecture into security enforcement, identity-aware access, cloud security and distributed policy control.

Security Service Edge

The security side of the architecture is commonly described using the term Security Service Edge (SSE). SSE focuses on cloud-delivered security services such as secure web access, zero-trust application access and cloud/data security controls.

In practical architectures, the networking and security components can therefore be viewed as complementary layers. SD-WAN provides connectivity and traffic steering, while SSE provides distributed security enforcement. Together, they form an important part of the broader SASE model.

Why Points of Presence Matter

A distributed SASE architecture depends on strategically located enforcement points, commonly delivered through provider points of presence (PoPs). The purpose is not simply to create more locations. The objective is to reduce unnecessary traffic tromboning while providing security enforcement near users and destinations.

Consider a user in one region accessing a SaaS application hosted in another region. A poorly designed architecture might force that traffic through a distant corporate data centre before allowing it to reach the SaaS service. A distributed architecture can instead select an appropriate security enforcement location and then connect toward the destination.

The engineering challenge is therefore not simply geographic proximity. The design must consider latency, security policy, application requirements, data sovereignty, availability, inspection requirements and operational visibility.

SASE Is Not a Single Traffic Path

A common mistake is to imagine SASE as a fixed chain in which every packet must pass through every security service. Real architectures are more selective.

An Internet request may require secure web gateway inspection. A private application request may require ZTNA enforcement. A SaaS transaction involving sensitive data may require CASB or DLP controls. Another request may require only a subset of these controls.

The correct mental model is therefore policy-driven service selection, not a mandatory linear chain.

Engineering Rule

Do not design SASE as “all traffic passes through all services.” Design it as “policy determines which security services are relevant to this request.”

Traditional Perimeter vs Distributed SASE

Traditional Perimeter Distributed SASE Model
Security concentrated around offices and data centres. Security services distributed closer to users and applications.
Network location strongly influences trust. Identity, device, context and policy influence access decisions.
Remote users often connect through central VPN infrastructure. Users can receive policy-driven access through distributed enforcement.
Cloud traffic may be forced through legacy inspection points. Cloud and Internet traffic can be inspected at appropriate distributed enforcement locations.
Security appliances are often tied to physical sites. Security capabilities can be delivered as cloud services.

SASE Deployment Is an Architectural Journey

SASE should not be treated as a requirement to replace an entire enterprise network immediately. Most organisations already have significant investments in routing, firewalls, VPNs, identity platforms, endpoint controls, proxies and cloud infrastructure.

A practical migration therefore introduces capabilities incrementally. An organisation may begin with SD-WAN, move Internet security toward cloud-delivered enforcement, introduce ZTNA for selected applications, integrate identity and device signals, and progressively consolidate policy and telemetry.

01
Start With Architecture

Map users, devices, applications, data and existing security enforcement points before deciding which SASE capabilities to introduce.

02
Move Policy, Not Just Appliances

The objective is not simply to replace hardware with cloud services. Policy must become portable, identity-aware and consistently enforceable.

03
Integrate Identity

Network connectivity alone cannot determine whether access should be permitted. Identity and device context must become part of the decision.

04
Build Visibility

Distributed enforcement creates more policy decision points, making consistent telemetry and centralised analysis essential for operations.

The Engineering Model

The most useful way to understand SASE is therefore not as a product category, but as a change in where networking and security decisions are made.

The enterprise moves from a model dominated by network location and centralised perimeter enforcement toward a model in which identity, context, policy and distributed enforcement work together.

Section 01 Engineering Takeaway

SASE provides the architectural foundation for a distributed enterprise: connectivity becomes application-aware, security enforcement moves closer to users and applications, and policy can incorporate identity and context rather than relying primarily on network location.

Engineering Lab · Section 01

SASE Architecture Flow

Change the destination and step the request through the distributed SASE architecture. Observe which security controls become relevant and why the path is policy-driven rather than a fixed security chain.
ARCHITECTURE ACTIVE
Live Request Path
◉
USER / DEVICE Distributed endpoint
→
◇
EDGE Nearest access point
→
◆
SASE PoP Cloud enforcement
→
⬡
SECURITY Policy services
→
▣
APPLICATION Internet
DNS SECURITY Resolve and classify destination
SWG Secure web access policy
FWAAS Network security policy
CASB SaaS visibility and control
DLP Protect sensitive information
ZTNA Private application access
IDENTITY Identity and access context
TELEMETRY Continuous evidence
Request Telemetry
Destination Internet
Path Stage USER / DEVICE
Policy Scope Web Access
Trust Model Zero Trust
CURRENT DECISION
EVALUATING
Event Stream
Engineering Readout
Start the request. Step through the architecture to see how the request progresses.
Engineering Challenge
Question: Does every request need to traverse every SASE security service?

Zero Trust Identity & Adaptive Access

Section 02 · Identity

Zero Trust Identity & Adaptive Access

Move beyond network location and evaluate every access request using identity, device posture, context, risk and policy.
Zero Trust
IDENTITY → DEVICE → CONTEXT → RISK → POLICY → DECISION
Engineering Question
When a valid identity becomes risky, should access remain allowed?
Explore
Test how changing risk changes the access decision.
OPEN LAB
Section 02 · Identity

Zero Trust Identity & Adaptive Access

Once security enforcement is distributed across users, devices, cloud applications and Internet services, network location can no longer be treated as a sufficient indication of trust. Zero Trust changes the access model by requiring every request to be evaluated using identity, device state, context, risk and policy.

Engineering Principle

A successful authentication proves that an identity has been authenticated. It does not automatically prove that the identity should receive unrestricted access to every resource.

Authentication Is Not Authorisation

One of the most important concepts in Zero Trust architecture is the distinction between authentication and authorisation.

Authentication answers the question: “Who are you?” Authorisation answers a different question: “What are you allowed to access?”

A user may successfully authenticate with a valid password, passkey or multi-factor authentication method and still be denied access to a sensitive application. The access decision may depend on the user's role, device security state, location, application sensitivity, requested operation or current risk level.

Zero Trust Access Decision Model
IDENTITY → DEVICE → CONTEXT → RISK → POLICY → DECISION

Identity Becomes a Primary Security Signal

In a traditional perimeter model, network location can provide a strong implicit signal. A device connected to the corporate LAN may be considered more trusted than a device on an external network.

Zero Trust reduces that assumption. The identity making the request becomes a primary security signal, but it is evaluated alongside other evidence rather than being treated as sufficient by itself.

ID Identity

User, service account or workload identity making the request.

DV Device

Device posture, management state, security controls and compliance.

CX Context

Location, time, network characteristics, application and request context.

RK Risk

Signals indicating unusual, suspicious or potentially compromised behaviour.

PL Policy

Rules defining which combinations of signals should permit access.

EN Enforcement

The control that actually allows, restricts, challenges or denies the request.

Multi-Factor Authentication

Multi-factor authentication strengthens authentication by requiring more than one category of evidence. The objective is to reduce the impact of compromised passwords and other single-factor credentials.

Modern deployments can include phishing-resistant mechanisms such as passkeys and FIDO2/WebAuthn, alongside other authentication factors where appropriate. The important architectural point is that MFA strengthens the authentication stage; it does not remove the need for subsequent authorisation and risk evaluation.

Important Distinction

MFA should not be treated as a universal “trusted” flag. A user who completed MFA can still present a risky device, an unusual access pattern or a request for a resource they are not authorised to use.

Device Posture Becomes Part of the Decision

Identity alone provides an incomplete picture. A valid identity using an unmanaged or compromised endpoint may represent significantly greater risk than the same identity using a healthy, managed device.

Device posture can therefore become another input to policy. Examples include whether the endpoint is managed, whether security controls are active, whether the operating system meets the required baseline and whether the device has recently generated security alerts.

This creates a more useful decision model: the same user may receive different access depending on the state of the device making the request.

Context Changes the Meaning of an Authentication Event

Context adds another layer of evidence. A login from a normal location during expected working hours may be routine. A login for the same identity from an unusual location followed immediately by access to a sensitive application may require additional verification.

Context can include geographic location, time, network characteristics, application, resource sensitivity and the sequence of actions associated with the session.

The goal is not to block every unusual event. The goal is to use contextual evidence to determine when the normal access decision should change.

Risk-Based Access Decisions

Zero Trust architectures can combine multiple signals into a risk assessment. Risk should be treated as dynamic rather than as a permanent property of an identity.

For example, a user may begin with a normal risk level and receive ordinary access. A later event, such as an impossible-travel indicator, suspicious authentication activity or endpoint security alert, can increase the risk associated with the session.

The resulting policy response does not necessarily have to be an immediate denial. Different levels of risk can trigger different enforcement actions.

Condition Potential Risk Example Response
Known identity + healthy device + expected context Low Allow normal access.
Known identity + unfamiliar device Moderate Require additional verification or restrict access.
Known identity + unusual context Elevated Step-up authentication or limit sensitive actions.
Identity + suspicious authentication behaviour High Restrict access and initiate investigation.
Compromise indicators + sensitive resource request Critical Deny, revoke session/token and potentially isolate the endpoint.

Adaptive Authentication

Adaptive authentication allows the authentication experience to respond to context and risk. A low-risk request may proceed normally, while a higher-risk request can require stronger verification.

This creates a more useful model than treating every authentication event identically. The security system can increase friction when evidence indicates elevated risk while avoiding unnecessary interruption for routine activity.

A typical decision sequence might therefore look like:

Adaptive Access Sequence
REQUEST → EVALUATE → RISK → POLICY → ALLOW / STEP-UP / RESTRICT / DENY

Least Privilege

Zero Trust also changes how authorisation is designed. Instead of granting broad access because a user belongs to a trusted network or security group, policies should provide only the permissions required for the task.

Least privilege can be applied to users, administrators, service accounts and workloads. Access should be limited by resource, action, scope and duration wherever practical.

Just-in-Time Access

Privileged access can be particularly dangerous when it remains permanently enabled. Just-in-time access reduces exposure by granting elevated privileges only when required and for an appropriate period.

Identity-Driven Segmentation

Segmentation can also move beyond IP addresses and VLAN boundaries. Policies can use identity, application and resource context to determine which services a user or workload can reach.

This does not make traditional network segmentation obsolete. Instead, identity-aware controls add another layer of precision to the segmentation model.

Continuous Verification

Zero Trust is often summarised as “never trust, always verify,” but the useful engineering interpretation is more precise: trust should not be assumed from network location, and access decisions should be capable of changing when relevant evidence changes.

A session that was acceptable five minutes ago may become unacceptable after a new security signal appears. This is why identity telemetry, endpoint telemetry, authentication events and application activity need to feed into the broader security architecture.

01
Authenticate

Establish the identity associated with the request using an appropriate authentication mechanism.

02
Evaluate

Combine identity, device, context and available risk signals.

03
Authorise

Determine which resource and actions the identity should be permitted to access.

04
Re-evaluate

Respond when new evidence changes the risk or policy context of an active session.

Zero Trust Does Not Mean “No Trust”

Zero Trust does not mean that every request must be manually approved. That would be operationally impractical at enterprise scale.

Instead, trust is transformed into a policy-controlled and continuously evaluated decision. Automated systems use identity, device, context and risk signals to determine whether access should be allowed and under what conditions.

This distinction matters because a mature Zero Trust architecture should improve security without creating unnecessary friction. Low-risk activity should remain efficient, while higher-risk activity receives stronger controls.

Identity as the Control Plane

In a distributed SASE architecture, identity increasingly acts as a control-plane signal connecting users, devices, applications and security policy.

The identity layer can provide the context required for access decisions, while SASE enforcement points apply those decisions close to the user or application. This creates a direct relationship between who is requesting access and where and how that access is enforced.

Architecture Connection

Section 01 established the distributed SASE architecture. Section 02 adds the identity and decision layer. The next engineering question is therefore: once a decision has been made, which security services should actually process the request?

Section 02 Engineering Takeaway

Zero Trust replaces implicit trust based on network location with policy-driven access decisions based on identity, device, context and risk. Authentication establishes identity; authorisation determines access; adaptive controls change enforcement when the evidence changes.

Engineering Lab · Section 02

Zero Trust Access Decision Engine

Change the identity, device, context and application conditions. Watch the Zero Trust policy engine calculate risk and determine whether the request should be allowed, stepped up, limited or denied.

ADAPTIVE POLICY ACTIVE
Zero Trust Evaluation Pipeline
LIVE POLICY STATE
01 IDENTITY
02 DEVICE
03 CONTEXT
04 RISK
05 POLICY
06 DECISION
Identity State
Verified
Device Posture
Healthy
Context
Normal
MFA Signal
Passed
Application
Standard
Privilege
Normal
Calculated Access Risk
10
LOW MODERATE HIGH CRITICAL
Policy Decision
ENFORCEMENT
Current Outcome
ALLOW
Identity and device signals are within policy thresholds.
Evidence Signals
CORRELATED
Verified identity
Healthy managed device
Normal access context
MFA successfully completed
Decision Event Stream
LIVE TELEMETRY
00:00:00
Policy engine initialised — waiting for access request.
READY

Engineering Readout

Zero Trust does not assume that a valid identity automatically represents a trusted session. Identity, device, context and application sensitivity are evaluated together.

Engineering Challenge

What happens when the identity is valid but the device becomes unmanaged and the application is highly sensitive?

SASE Security Service Path

Section 03 · Enforcement

SASE Security Service Path

Follow the request through the security controls that may be required for Internet, SaaS, private-application and sensitive-data access.
Enforcement
USER → DNS → SWG → FWaaS → CASB → DLP → ZTNA
Engineering Question
Which security controls should process this request — and which controls are unnecessary?
Explore
Watch policy select the appropriate service path.
OPEN LAB
Section 03 · Enforcement

SASE Security Service Path

The first two sections established the architecture and the access decision. The next engineering question is what happens to the request after those decisions are made. SASE provides a distributed set of security services that can inspect, control, route and protect traffic according to the requirements of the request.

Engineering Principle

A SASE service path should not be designed as a mandatory chain where every request passes through every security service. Policy determines which controls are relevant to the identity, device, destination, application, data and risk associated with the request.

From Access Decision to Security Enforcement

Section 02 introduced the Zero Trust decision model: IDENTITY → DEVICE → CONTEXT → RISK → POLICY → DECISION.

Section 03 extends that model into the traffic plane. Once the system understands who is making the request and what the policy allows, the architecture must determine which security services should process the traffic before it reaches its destination.

Policy-Driven SASE Service Path
USER / DEVICE → DNS SECURITY → SWG → FWaaS → CASB → DLP → ZTNA → RESOURCE

This diagram represents the available security functions rather than a compulsory sequence. A particular request may use only one or two of these services, while a sensitive transaction may require several controls.

DNS Security

DNS is often one of the first security control points encountered when a user or device attempts to access an Internet destination. DNS security can identify malicious domains, known command-and-control infrastructure, phishing destinations and other categories that policy may prohibit.

Blocking a malicious destination at the DNS layer can prevent the connection from progressing further. This makes DNS an efficient early enforcement point, although it should not be treated as a replacement for deeper traffic and application controls.

Secure Web Gateway

A Secure Web Gateway (SWG) applies security policy to web traffic. Depending on architecture and policy, it can provide URL filtering, malware protection, application controls, acceptable-use enforcement and other inspection capabilities.

The important SASE concept is that the gateway does not have to be a physical appliance located at a central corporate Internet edge. The capability can be delivered through distributed cloud enforcement points closer to the user.

Firewall as a Service

Firewall as a Service (FWaaS) extends firewall policy into a distributed service model. Instead of requiring dedicated firewall appliances at every location, organisations can apply centrally managed policy through cloud-delivered enforcement.

Firewall policy can still control source, destination, protocol, application and other attributes. The architectural difference is that enforcement becomes less dependent on the physical location of a particular appliance.

Cloud Access Security Broker

CASB capabilities address security requirements associated with cloud applications. Cloud services create a visibility challenge because users can access SaaS applications directly from many locations and devices.

CASB controls can help identify cloud applications, apply policy, monitor usage and enforce security requirements around cloud data and application activity.

CASB should therefore be understood as a set of cloud security capabilities rather than simply another network hop that every packet must traverse.

Data Loss Prevention

DLP focuses on protecting sensitive information rather than simply determining whether a destination is safe. The control can evaluate data being uploaded, downloaded, shared or transmitted and compare it against organisational policy.

This becomes particularly important when users interact with SaaS platforms, cloud storage, collaboration systems and other Internet-accessible services.

Important Shift

Network security asks whether traffic should be allowed. Data security asks whether the specific information being transmitted should be allowed to leave its current security boundary.

Zero Trust Network Access

ZTNA provides a different access model for private applications. Instead of placing a user on a broad network and allowing that user to discover reachable resources, ZTNA can provide access to specific applications based on identity and policy.

This creates a significant architectural distinction between network access and application access.

A user may be authorised to access one application without receiving general network-level connectivity to the surrounding infrastructure. This supports least privilege and reduces the attack surface exposed to compromised identities and devices.

Understanding the Security Service Categories

DNS DNS Security

Blocks or redirects access to known malicious or prohibited destinations.

Early destination control
SWG Secure Web Gateway

Applies security policy to web and Internet traffic.

Web security enforcement
FW FWaaS

Applies distributed firewall policy to network traffic.

Network policy enforcement
CASB CASB

Provides visibility and policy controls for cloud applications.

Cloud application control
DLP DLP

Evaluates sensitive information against data protection policy.

Data protection
ZT ZTNA

Provides identity-aware access to authorised private applications.

Application access control

Not Every Request Needs Every Service

The most important operational concept in this section is selective enforcement. A SASE architecture should determine which services are relevant rather than automatically forcing all traffic through every available control.

Request Likely Relevant Controls Primary Objective
Internet DNS Security, SWG, FWaaS Protect general Internet access and enforce security policy.
SaaS DNS Security, SWG, CASB, DLP Control cloud application usage and sensitive data movement.
Private App ZTNA, identity policy, device posture Provide least-privilege application access.
Sensitive Data DLP, CASB, application controls Determine whether specific information can be transferred.
Malicious DNS DNS Security Stop the request before a connection is established.

Encrypted Traffic Changes the Inspection Model

Modern applications rely heavily on encrypted protocols, particularly TLS. Encryption protects confidentiality, but it also changes how security controls obtain visibility into traffic.

Depending on architecture, policy and legal requirements, security services may use metadata, destination intelligence, endpoint telemetry, application-aware controls or controlled decryption and inspection.

Decryption is therefore not automatically required for every connection. It is an architectural decision that must consider security value, privacy, regulatory requirements, application compatibility and performance.

Security Service Chaining

Security service chaining describes the process of directing traffic through the appropriate sequence of security functions. In a SASE architecture, this can become policy-driven rather than being hard-coded to a physical topology.

For example, an ordinary Internet request may require DNS security and web filtering. A sensitive SaaS transaction may additionally require cloud application and DLP controls. A private application request may instead be directed toward an identity-aware ZTNA service.

Example Policy Selection
REQUEST → IDENTITY → DESTINATION → POLICY → SERVICE SELECTION → ENFORCE

Microsegmentation and Application-Level Access

SASE and Zero Trust architectures increasingly move segmentation away from a purely network-centric model. Traditional segmentation often relies on VLANs, subnets, firewall zones and IP addresses.

Identity-aware application access allows policy to become more granular. A user may be permitted to access a particular application without receiving unrestricted access to the network segment hosting that application.

This reduces the amount of infrastructure exposed to a compromised identity and supports the principle of least privilege introduced in Section 02.

Four Common Enforcement Scenarios

Scenario 01
Malicious Destination

DNS intelligence identifies a known malicious destination. The request is blocked before the user establishes the connection.

Scenario 02
Untrusted Device

The identity is valid, but the endpoint fails the required device posture. Policy can restrict or deny access rather than treating authentication as sufficient.

Scenario 03
Private Application

A user requests a private application. ZTNA evaluates identity and policy and exposes only the authorised application rather than broad network access.

Scenario 04
Sensitive Data

A user attempts to upload protected information to a cloud service. DLP and application policy determine whether the transaction should be permitted.

The Enforcement Plane

The SASE enforcement plane is therefore best understood as a collection of specialised security functions controlled by a common policy model. Each service provides a different type of protection, and the architecture determines which combination is appropriate for the request.

This separation is important because it prevents SASE from becoming another rigid perimeter architecture. The security decision follows the request rather than forcing the request through a fixed physical path.

Architecture Connection

Section 02 determined whether access should be allowed. Section 03 determines which enforcement controls should process that access. The final question is operational: how do we observe these decisions, detect abnormal behaviour and respond when the security model is challenged?

Section 03 Engineering Takeaway

SASE security services form a policy-driven enforcement plane. DNS Security, SWG, FWaaS, CASB, DLP and ZTNA each address different security requirements, but not every request requires every service. The correct architecture selects controls according to identity, device, destination, application, data and risk.

SASE Visibility, Detection & Response

Section 04 · Operations

SASE Visibility, Detection & Response

Connect identity, endpoint, DNS, network and application telemetry so that changing risk can be detected and acted upon.
Operations
OBSERVE → CORRELATE → INVESTIGATE → CONTAIN → RECOVER
Engineering Question
What evidence is strong enough to treat an identity, device or session as compromised?
Explore
Investigate a multi-stage SASE security incident.
OPEN LAB
Section 04 · Operations

SASE Visibility, Detection & Response

Distributed security changes the operational problem. Once networking, identity and security enforcement are spread across users, endpoints, cloud applications and SASE points of presence, security teams need a unified view of what is happening across those control points. Visibility is therefore not an optional addition to SASE; it is required to operate the architecture effectively.

Engineering Principle

A security decision is only as useful operationally as the evidence available to explain why it happened, what happened next and whether the risk changed.

From Enforcement to Continuous Telemetry

Sections 01–03 established the SASE architecture, identity decision model and security enforcement plane. Those layers generate a large amount of operational evidence.

Authentication systems generate identity events. Endpoint platforms generate device telemetry. DNS services generate destination queries. SWGs and firewalls generate traffic and policy events. ZTNA systems generate application-access decisions. Cloud applications generate their own audit information.

The challenge is to combine those signals into a coherent operational picture.

SASE Operational Security Loop
OBSERVE → CORRELATE → ASSESS → INVESTIGATE → RESPOND → RE-EVALUATE

What Telemetry Does SASE Generate?

ID Identity Events

Authentication attempts, MFA events, session changes, privilege activity and identity-risk signals.

EP Endpoint Events

Device posture, endpoint alerts, process activity and security-control status.

DNS DNS Activity

Domain queries, blocked destinations, threat classifications and unusual lookup behaviour.

NET Network Flows

Source, destination, application, transport and traffic-volume information.

APP Application Events

SaaS activity, private-application access and application-level policy events.

POL Policy Decisions

Allow, deny, step-up, restrict and other enforcement outcomes with decision context.

Identity Telemetry

Identity events are particularly valuable because they can connect otherwise separate security observations to a specific user, administrator, service account or workload.

A suspicious DNS request becomes more useful when it can be correlated with the identity that generated it. An unusual application access event becomes more significant when the same identity recently experienced an MFA anomaly.

This is one of the key operational advantages of the SASE and Zero Trust model: security events can be interpreted in the context of identity rather than existing as isolated network events.

Endpoint Telemetry

The endpoint provides another critical source of evidence. A device can transition from healthy to suspicious during an active session, changing the risk associated with requests generated by that device.

Endpoint security alerts, device-management state and posture information can therefore influence access policy. This creates a feedback loop between the endpoint security layer and the SASE enforcement layer.

DNS and Network Behaviour

DNS and network telemetry provide visibility into where devices are attempting to communicate and how those communication patterns change over time.

A single connection may not appear particularly suspicious. A sequence involving unusual DNS queries, new destinations, unexpected application protocols and abnormal traffic volumes may provide much stronger evidence of compromise.

This is why behavioural analysis generally benefits from correlating multiple signals rather than relying on one isolated event.

SIEM and Security Analytics

A Security Information and Event Management (SIEM) platform can aggregate and correlate telemetry from identity systems, endpoints, network controls, cloud applications and SASE services.

The value of centralised analytics is not simply storing more logs. The objective is to identify relationships between events that would otherwise be difficult to see.

Signal Individual Meaning Correlated Meaning
Login Identity authenticated successfully. Potentially normal, depending on context and subsequent activity.
MFA Event Authentication factor was challenged or completed. Repeated unexpected challenges may indicate credential abuse or attack activity.
DNS Device queried an unusual domain. More significant when combined with endpoint or identity anomalies.
Application User accessed a resource. Potentially suspicious when the resource is unusual for that identity or follows other risk events.
Endpoint Security control detected suspicious activity. Can justify changing the access decision for sessions originating from the device.

Behavioural Analytics

Behavioural analytics attempts to identify deviations from expected activity. The objective is not to define one permanent baseline for every user, but to understand patterns sufficiently well to identify meaningful anomalies.

Examples include unusual access times, unexpected applications, unfamiliar destinations, abnormal data volumes, repeated authentication failures or access to resources that are inconsistent with normal activity.

Behavioural signals should contribute to risk evaluation rather than automatically becoming proof of compromise. An unusual event can have legitimate explanations, which is why correlation and investigation remain important.

Compromised Identity Detection

One of the most important SASE security scenarios is the compromised identity. An attacker may possess valid credentials, meaning traditional authentication alone may not detect the attack.

Detection therefore depends on identifying changes in behaviour and correlating evidence across multiple systems.

Example Investigation Timeline
USER LOGIN → NEW DEVICE → SUSPICIOUS DNS → UNUSUAL APP → RISK ↑ → PRIVATE APP → CONTAIN

Lateral Movement

Compromised credentials become particularly dangerous when they provide broad access to internal applications and infrastructure. If access controls are based primarily on network location, an attacker who obtains a valid foothold may be able to discover and reach many additional resources.

Identity-aware application access and microsegmentation reduce this exposure by limiting which resources the identity can reach. The goal is not simply to detect lateral movement after it happens, but to reduce the available movement paths in the first place.

Threat Hunting

Threat hunting uses available telemetry to search proactively for suspicious patterns rather than waiting for a single security alert to trigger an investigation.

In a SASE environment, useful hunting questions might include:

HUNT 01
Which identities changed behaviour?

Identify users whose application access, authentication or destination patterns differ significantly from their normal activity.

HUNT 02
Which devices became risky?

Correlate endpoint alerts and posture changes with active SASE sessions and access requests.

HUNT 03
Which destinations are unusual?

Investigate new domains, unexpected applications and abnormal network destinations.

HUNT 04
Which policies are being challenged?

Look for repeated denies, step-up requests and unusual attempts to reach protected applications or data.

Response and Containment

Detection is only useful if the organisation can respond. SASE and Zero Trust architectures can provide multiple enforcement points where a response can be applied.

Response Purpose Example Trigger
Monitor Increase observation without immediately interrupting access. Low-confidence anomaly.
Step-Up Require stronger authentication before continuing. Elevated identity or contextual risk.
Restrict Reduce available resources or actions. Suspicious session with insufficient evidence for full denial.
Revoke Terminate sessions or invalidate tokens. Strong evidence of identity compromise.
Isolate Limit communication from a compromised endpoint. Endpoint security confirms active compromise.

SOAR and Automated Response

Security Orchestration, Automation and Response (SOAR) can connect detection events to predefined response workflows. Automation is particularly useful when the response is well understood and the confidence level is high.

For example, a confirmed compromised identity might trigger token revocation, session termination, privileged-access removal and an incident-management workflow.

Automation should nevertheless be designed carefully. Aggressive automated responses based on weak signals can create operational disruption, lock out legitimate users or hide the original investigation context.

Performance Visibility Is Also Security Visibility

SASE operations are not limited to security events. Network performance can directly influence the user experience and the effectiveness of distributed enforcement.

Latency, packet loss, application response time and path changes can help engineers determine whether a problem originates from the endpoint, local network, Internet path, SASE enforcement point, cloud provider or application.

This is where network-observability capabilities can complement security telemetry. Security and performance teams need enough shared evidence to distinguish a security event from an ordinary application or connectivity problem.

Policy Maintenance

A mature SASE architecture is not finished when the initial policy is deployed. Applications change, users change roles, new threats appear, cloud services are introduced and network conditions evolve.

Policies therefore require continuous review. Security teams should understand which rules are frequently triggered, which rules are never used, where exceptions have accumulated and whether the original business requirement still exists.

Operational Principle

The goal is not to create the largest possible policy set. The goal is to create policies that are understandable, measurable, enforceable and aligned with current business requirements.

The Complete SASE Security Loop

The four sections of this guide can now be connected into a single engineering model.

End-to-End SASE Security Model
CONNECT → IDENTIFY → EVALUATE → ENFORCE → OBSERVE → DETECT → RESPOND

This is the real engineering value of the SASE model. Connectivity, identity, policy enforcement and security operations are no longer isolated layers. They form a continuous control loop in which telemetry can influence future access decisions and enforcement.

What SASE Changes Operationally

Traditional Model SASE-Oriented Model
Security events are often tied to individual appliances. Telemetry is correlated across identity, endpoint, network and cloud controls.
Network location strongly influences security assumptions. Identity, context and risk influence access decisions.
Incident response often begins after a major alert. Continuous telemetry supports earlier detection and investigation.
Segmentation primarily uses network boundaries. Identity and application-level controls can reduce reachable resources.
Security policy is frequently tied to physical infrastructure. Policy can be distributed across cloud-delivered enforcement points.

Engineering the SASE Operating Model

A successful SASE deployment therefore requires more than selecting networking and security products. The organisation must define how identity, device posture, policy, telemetry and response interact across the entire architecture.

Engineers need to understand not only whether a request was allowed or denied, but why the decision was made, which signals influenced it, which security services processed the request and what happened afterwards.

That is what turns SASE from a collection of cloud security services into an operational security architecture.

Section 04 Engineering Takeaway

SASE becomes operationally powerful when identity, endpoint, DNS, network, application and policy telemetry are correlated into a continuous detection and response loop. The architecture should not only enforce access; it should explain decisions, detect changing risk and provide mechanisms to contain compromised identities, devices and sessions.

Engineering Lab · Section 04

SASE Incident Investigation

Correlate identity, device, DNS, application and access telemetry to determine whether a session has become suspicious. Investigate the evidence chain, then select the response that best contains the incident.

INCIDENT INVESTIGATION ACTIVE
Correlated Evidence Chain
SECURITY TELEMETRY
01
User Authentication
Successful identity authentication observed.
OBSERVED
02
Unusual Device
Session originates from an unfamiliar device posture.
WAITING
03
Suspicious DNS Request
DNS telemetry identifies a destination associated with elevated risk.
WAITING
04
Abnormal Application Access
Application behaviour differs from the user's normal baseline.
WAITING
05
Elevated Risk
Correlated signals increase the session risk score.
WAITING
06
Private Application Attempt
Session attempts to reach a protected private application.
WAITING
07
Policy Violation
Access request conflicts with the current security policy.
WAITING
08
Containment Required
Response action is required to prevent further access.
WAITING
Incident State
LIVE ANALYSIS
Current Threat Level
ELEVATED
Initial evidence requires additional investigation.
Telemetry Correlation
SIGNALS
1 Identity
0 Device
0 DNS
0 Application
LOW Risk
0 Policy
Response Decision
SOC ACTION
Investigate the evidence chain before selecting a containment action.
Security Event Stream
LIVE TELEMETRY
00:00:00
Incident investigation initialised.
READY

Engineering Readout

A single authentication event does not prove compromise. SASE operations correlate identity, device, DNS, application and policy telemetry to determine whether behaviour has become suspicious.

Engineering Challenge

Investigate the complete evidence chain. When multiple independent signals indicate compromise, which response prevents the session from continuing to access protected resources?

```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
rsz_1te_agents

SASE Visibility with Cisco ThousandEyes

Network Insight · Engineering Guide
SASE Visibility with Cisco ThousandEyes: From User Experience to Network Path

Secure access does not automatically mean observable access. In a SASE architecture, a user's traffic can cross the endpoint, local network, Internet, SASE service edge, cloud provider and application before the final transaction completes. When performance degrades, the challenge is identifying which part of that path is responsible.

01
Endpoint User experience
02
Local Access LAN / Wi-Fi
03
Internet Underlay path
04
SASE PoP Security edge
05
Cloud / SaaS Service path
06
Application Transaction
Observe

See the complete path

Measure more than the security policy. Observe latency, packet loss, DNS behaviour, routing changes and application response across the complete user-to-service path.

Localize

Find where the problem begins

Compare evidence from different vantage points to separate endpoint, access-network, Internet, SASE and cloud conditions.

Explain

Turn telemetry into a diagnosis

Correlate network-path evidence with application and service dependencies so an incident can move from symptom to probable cause.

The engineering question: When a SASE-connected application becomes slow, can you prove which dependency changed — and where in the path the degradation started?
Engineering Guide
Explore the SASE Visibility Path

Four engineering sections take the investigation from end-to-end visibility through vantage points, troubleshooting and operational correlation.

4 Sections
SASE VISIBILITY WITH CISCO THOUSANDEYES

See the complete path from user to application

SASE secures access, but visibility must extend beyond the security policy itself. ThousandEyes adds digital experience and network-path visibility across the endpoint, local network, Internet, SASE infrastructure, cloud services and applications.

End-to-End SASE Visibility
U
User / Device
Endpoint, Wi-Fi, device and user experience
→
A
Local Access
LAN, Wi-Fi, gateway and local connectivity
→
I
ISP / Internet
Internet path, latency, loss and routing
→
S
SASE PoP
Secure Access, policy and cloud security services
→
C
Cloud / SaaS
Cloud provider, SaaS service and Internet path
→
A
Application
Application response and user transaction
Visibility Across The Path
Latency
Packet Loss
Jitter
DNS
Network Path
Application Response
User Experience
Visibility Layer

User / Device

The endpoint is where the digital experience begins. Local conditions such as Wi-Fi quality, device performance and the user's connection can influence application performance.

What can we investigate?
Is the problem occurring on the endpoint or local access network?
Why it matters
A slow application does not automatically mean the application or SASE service is responsible.
Engineering principle: Follow the evidence across the complete delivery path. Start with the user experience, then isolate the layer where the degradation actually appears.
SASE
Provides cloud-delivered security and access controls for users, devices and applications.
ThousandEyes
Provides visibility into network paths, digital experience and application performance across owned and unowned infrastructure.
Combined View
Security policy explains what access was permitted; observability helps explain how that access actually performed.
01 · SASE Visibility / Evidence Layer
See the Complete Delivery Path
SASE does not remove the network path. It distributes it. Follow the user experience across every layer before deciding where the problem lives.
U
User Experience
→
L
LAN / Wi-Fi Local access
→
I
ISP Internet path
→
S
SASE PoP Secure edge
→
C
Cloud Provider path
→
A
Application Response
Selected layer · User Start with the actual user experience. A slow application is a symptom, not yet a root cause.

SASE Visibility: Building the End-to-End Evidence Path

SASE changes the way enterprise traffic moves through the network. Instead of sending every application flow through a traditional central security stack, users may connect through a combination of local access, Internet connectivity, SD-WAN, security service edges, cloud platforms and SaaS providers.

This architecture provides greater flexibility, but it also changes the visibility problem. A user experiencing a slow application does not necessarily have a problem with the application itself. The degradation could have started on the endpoint, across Wi-Fi, at the local gateway, somewhere in the Internet path, at a SASE point of presence or within a cloud service dependency.

The key engineering principle: SASE visibility should follow the complete transaction path rather than stopping at the security boundary.

From security policy to user experience

Traditional security monitoring often concentrates on whether traffic was permitted, denied or inspected correctly. Those are important control-plane questions, but they do not answer whether the user actually received a good application experience.

An application request can be successfully authorised and inspected while still experiencing high latency, packet loss, DNS delays or inefficient routing. Consequently, operational visibility needs to connect security decisions with the underlying network and application path.

Endpoint

User and device experience

Measure the starting point of the transaction, including endpoint connectivity, local access conditions and the experience observed by the user.

Network

Path performance

Examine latency, packet loss, routing changes and path transitions between the user, Internet and SASE service edge.

SASE

Service-edge behaviour

Establish whether the selected SASE point of presence and security service are introducing delay or whether the service itself remains healthy.

Application

Transaction performance

Correlate network evidence with DNS, HTTP response and application behaviour to determine whether the destination service is actually responsible.

What should be measured?

Effective SASE observability requires multiple forms of telemetry rather than a single health indicator. Network-path measurements can reveal where latency or loss begins, while application tests can determine whether the same condition is affecting the transaction itself.

Core evidence to correlate

  • Endpoint and local-network conditions
  • DNS resolution and dependency behaviour
  • Latency, packet loss and jitter
  • Internet routing and path changes
  • SASE PoP reachability and service health
  • Cloud and SaaS connectivity
  • HTTP and application response time

Why end-to-end visibility matters

The objective is not to create another dashboard containing more metrics. The objective is to build an evidence chain that allows an engineer to move from symptom to location and then from location to probable cause.

Engineering takeaway: The more distributed the SASE architecture becomes, the more important it is to observe the complete path from the user's device to the application. Visibility must cross organisational and infrastructure boundaries rather than ending at the enterprise edge.

SASE Visibility / Path Explorer
Follow the User-to-Application Evidence Path
Select a layer to see what an engineer should observe there and how that evidence contributes to the end-to-end diagnosis.
Select a layer
Live Evidence Path
0 / 6
01
Endpoint Device / user
02
Local Access LAN / Wi-Fi
03
Internet Underlay
04
SASE PoP Security edge
05
Cloud / SaaS Service path
06
Application Transaction
Current observation
Start the trace
Step through the path to see which evidence belongs to each layer of the SASE transaction.
Latency —
Loss —
Evidence —
Engineering Lens
What to ask
Endpoint Is the user actually connected normally?
Network Where does latency or loss first increase?
SASE Is the selected service edge healthy?
Cloud Is the destination path behaving normally?
Application Does application response correlate with the path?
Live Interpretation
End-to-end visibility begins at the user. Select a node or use Trace Next.
Engineering Principle
A SASE dashboard can show service health while the user's actual path is degraded. Always correlate service telemetry with the transaction path.
02 · Observability / Vantage Points
One Problem. Multiple Observation Points.
Different vantage points expose different parts of the delivery path. Select an agent to see what evidence it contributes.
EA · Endpoint
Endpoint Agent User experience
EN · Enterprise
Enterprise Agent Site visibility
CA · Cloud
Cloud Agent Cloud / Internet
Endpoint Agent

Measures evidence close to the user: endpoint health, Wi-Fi, local access, VPN paths and application experience.

Where does the degradation appear?

Compare measurements from different locations before assigning the fault domain.

SASE VISIBILITY • THOUSANDEYES

ThousandEyes Vantage Point Explorer

The same application problem can look completely different depending on where you measure it. Select a vantage point to see what evidence it contributes to the investigation.

EA
Endpoint Agent
Measures the experience close to the user, including endpoint and local access conditions and the path toward the service.
USER EXPERIENCE
EN
Enterprise Agent
Provides a controlled observation point from a branch, office, data-center or other enterprise location.
SITE VISIBILITY
CA
Cloud Agent
Provides cloud-based observation points that help compare paths, application reachability and service performance from different locations.
CLOUD / INTERNET
OBSERVATION PATH
User
→
LAN / Wi-Fi
→
ISP
→
SASE PoP
→
Cloud
→
SaaS / App
Visibility emphasis
Endpoint
Local Network
Internet Path
Application
SELECTED VANTAGE POINT
ENDPOINT EXPERIENCE
Endpoint Agent
An endpoint vantage point helps answer whether the problem is visible from the user's actual access path rather than only from a central monitoring location.
Investigation question: Is the degradation already visible between the user and the network, or does it appear farther along the path?
WHAT DIFFERENT VANTAGE POINTS CAN TELL YOU
Observation
Endpoint
Enterprise
Cloud
User / Endpoint Experience
✓
~
—
Local Network / Site
✓
✓
—
Internet / ISP Path
✓
✓
✓
Cloud / SaaS Reachability
✓
✓
✓
Compare Different Locations
~
✓
✓
Engineering principle: no single vantage point tells the whole story. Comparing measurements from multiple locations helps separate endpoint, access-network, Internet-path, SASE-path and application-service problems.

ThousandEyes Vantage Points: Seeing the Path from Multiple Locations

End-to-end SASE visibility becomes much more useful when measurements can be taken from different points in the network. A single test tells you what one observer experienced. Multiple vantage points allow you to compare those experiences and determine where the difference begins.

This is particularly important for SASE environments because the user does not simply connect directly to an application. Traffic may pass through the endpoint, local access network, ISP, Internet transit, security service edge, cloud provider and finally the application itself.

Endpoint Agents: Measuring the User Experience

An Endpoint Agent provides the closest view to the actual user experience. It can help expose problems affecting the device, Wi-Fi or local network before traffic even reaches the wider Internet.

This makes endpoint visibility valuable when users report that an application is slow, unreliable or intermittently unreachable. The measurement begins where the problem is being experienced rather than somewhere deeper in the network.

Enterprise Agents: Establishing a Controlled Baseline

Enterprise Agents provide a controlled observation point within a branch, office, data centre or other managed location. They are useful for establishing a repeatable baseline for connectivity and application reachability.

Comparing an Enterprise Agent with an Endpoint Agent can help distinguish a local user problem from a wider network condition. If the enterprise baseline remains healthy while endpoint measurements degrade, attention can move towards the local access environment.

Cloud Agents: Seeing the Internet from Outside the User Network

Cloud Agents provide another perspective by measuring connectivity from externally hosted locations. They cannot see the user's Wi-Fi or local network, but they can provide independent evidence about Internet, provider and SaaS reachability.

This external perspective is particularly useful when investigating whether an apparent SASE or application problem is actually broader than the affected user location.

Why Multiple Vantage Points Matter

The real value comes from comparing the measurements rather than treating any individual vantage point as the complete picture.

Endpoint Agent User experience · Wi-Fi · LAN · path
Enterprise Agent Branch baseline · controlled path · application reachability
Cloud Agent Internet perspective · SaaS reachability · comparative evidence

When measurements from these locations agree, confidence in the observed condition increases. When they disagree, that difference becomes useful evidence in itself. It can help narrow the investigation to the local access network, Internet path, SASE service edge or application dependency.

Engineering principle: A vantage point is not simply a place from which to run a test. It defines which part of the service path you can observe and therefore which hypotheses you can confidently eliminate.
ENGINEERING EVIDENCE · VANTAGE POINT LAB
ThousandEyes Vantage Point Investigation
Run the same SASE path investigation from different observation points. Change the vantage point, execute the probe, compare telemetry and determine which part of the path the evidence can actually prove.
READY · SELECT A VANTAGE
Live observation path
Latency —
Packet Loss —
DNS —
HTTP Response —
Observation point
What can this prove?
Vantage point comparison
Evidence Endpoint Enterprise Cloud
Local Wi-Fi / LAN Direct Branch Not visible
ISP path Direct Direct Comparative
SASE PoP Visible Visible Visible
User experience Direct Baseline Indirect
SaaS reachability Direct Direct Direct
Investigation timeline
Live engineering readout
Select a vantage point and run the test. The important question is not simply whether the path is reachable — it is which observation point gives you enough evidence to localize the problem.
0 / 6 evidence stages Confidence: —
Engineering takeaway: multiple vantage points turn a single path view into comparative evidence.
03 · Incident Investigation / Root Cause
Where Is the Performance Problem?
A user reports that Microsoft 365 is slow. Do not guess. Walk the evidence through the delivery path and identify where the degradation begins.
Performance incident Users in one location report increased application response time. The application is reachable, but transactions are slow.
01 Endpoint Wi-Fi / device
→
02 LAN Gateway / access
→
03 ISP Internet path
→
04 SASE PoP Secure edge
→
05 Cloud / App Response
Start close to the user

Check Wi-Fi quality, device conditions and local connectivity. If the endpoint is unhealthy, investigate locally before moving toward the SASE service.

SASE VISIBILITY • TROUBLESHOOTING

Where is the performance problem?

A user reports that a cloud application is slow. Instead of immediately blaming the network, investigate the complete delivery path and use evidence to isolate the failing layer.

Incident Investigation
Performance Incident
Users in one location report that Microsoft 365 is responding slowly. HTTP response time has increased. The first question is not "Is the network down?" — it is "Where does the degradation appear?"
Follow the Evidence
U
Endpoint
Wi-Fi
Device health
→
L
LAN / Gateway
Loss
Retransmits
→
I
ISP / Internet
Latency
Path changes
→
S
SASE PoP
Secure path
Service edge
→
C
Internet / Cloud
Routing
Provider path
→
A
Microsoft 365
HTTP response
Availability
Investigation

Start With The User Experience

Begin with the observed symptom. A high HTTP response time tells you that the user experience is degraded, but it does not yet identify the root cause.

Evidence
HTTP response time is elevated for users in one location.
Next question
Is the degradation visible at the endpoint, in the network path, or only at the application?
Investigation principle
Correlate measurements from multiple vantage points before assigning root cause.
Endpoint Evidence
Wi-Fi quality, device conditions and local connectivity can explain why an individual user experiences degradation.
Path Evidence
Latency, packet loss, routing changes and hop-by-hop measurements help isolate transport problems.
Application Evidence
Application response time and transaction behaviour help distinguish application problems from network problems.

Troubleshooting SASE Performance: Follow the Evidence

The value of end-to-end visibility becomes most obvious during an incident. Instead of beginning with assumptions about the SASE platform, ISP or application provider, an engineer can work through the evidence in the same order that the transaction travels through the environment.

Investigation Scenario Microsoft 365 is slow for users in one location.

Users report increased page-load time and application response latency. The first objective is not to identify the culprit immediately, but to determine where the evidence begins to diverge from the normal baseline.

Start with the user experience

An application complaint is the symptom, not necessarily the root cause. Begin by establishing exactly what has changed. Is the problem affecting every user, a particular office, a specific network, a region or only a subset of devices?

This initial scope is important because it immediately changes the investigation. A global application failure should produce a different evidence pattern from a local access-network problem affecting only one office.

Move down the path

01 · ENDPOINT
Check local health

Establish whether the endpoint and local access environment are behaving normally.

02 · NETWORK
Inspect the path

Look for increased latency, packet loss, routing changes or path instability.

03 · SASE
Validate the service edge

Determine whether the selected SASE PoP and security service show corresponding degradation.

04 · APPLICATION
Validate the destination

Compare application and HTTP response with network-path evidence.

Separate path problems from application problems

One of the most useful troubleshooting techniques is correlation. If application response time increases at the same time that network latency increases along a particular path, there is evidence of a network-side contribution.

Conversely, if the network path remains stable while application response time increases, attention should move toward the destination service, application infrastructure or one of its dependencies.

Healthy network path

Latency and loss remain close to baseline, routing is stable and the SASE service edge is responding normally. Investigate application or service dependencies.

Changed network path

Latency or loss increases after a path transition or routing change. Investigate the affected provider, transit segment or Internet route.

Where SPAN and sFlow fit

Traditional network telemetry remains valuable. SPAN can provide packet visibility for a local segment, while sFlow and related telemetry can provide traffic-level information from network infrastructure.

These technologies should be treated as complementary evidence rather than replacements for end-to-end observability. A packet capture may explain what happened on one network segment, but it cannot by itself establish the complete user-to-SaaS path across multiple providers and service boundaries.

Build the investigation around evidence

The strongest troubleshooting process continually asks what the current evidence proves and what it does not prove. This prevents engineers from prematurely blaming the SASE platform simply because the incident was observed through a SASE-connected user.

Engineering takeaway: Troubleshooting should follow the transaction path. Start with the observed user experience, compare vantage points, inspect the network path, validate the SASE service edge and then confirm the application response. Each step should narrow the possible failure domain.

ENGINEERING EVIDENCE · INCIDENT INVESTIGATION
SASE Performance Investigation Lab
A user reports that Microsoft 365 is slow from Dublin. Investigate the complete service path, collect evidence at each layer and determine where the performance degradation actually begins.
INCIDENT OPEN · NO EVIDENCE
!
INCIDENT: Microsoft 365 is slow for Dublin users Reported symptom: increased HTTP response time. The root cause has not yet been established.
Live service path
HTTP Response
—
End-to-End Latency
—
Packet Loss
—
DNS Response
—
Fault injection
Evidence collected
Investigation timeline
Investigator readout
Begin the investigation. Do not assume that the reported application symptom identifies the failing layer.
0 / 7 evidence stages Confidence: Low
Engineering principle: investigate from the user experience backwards through the dependency chain. A slow application does not automatically mean the application is the cause.
04 · SASE Observability / Engineering Control Loop
Measure. Compare. Isolate. Validate. Resolve.
Effective observability is a continuous engineering process. Collect measurements, compare them against expected behaviour, isolate the failing layer, validate the hypothesis and then restore the user experience.
01
Measure Collect evidence
02
Compare Find deviation
03
Isolate Locate problem
04
Validate Confirm cause
05
Resolve Restore service
Measure

Collect network, endpoint, application and service measurements from the relevant observation points.

Visibility becomes part of SASE

Secure access is only successful when users can reliably reach the applications they depend on.

Engineering principle: Observability should reduce uncertainty at every step — not simply produce more dashboards.

SASE Operations: Correlating Network, Application and Service Dependencies

SASE should be operated as a distributed service rather than as an isolated security platform. User experience depends on multiple interconnected components, including identity, connectivity, security policy, DNS, service edges, cloud infrastructure and SaaS applications.

This means that operational visibility must extend beyond individual devices and dashboards. Engineers need to understand the dependencies that make secure application access possible and continuously validate whether those dependencies are behaving as expected.

Secure access is only part of the objective. Enterprise users also need predictable, measurable and explainable access to the applications they depend on.

The SASE service dependency chain

Identity Authentication and user context establish access.
SD-WAN Connectivity determines the available transport path.
ISP Internet performance influences the underlay.
SASE PoP The security edge processes and forwards traffic.
DNS Name resolution can influence application reachability.
Cloud Cloud infrastructure introduces additional dependencies.
SaaS External services may use distributed delivery networks.
Application The final transaction determines user experience.

Build an operational control loop

Measure
Correlate
Localize
Validate
Remediate
Verify

Monitoring becomes much more useful when it forms a continuous operational loop. Measurements identify change, correlation connects related signals, localization narrows the failure domain and validation confirms the suspected cause before remediation is applied.

After a change is made, the same measurements should be used to verify that the user experience actually improved. Otherwise, an incident may simply move from one component to another without being resolved.

Underlay and overlay must be correlated

Underlay visibility

Observe the physical and Internet transport supporting the SASE architecture. Latency, packet loss, routing changes and provider behaviour can explain why an otherwise healthy overlay is performing poorly.

Overlay visibility

Observe the logical service path created by SD-WAN, security policies, SASE inspection and application access decisions. The overlay can change even when the physical network remains healthy.

From dashboards to dependency-aware operations

A large collection of independent monitoring dashboards can still leave engineers searching for the relationship between signals. A better approach is to connect measurements to the services and dependencies they represent.

For example, increased Microsoft 365 response time should be correlated with DNS performance, Internet path changes, SASE PoP behaviour and endpoint experience. If all users using one Internet provider show the same path degradation while users on another provider remain healthy, the evidence becomes significantly more actionable.

What good SASE observability looks like

Mature SASE operations should allow an engineer to answer five questions quickly:

Who is affected?

Identify the users, locations, applications and services experiencing the degradation.

Where does it begin?

Determine the first point in the transaction path where performance diverges from the expected baseline.

What changed?

Correlate the degradation with routing, provider, policy, service or application changes.

Did remediation work?

Re-measure the same path after remediation and verify that the actual user experience recovered.

Engineering takeaway: SASE observability is most valuable when it connects user experience, network telemetry, security services and application dependencies into a single investigation model. The goal is not simply to see more data. It is to reduce the time required to explain what changed and why.

ENGINEERING OPERATIONS · SERVICE CORRELATION
SASE Dependency & Observability Control Loop
SASE is not a single service. Investigate how identity, SD-WAN, ISP connectivity, the SASE PoP, DNS, cloud services and applications interact — then correlate the evidence before deciding where remediation belongs.
OBSERVABILITY ACTIVE
!
OPERATIONAL EVENT · Secure access degradation Users can authenticate, but application performance has degraded. Determine which dependency is responsible and verify the service after remediation.
Observability control loop
SASE service dependency map
Dependency health
Correlated evidence
Operational timeline
Engineering readout
Start by measuring the service rather than assuming which dependency is responsible.
0 / 6 control stages Confidence: Low
Engineering principle: secure access is only operationally useful when the underlying service path is measurable, correlated and verifiable.
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
WAN Security

SD WAN Security

Network Insight · Engineering Guide

SD-WAN Security: From Secure Connectivity to Adaptive WAN Enforcement

SD-WAN changes the way enterprise networks connect branches, users, cloud services and applications. Instead of relying on a fixed private WAN and a central security perimeter, modern SD-WAN architectures can use multiple transports, encrypted overlays, application-aware routing, distributed Internet access and cloud-delivered security services.

This flexibility changes the security problem. Protecting the WAN is no longer simply about encrypting a tunnel or placing a firewall at the edge. The SD-WAN fabric itself must be secured, devices and controllers must be authenticated, traffic must be segmented, access must be policy-driven and application flows must be inspected according to their identity, destination, risk and security context.

Engineering Question
How do we build an SD-WAN that remains connected and resilient while ensuring that every device, identity, application and traffic flow receives the appropriate security controls?
CONNECT
›
PROTECT
›
ENFORCE
›
DETECT
What This Guide Examines

We will examine SD-WAN security as an end-to-end engineering system: protecting the control and management planes, securing the encrypted overlay, applying identity and segmentation policy, inspecting Internet-bound traffic, and using telemetry to detect suspicious behaviour and respond to incidents.

Core Engineering Model

Secure the fabric first, control who and what can communicate, inspect the traffic according to its context, and continuously observe the resulting behaviour.

Engineering Progression
01 · FABRIC Secure the architecture
02 · POLICY Control access
03 · ENFORCEMENT Inspect the flow
04 · OPERATIONS Detect & respond

SD-WAN Architecture & Secure Fabric

Section 01 · Architecture

SD-WAN Architecture & the Secure Fabric

Before securing application traffic, the SD-WAN fabric itself must be trusted. This section examines the control plane, management plane, data plane, device identity, encrypted overlays, segmentation and the mechanisms that allow distributed WAN components to participate securely in the fabric.

BRANCH
›
SD-WAN EDGE
›
CONTROL PLANE
›
SECURE OVERLAY
Engineering Question
How do we ensure that only trusted devices and authorised control-plane components can participate in the SD-WAN fabric?
Explore Secure Fabric →

SD-WAN changes the WAN from a collection of relatively static connections into a software-controlled connectivity fabric. Multiple transports can be combined, application traffic can be steered according to policy and performance, and network behaviour can be coordinated from central management systems. That flexibility creates a different security problem: the organisation must secure not only the traffic crossing the WAN, but also the components that create, control and operate the fabric.

A secure SD-WAN therefore begins with the architecture itself. Before considering firewalls, DNS security or Internet inspection, the organisation must establish whether a device is trusted, whether its control-plane relationships are legitimate, whether management access is protected, and whether the resulting overlay can be relied upon to carry authorised traffic.

Engineering Principle

Secure the fabric before securing the flow. If an unauthorised device, compromised controller or poorly protected management interface can influence the fabric, downstream security controls may be operating on an untrusted foundation.

Why SD-WAN Changes the Security Model

Traditional WAN security often centred on fixed sites, known circuits, perimeter firewalls and relatively predictable traffic paths. SD-WAN introduces more variables. A branch may have broadband, MPLS, 5G or other transports. The preferred path for an application can change according to latency, loss, jitter, policy or availability. Internet traffic may break out locally rather than returning to a central data centre. Security functions may be integrated into the WAN edge, delivered from the cloud, or distributed across both.

The result is that security can no longer be treated as a single appliance positioned at the edge of the network. Security must be considered across the management plane, control plane and data plane, with clear trust relationships between them.

Management Plane

Controls administration, configuration, policy, software lifecycle, identity, RBAC and operational access to the SD-WAN environment.

Control Plane

Establishes the relationships and routing/policy information that allow SD-WAN devices to understand the overlay and make forwarding decisions.

Data Plane

Carries production traffic across the WAN using secure tunnels, segmentation and forwarding policies established by the control architecture.

These planes are related but should not be treated as interchangeable. A secure data-plane tunnel does not compensate for weak administrator authentication. Strong controller authentication does not automatically protect application traffic. Likewise, an encrypted overlay does not prevent a compromised endpoint from generating malicious traffic.

The SD-WAN Secure Fabric

At the architectural level, an SD-WAN fabric consists of WAN edges, management systems, control-plane components and the underlying transport networks that connect them. The exact architecture varies by platform, but the security objectives remain broadly consistent.

A new WAN edge should not simply become a trusted member of the fabric because it can reach a controller. The platform should establish device identity, validate the device's credentials or certificates, apply an onboarding policy and create only the control-plane relationships that the design permits.

This is particularly important in distributed environments. Branches may be deployed remotely, equipment may be replaced without an engineer physically visiting the site, and multiple transport networks may be available. Automated provisioning improves operational efficiency, but it also makes secure identity and onboarding fundamental architectural requirements.

01 Device Identity
02 Authentication
03 Control Plane
04 Policy & Routes
05 Secure Overlay
Device Identity and Secure Onboarding

Device identity is one of the first security boundaries in an SD-WAN deployment. The organisation needs a reliable mechanism for determining whether a device is an approved WAN edge and whether it is permitted to establish relationships with the management and control infrastructure.

Certificate-based identity is commonly used in modern SD-WAN implementations, although the exact mechanism varies by vendor and deployment model. The important engineering principle is that identity should be cryptographically bound to the device and validated before it becomes a trusted participant in the fabric.

Secure onboarding should therefore address device registration, credential or certificate validation, authorised inventory, configuration assignment and lifecycle management. Decommissioned or compromised devices must also be capable of being removed from the trust model.

Control-Plane Protection

The control plane determines how the SD-WAN fabric understands reachability, policy and available paths. Compromise of this layer could therefore have consequences beyond a single device. An attacker capable of manipulating control information may influence where traffic is sent or which routes are considered available.

Control-plane protection should include authenticated relationships between participating components, protected management interfaces, appropriate cryptographic mechanisms and strict control over which devices are allowed to participate.

Operational monitoring is also important. A sudden change in controller relationships, unexpected peer formation or repeated authentication failures may indicate an attempt to interfere with the fabric rather than simply a normal routing event.

Management-Plane Security

The management plane deserves particular attention because it can provide centralised access to configuration and policy. A compromised management account may be more dangerous than the compromise of an individual branch device because the attacker could potentially change policy across many locations.

Management security should therefore include strong administrator authentication, multi-factor authentication where supported, role-based access control, protected management interfaces, logging and controlled administrative workflows. Privileged access should follow least-privilege principles rather than giving every operator unrestricted control of the entire fabric.

Strong Administrator Identity Use strong authentication and appropriate MFA for privileged management access.
Role-Based Access Separate operational responsibilities so users receive only the permissions required for their role.
Configuration Control Track policy changes, configuration versions and administrative activity.
Management Isolation Restrict management access paths and avoid exposing administrative interfaces unnecessarily.

Encrypted Overlay Connectivity

Once the participating devices and control relationships are trusted, the next requirement is protecting the data plane. SD-WAN commonly creates logical overlay connectivity across one or more underlying transports. The transport itself may be private, public or a combination of both.

Encryption protects data while it is travelling between participating endpoints. IPsec is widely used for secure WAN tunnels, but the precise tunnel and control mechanisms depend on the SD-WAN implementation. The architectural principle is more important than assuming every platform operates identically: traffic crossing an untrusted or shared transport should receive appropriate cryptographic protection.

Encryption, however, should not be confused with complete traffic security. Encrypted traffic can still originate from a compromised endpoint, violate a segmentation policy or contain malicious activity. Encryption protects the confidentiality and integrity of the transport; it does not establish that the application or user generating the traffic is trustworthy.

Important Distinction

Encryption protects the path. Policy protects the communication. A secure tunnel can carry traffic safely across the transport network while still carrying traffic that should have been blocked, restricted or inspected.

Transport Independence and Security

One of the strengths of SD-WAN is the ability to abstract the underlying WAN transports. An organisation may use MPLS, broadband, fibre, LTE, 5G or other connectivity options according to location and business requirements.

This should not be interpreted as “SD-WAN replaces MPLS with the Internet.” SD-WAN is better understood as a software-controlled architecture that can use multiple transports and make policy-driven decisions about how traffic uses them.

Security must therefore remain independent of the assumption that a particular transport is inherently trusted. A private circuit may reduce exposure to some threats, while a public Internet connection introduces a different risk profile, but neither transport should automatically be treated as a substitute for end-to-end security controls.

Application-Aware Connectivity

SD-WAN can evaluate application and path characteristics when determining how traffic should be forwarded. For example, an organisation may prefer a low-loss path for voice, select a high-bandwidth path for business applications, or move traffic away from a degraded transport.

Security policy can interact with these decisions. A sensitive application may require a particular segmentation boundary, a trusted path, inspection or additional controls. A guest application may be permitted to use direct Internet access while remaining isolated from corporate resources.

The important distinction is that path selection and security policy are related but not identical. Path selection answers where traffic should travel. Security policy answers whether the traffic is permitted and what controls should apply to it.

Segmentation as a Security Boundary

Segmentation provides another foundational security mechanism. SD-WAN platforms commonly support logical separation of traffic using constructs such as VPNs, VRFs or vendor-specific segmentation mechanisms.

The objective is not simply to create multiple routing tables. Segmentation should establish meaningful security boundaries between traffic classes that have different trust requirements.

Examples might include corporate users, guest devices, operational technology, payment systems, voice, management traffic and Internet-only services. Each segment can then have its own routing, security and access policy.

Effective segmentation also requires careful consideration of the points where traffic is allowed to cross between segments. If every segment can freely communicate through a central firewall or shared service, the segmentation boundary may provide less security value than expected.

Vendor Example

Cisco SD-WAN provides examples of vendor-specific constructs such as OMP and TLOCs. These terms should not be treated as generic SD-WAN terminology. OMP is Cisco's overlay control/routing protocol, while TLOCs represent Cisco-specific transport-location constructs used in its SD-WAN architecture. Other platforms use different architectures and terminology.

The Role of Zero Trust

SD-WAN can support Zero Trust architectures, but SD-WAN itself should not automatically be described as Zero Trust. Zero Trust is a broader security approach based on continuously evaluating identity, device context, resource access and policy rather than assuming that network location creates trust.

An SD-WAN environment can contribute to this model by providing segmentation, identity-aware policy integration, application visibility and controlled connectivity. Additional identity, endpoint, security and policy systems may then provide the context required to make more granular access decisions.

This distinction is important because a trusted branch device should not automatically imply that every user, application or destination behind that device is trusted.

Secure Fabric Engineering Checklist

Before moving into detailed traffic-security controls, a secure SD-WAN design should be able to answer several fundamental questions.

  • How is each SD-WAN edge uniquely identified?
  • How is a new device authenticated before joining the fabric?
  • How are control-plane relationships authenticated and protected?
  • How are administrator identities protected?
  • Which roles can modify global policy?
  • How are management interfaces isolated and monitored?
  • How is traffic protected across shared or untrusted transports?
  • Which traffic classes require separate segmentation?
  • How are compromised or decommissioned devices removed from the trust model?
  • How are configuration and policy changes logged and investigated?
Section 01 · Engineering Takeaway

A secure SD-WAN starts with a trusted fabric. Device identity, management security, control-plane protection, encrypted connectivity and meaningful segmentation establish the foundation on which traffic-security policy can operate. Once that foundation exists, the next engineering question is no longer simply “Can these sites connect?” but “Which traffic is allowed to move between them, through which security boundaries, and under what conditions?”

Engineering Lab · Section 01

SD-WAN Secure Fabric Explorer

Test the trust chain that allows an SD-WAN device to join the fabric, establish control-plane connectivity and participate in an encrypted overlay.

Fabric Healthy
Manipulate trust controls → observe the fabric
Secure Fabric Topology ESTABLISHED
▣
BRANCH-01
WAN EDGE
◈
CONTROLLER
CONTROL PLANE
▣
BRANCH-02
WAN EDGE
☁
OVERLAY
SECURE FABRIC
01
DEVICE
Trusted
02
AUTHENTICATE
Verified
03
CONTROL PLANE
Established
04
POLICY / ROUTES
Accepted
05
ENCRYPTED OVERLAY
Active
Fabric Controls LIVE
Device Trust
Certificate/device identity accepted
Certificate Valid
Secure onboarding credential
Controller Trust
Trusted control-plane authority
Control Plane
Authenticated control session
Encrypted Overlay
Protected data-plane tunnel
Live Telemetry
Device
TRUSTED
Identity
VALID
Control
UP
Overlay
SECURE
Fabric Events
Engineering Readout
The device is trusted, the control plane is established and the encrypted overlay can participate in the secure SD-WAN fabric.
Engineering Challenge
Break the fabric. Disable one trust dependency at a time and determine which failure prevents the overlay from becoming operational.

SD-WAN Architecture & Secure Fabric

Section 02 · Policy

Identity, Segmentation & Security Policy

Connectivity does not automatically mean permission. Modern SD-WAN security can use identity, device posture, application classification, segmentation and risk context to determine which flows should be permitted, inspected, restricted or blocked.

IDENTITY
›
DEVICE
›
APPLICATION
›
SEGMENT
›
RISK
›
DECISION
Engineering Question
Who or what is generating this flow, what should it be allowed to reach, and which security policy should control that communication?
Explore Security Policy →

Once the SD-WAN fabric itself is trusted, the next security challenge is controlling what moves through it. Modern WAN traffic is no longer defined simply by source site and destination site. Applications, users, devices, segments, performance conditions and security policy can all influence how a flow should be handled.

This makes traffic security a combination of encryption, segmentation, policy enforcement and intelligent path selection. The objective is not merely to create a secure tunnel between two locations. It is to ensure that each flow travels through an authorised security boundary, uses an appropriate path and remains isolated from traffic that should never have access to it.

Engineering Principle

A secure SD-WAN flow is more than an encrypted packet. The design must establish who or what generated the traffic, which segment it belongs to, what policy applies, which path is appropriate and whether additional inspection is required.

From Connectivity to Secure Flow Control

In a traditional WAN, forwarding decisions may have been dominated by routing metrics and fixed topology. SD-WAN introduces an additional policy layer in which application and transport information can influence the forwarding decision.

For example, a voice application may require a low-latency path, a business-critical application may require predictable loss characteristics, and general Internet traffic may be permitted to use local broadband breakout. These decisions become security-relevant when different applications have different trust requirements.

01 Identity
02 Application
03 Segment
04 Context
05 Policy
06 Secure Path

This does not mean that every SD-WAN platform directly evaluates every one of these signals. Implementations differ. The engineering model is to understand that connectivity, security and context can increasingly be combined into a single policy decision.

Encryption Protects the Data Plane

Encryption is a fundamental component of SD-WAN security because traffic may cross shared or untrusted transport networks. A branch may use broadband or mobile connectivity to reach another branch, a data centre or a cloud service. The organisation cannot assume that the underlying transport provides the confidentiality or integrity required by the application.

Secure tunnels therefore provide a protected logical path across the physical transport. IPsec is widely used for this purpose, although the precise implementation, tunnel establishment process and control-plane mechanisms vary between SD-WAN platforms.

A useful architectural distinction is between the underlay and the overlay. The underlay consists of the physical or IP connectivity supplied by the transport networks. The overlay provides the logical SD-WAN connectivity and security relationships built across those transports.

Underlay

MPLS, broadband, fibre, LTE, 5G and other transport services that provide basic reachability between locations.

Overlay

Logical connectivity between SD-WAN endpoints, including secure tunnels, routing relationships and policy-controlled forwarding.

Encryption

Protects data in transit across transports that should not be treated as trusted application paths.

Policy

Determines which communications are allowed, restricted, inspected or isolated within the overlay.

The security value of encryption depends on correct key management, endpoint identity, tunnel configuration and lifecycle management. A tunnel that is technically encrypted but established with the wrong endpoint or inappropriate policy is not necessarily a secure communication channel.

Segmentation Creates Security Boundaries

Encryption protects traffic while it travels across a transport, but it does not determine which applications should be allowed to communicate. That responsibility belongs to policy and segmentation.

SD-WAN segmentation can be implemented using technologies such as VRFs, VPNs or platform-specific logical network constructs. These mechanisms allow different classes of traffic to maintain separate forwarding and policy contexts.

The security objective is to prevent unrelated trust domains from being treated as one large network.

Traffic Domain Typical Requirement Security Objective
Corporate Access to internal applications and services Controlled access to trusted enterprise resources
Guest Internet access only Prevent access to corporate and management networks
IoT / OT Restricted application communication Reduce unnecessary lateral movement
Management Administrative access Strong isolation and privileged access control

Segmentation should therefore be designed around business and security requirements rather than simply creating additional logical networks. Each segment should have an explicit definition of what it can reach, what can reach it and where controlled communication between segments is permitted.

Segmentation Is Not the Same as Microsegmentation

The terms segmentation and microsegmentation are sometimes used interchangeably, but they represent different levels of policy granularity. Traditional segmentation may separate broad traffic domains such as corporate, guest and management networks. Microsegmentation aims for much more granular control, potentially considering individual workloads, identities, applications or security groups.

An SD-WAN platform can contribute to segmentation, but the exact level of granularity depends on the platform and its integration with identity, endpoint and security systems. It is therefore better to describe SD-WAN as an enforcement point within a broader segmentation architecture rather than assuming that every SD-WAN deployment automatically provides full microsegmentation.

Application-Aware Path Selection

One of SD-WAN's defining capabilities is the ability to select paths according to application requirements and current network conditions. Instead of relying only on a static route, the system can consider metrics such as latency, packet loss, jitter, bandwidth availability and policy.

This creates a security opportunity. Different application classes can be assigned different forwarding policies, security requirements and acceptable paths.

For example, a real-time voice application may require a stable low-latency path, while a less sensitive backup workload may tolerate a higher-latency transport. A sensitive application might additionally require a particular security service or segmentation boundary before the flow is allowed to proceed.

Path Selection vs Security

Do not confuse “best path” with “permitted path.” A transport can be technically optimal from a performance perspective while still being unsuitable because of security policy, segmentation or inspection requirements.

Policy-Based Forwarding

Policy-based forwarding allows an organisation to define how selected traffic should be handled rather than allowing the routing table alone to determine the outcome.

A policy may identify traffic using application characteristics, source or destination networks, ports, users, segments or other available attributes. It can then determine whether the flow is allowed, which path should be preferred, whether it should be inspected, or whether it should be blocked.

The exact capabilities vary considerably between platforms, so the engineering design should start with the required security outcome rather than assuming a particular vendor feature exists everywhere.

A Useful Policy Model

A practical way to reason about secure SD-WAN forwarding is to separate the decision into stages:

  • Identify the flow: determine source, destination, application and available context.
  • Determine the segment: establish which security domain the traffic belongs to.
  • Evaluate policy: determine whether the communication is permitted.
  • Select the path: choose an appropriate transport or overlay path.
  • Apply security controls: send the flow through required inspection or enforcement points.
  • Monitor the result: record the decision and resulting traffic behaviour.

This model makes an important point: routing is only one part of the security decision.

Branch-to-Branch and Branch-to-Cloud Security

SD-WAN commonly connects branches not only to data centres but also to cloud services and other distributed resources. This changes the traditional assumption that all application traffic should first return to a central security perimeter.

A branch may need direct access to a SaaS platform, a cloud workload or another branch. Forcing every flow through a central data centre can introduce unnecessary latency and consume expensive transport capacity. SD-WAN allows more distributed forwarding models, but the security architecture must move with the traffic.

For branch-to-branch communication, this means defining which segments can communicate and whether the traffic should use direct encrypted connectivity or a controlled hub/service path. For branch-to-cloud traffic, it means deciding whether security inspection occurs locally, through a cloud security service or through another central enforcement point.

Containing Lateral Movement

One of the strongest reasons to combine SD-WAN with segmentation is to limit lateral movement after a device or workload has been compromised.

Consider a branch endpoint that becomes infected with malware. Encryption may keep its traffic protected in transit, but encryption does nothing to prevent the compromised endpoint from attempting to reach other internal systems.

Segmentation and least-privilege policy can reduce that risk by limiting the destinations available to the compromised system. Security controls can then identify suspicious traffic and apply additional restrictions.

The goal is not to guarantee that compromise never occurs. The goal is to make the compromised environment smaller, more observable and easier to contain.

Security Context and Identity

Network location alone is becoming a weaker indicator of trust. A device connected to a corporate branch may be managed and compliant, or it may be compromised. A user working from a branch may require access to one application but not another.

SD-WAN can participate in a broader identity-aware architecture by consuming or integrating with identity, endpoint and security context. This can allow policy decisions to become more granular than source IP address alone.

However, the architecture should remain explicit about where each decision is made. Identity systems determine identity and authentication context. Endpoint systems can provide device posture. SD-WAN can provide connectivity and policy enforcement. Security platforms can provide threat intelligence and inspection. Combining these signals can produce stronger decisions than relying on any single system.

Architecture Note

Identity-aware SD-WAN does not mean that every SD-WAN router independently understands every user identity. In many designs, identity and endpoint context is supplied through integrations with other security and access systems. The important engineering question is how that context reaches the enforcement point and how reliably it can be used in policy.

Secure Traffic Engineering

A mature SD-WAN security design therefore treats traffic as a policy-controlled object rather than simply a packet travelling between two IP addresses.

The same branch may contain multiple traffic classes with completely different requirements. Corporate application traffic may require access to internal services. Guest traffic may require Internet-only connectivity. Operational technology may need to communicate with a small set of known systems. Voice may require a predictable low-latency path. Sensitive applications may require additional inspection.

The SD-WAN architecture should make these differences explicit rather than relying on one universal forwarding rule.

Protect

Use appropriate encryption and authenticated overlay connectivity to protect traffic across the underlying transport.

Separate

Use segmentation to prevent unrelated trust domains from communicating without explicit policy.

Decide

Apply policy to determine whether the flow is permitted and what security requirements apply.

Steer

Select an appropriate path according to application requirements, network conditions and security policy.

Vendor Architectures Are Different

The underlying engineering principles are broadly applicable, but SD-WAN products do not implement them identically. Terminology, control-plane architecture, tunnel establishment, segmentation models, application identification and security integrations differ between vendors.

For example, Cisco SD-WAN uses concepts such as OMP and TLOCs, while other SD-WAN platforms use different control and forwarding models. Some platforms integrate extensive security capabilities directly into the WAN edge; others rely more heavily on external security appliances or cloud-delivered services.

This is why a good SD-WAN security design should begin with requirements such as identity, segmentation, encryption, inspection, availability and policy enforcement, and only then map those requirements to vendor-specific features.

Secure Flow Design Checklist

For each important traffic class, the engineering team should be able to answer the following questions:

  • Who or what is generating the traffic?
  • Which application or service is being accessed?
  • Which security segment does the traffic belong to?
  • Is the source device trusted and appropriately managed?
  • Is the destination authorised for that segment?
  • Must the traffic be encrypted across the transport?
  • Which transport or overlay path should be preferred?
  • Can the path change without violating security policy?
  • Does the traffic require firewall, IPS, DNS, URL or other inspection?
  • What happens if the device, application or destination becomes risky?
Section 02 · Engineering Takeaway

SD-WAN security becomes meaningful when encrypted connectivity is combined with segmentation and policy-controlled forwarding. The objective is not simply to find the fastest route between two endpoints. It is to determine whether the communication is authorised, which security boundaries it must cross, which path is appropriate and whether additional controls must inspect the flow. The next question is what happens when that traffic leaves the private WAN and breaks directly out to the Internet.

Engineering Lab · Section 02

SD-WAN Secure Flow Decision Lab

Change identity, application, segment and device context to see how a policy engine determines whether traffic should be allowed, inspected, blocked or isolated — and which secure path it can use.

POLICY ALLOW
Identity → Application → Segment → Context → Policy → Path
Secure Traffic Decision Path ENFORCED
◉
IDENTITY
USER / DEVICE
◇
APPLICATION
FLOW TYPE
▦
SEGMENT
SECURITY ZONE
◎
POLICY
DECISION ENGINE
⇢
SECURE PATH
FORWARDING
01
IDENTITY
Verified
02
APPLICATION
Classified
03
SEGMENT
Matched
04
CONTEXT
Healthy
05
POLICY
Evaluated
06
PATH
Secure
07
FLOW
ALLOW
Flow Inputs LIVE
Identity
Application
Segment
Device Context
Policy Decision
Enforcement Result
ALLOW
Trusted identity and healthy device satisfy the current policy.
Segment
Corporate
Path
Secure Overlay
Inspection
No
Trust
HIGH
Decision Events
Engineering Readout
The flow has passed identity, application, segmentation and context evaluation. Policy permits the traffic onto the secure overlay.
Engineering Challenge
Change the context. Select a compromised endpoint, sensitive application or guest segment and observe how the enforcement decision changes.

Encryption, Segmentation & Secure Traffic

Section 03 · Enforcement

Secure DIA & Integrated Security Services

Direct Internet Access changes where enterprise traffic exits the WAN, but it does not remove the need for security inspection. Firewalling, IPS, DNS security, URL filtering, TLS inspection and cloud security services can be applied according to the application, destination and policy requirements of each flow.

BRANCH
›
SD-WAN EDGE
›
POLICY
›
INSPECTION
›
DIA
›
CLOUD / INTERNET
Engineering Question
When traffic breaks directly out to the Internet, which security services should inspect the flow before it reaches its destination?
Explore Secure DIA →

The traditional WAN security model often assumed that Internet access would be concentrated behind a small number of central security boundaries. Modern SD-WAN makes local Internet breakout much more practical. A branch can send SaaS, web and cloud traffic directly to the Internet instead of backhauling every session through a central data centre.

This improves application performance and can reduce unnecessary WAN utilisation, but it also changes where security enforcement must occur. When the branch becomes an Internet access point, the security controls that previously protected traffic at a central perimeter must either move closer to the branch, move into the cloud, or be provided through a combination of both.

Engineering Principle

DIA is not inherently insecure. The security question is whether appropriate policy, inspection and monitoring follow the traffic when Internet access is distributed across many locations.

Why Direct Internet Access Changes Security

Direct Internet Access, commonly abbreviated as DIA, allows branch traffic to exit directly to the Internet rather than travelling through a central hub or data centre first.

This architecture is increasingly useful because many business applications are now delivered from cloud platforms. If a user in a branch is accessing a SaaS service, sending the traffic through a central data centre can create additional latency and consume WAN capacity without providing a security benefit that cannot be delivered elsewhere.

The challenge is that local breakout distributes the security perimeter. Instead of one or two Internet gateways, the organisation may now have dozens or hundreds of Internet exit points.

01 Branch User
02 SD-WAN Edge
03 Security Controls
04 DIA Breakout
05 Internet / SaaS

The engineering objective is therefore to create a distributed security perimeter without creating inconsistent security policy.

The Secure Internet Breakout Model

A secure DIA design typically places one or more enforcement layers between the branch user or device and the external destination. The exact architecture depends on the organisation's risk model, traffic types and available security services.

Some environments may place firewall and security inspection directly on the SD-WAN edge. Others may forward traffic to a regional security appliance or a cloud-delivered security service. Hybrid designs can combine local enforcement with cloud inspection depending on application and risk.

Local Edge Security

Firewall, application control and other security functions operate directly on or beside the SD-WAN edge.

Regional Security

Branch traffic is directed to a regional security enforcement point before reaching the Internet.

Cloud Security

Traffic is sent to cloud-delivered security services for inspection and policy enforcement.

Hybrid Enforcement

Different applications or risk classes can use different combinations of local, regional and cloud controls.

Firewall Enforcement at the WAN Edge

A firewall remains an important control for many SD-WAN deployments. The SD-WAN edge can use application, network, port, segment and other available attributes to determine whether traffic should be permitted.

The firewall policy should not simply reproduce a traditional perimeter rule set at every branch. A distributed environment requires central policy management, consistent object definitions, controlled exceptions and appropriate local enforcement.

The policy should also distinguish between traffic that is allowed to leave the branch and traffic that must never reach the Internet. Management services, internal infrastructure and sensitive systems may require significantly more restrictive rules than general user traffic.

Traffic Type Possible Policy Reason
Business SaaS Allow with appropriate inspection Business requirement with controlled external access
General Web Allow with web/DNS controls Reduce exposure to malicious destinations
Management Restrict or block direct Internet access Reduce exposure of privileged infrastructure
Unknown / High Risk Inspect, restrict or block Prevent uncontrolled exposure to suspicious destinations

IDS and IPS Protection

Firewall policy answers whether traffic is permitted according to defined rules, but permitted traffic can still contain malicious behaviour. Intrusion Detection and Intrusion Prevention Systems provide another layer of analysis.

An IDS identifies suspicious activity and generates an alert. An IPS can additionally take an enforcement action, depending on the implementation and policy.

These controls can be particularly valuable for Internet breakout because branch traffic is exposed directly to external destinations. They can also provide visibility into attacks that would otherwise appear to be legitimate permitted sessions.

Technologies such as Snort and Suricata are examples of IDS/IPS engines used in different network-security architectures. They should be viewed as examples rather than assuming that every SD-WAN platform uses the same inspection engine.

Detection is not the same as prevention.

An alert tells the organisation that suspicious behaviour has been observed. Prevention requires the enforcement point to have the capability and policy authority to interrupt or restrict the traffic.

DNS Security

DNS is another important security enforcement point because many applications begin with a name-resolution request. Malicious infrastructure may use domains associated with phishing, malware delivery, command-and-control or other threats.

DNS security can therefore identify or block known malicious destinations before the connection is established. It can also provide useful telemetry about which devices are attempting to resolve suspicious domains.

However, DNS security should be treated as one layer rather than a complete security solution. Modern applications can use encrypted DNS, hard-coded destinations, content delivery networks and other techniques that make DNS alone insufficient for determining whether a connection is safe.

URL and Web Filtering

Web filtering provides another layer of policy by evaluating requested destinations or web categories. An organisation may allow business services while restricting categories that present unnecessary risk or violate corporate policy.

This becomes especially useful in distributed DIA environments because the policy can be applied consistently regardless of which branch provides the Internet connection.

The engineering challenge is balancing security with usability. Overly broad blocking can interfere with legitimate business activity, while overly permissive policy reduces the value of the control. Categories, reputation, user context and exception management should therefore be considered together.

TLS Inspection

Encryption protects users and applications, but it also reduces the visibility available to traditional security controls. A significant proportion of modern application traffic is encrypted using TLS, meaning that security devices may not be able to inspect the contents of the session without an appropriate inspection mechanism.

TLS inspection can provide deeper visibility by terminating and re-establishing encrypted sessions under controlled conditions. This can allow security systems to inspect otherwise opaque traffic.

However, TLS inspection introduces significant engineering considerations. Certificate deployment, device compatibility, performance, privacy, application breakage and legal or regulatory requirements must all be considered before enabling it broadly.

Inspection Boundary

More inspection is not automatically better security. Inspection should be applied where it provides meaningful risk reduction and where the organisation can operate the associated certificate, privacy, performance and exception-management processes correctly.

Security Service Chaining

Some traffic requires multiple security controls. A high-risk Internet flow might need firewall enforcement, DNS protection, URL filtering, malware analysis and additional inspection before it is allowed to reach its destination.

The traffic path can therefore become a security service chain.

01 Classify
02 Firewall
03 DNS / Web
04 Threat Inspect
05 Internet

The important design principle is that not every application necessarily needs every security service. Applying the entire inspection chain to every packet can increase latency, consume resources and complicate troubleshooting.

Policy should determine which traffic requires which controls. Business-critical SaaS traffic may require one treatment, sensitive data another, and guest Internet traffic a simpler but still controlled path.

Security Policy Should Follow the Flow

Once Internet breakout is distributed, policy consistency becomes a major operational requirement. A user should not receive significantly different security treatment simply because they happen to be working from another branch.

Centralised policy management can help maintain consistency, but local conditions still matter. Branches may have different bandwidth, different security capabilities, different regulatory requirements or different application dependencies.

A strong design therefore combines central policy intent with controlled local enforcement.

Policy Intent

Define the security outcome centrally: who can access what, under which conditions and with which controls.

Enforcement Point

Determine where the required control should actually inspect or block the traffic.

Path Selection

Select a path that satisfies both application performance and security requirements.

Telemetry

Record enough information to determine whether the policy produced the expected result.

Relationship Between SD-WAN and SASE

SD-WAN and SASE are closely related but should not be treated as synonyms.

SD-WAN primarily provides software-controlled connectivity, transport abstraction, routing, segmentation and application-aware traffic steering. SASE is a broader architectural model that combines networking capabilities with distributed, often cloud-delivered security services.

An SD-WAN edge can therefore be an important networking component within a SASE architecture. Security services such as secure web access, Zero Trust access, cloud firewalling, DNS security and threat inspection may be delivered separately or integrated with the SD-WAN environment.

The important engineering question is not whether an organisation has “SD-WAN or SASE.” It is how connectivity and security services are combined to produce a consistent access and enforcement model.

Vendor Example

Cisco provides multiple networking and cloud-security products that can participate in SASE-oriented architectures. Cisco Umbrella is a cloud security service within that broader ecosystem; it should not be described as simply “Cisco's version of SASE.”

Integrated Security at the Branch

Modern SD-WAN platforms increasingly integrate networking and security functions at the edge. This can simplify deployment because a single branch device may provide routing, segmentation, firewalling and application-aware controls.

Integration can also improve visibility because the same system understands the traffic path and security decision. However, consolidation introduces its own risks. A failure or compromise of the integrated edge may affect multiple functions simultaneously, and resource constraints can become important when advanced inspection is enabled.

Architecture should therefore consider capacity, resilience, software lifecycle, high availability and the ability to maintain security controls during transport or device failures.

Distributed Security Requires Distributed Operations

A centralised security architecture allows a small number of enforcement points to be monitored closely. Distributed DIA changes this operational model.

Security teams now need visibility into many Internet exit points, each potentially producing firewall events, DNS activity, web requests, IPS alerts and application telemetry.

This makes centralised logging and security analytics increasingly important. The objective is to make a distributed enforcement architecture appear as one coherent security system to the operations team.

DIA Security Design Checklist

For each branch with direct Internet access, the engineering team should be able to answer:

  • Which traffic is allowed to use local Internet breakout?
  • Which traffic must remain on the private WAN?
  • Where is the firewall enforcement point?
  • Where is DNS security applied?
  • Is web or URL filtering required?
  • Which traffic requires IDS/IPS inspection?
  • Where, if anywhere, is TLS inspection performed?
  • Which traffic is sent to cloud security services?
  • How are exceptions approved and maintained?
  • How are security events from all branches collected centrally?
  • What happens when a local security service becomes unavailable?
  • How does the SD-WAN policy respond when the preferred security path fails?

The Secure DIA Decision

A useful way to evaluate an Internet-bound flow is to stop thinking about DIA as simply “send the packet to the Internet.” Instead, treat the breakout as a security decision.

The SD-WAN edge should determine the traffic class, identify the appropriate security policy, select the required inspection services and then choose an available path that satisfies both performance and security requirements.

Example engineering decision

A managed corporate device requests a business SaaS application. The flow belongs to the corporate segment, is permitted by policy, passes DNS and web-security controls, uses an approved Internet breakout and is monitored. A guest device requesting an internal application receives a different outcome: the segment policy prevents the connection before it reaches the protected resource.

Section 03 · Engineering Takeaway

Direct Internet Access changes where security must be enforced, not whether security is required. A mature SD-WAN design combines local or cloud-based firewalling, DNS and web controls, threat inspection and appropriate encryption or TLS visibility with centralised policy and telemetry. Once security enforcement is distributed across the WAN, the final engineering challenge is operational: how do we know when a trusted device, flow or policy begins behaving suspiciously?

Engineering Lab · Section 03

Secure DIA / Internet Breakout Explorer

Explore how Direct Internet Access changes the security path. Select a traffic scenario and determine which security services should inspect the flow before it reaches the Internet or SaaS.

DIA SECURE
BRANCH → EDGE → SECURITY STACK → DIA → INTERNET
Internet Breakout Security Path PROTECTED
◉
BRANCH
USER / DEVICE
◇
SD-WAN EDGE
WAN SECURITY
◈
SECURITY
INSPECTION
⇢
DIA
BREAKOUT
◎
INTERNET
WEB / SaaS
Traffic Scenario LIVE
Flow Type
Destination Trust
Security Controls
Enforcement Result
DIA Decision
ALLOW
Business SaaS is permitted through the protected Internet breakout path.
Breakout
Local DIA
Inspection
Standard
Security
Protected
Destination
Trusted
Breakout Events
Engineering Readout
The selected Internet flow is using local DIA with the required security controls applied before breakout.
Engineering Challenge
Break the security path. Disable one or more controls and change the destination to observe when the flow becomes restricted or blocked.

DIA & Integrated Security Enforcement

Section 04 · Operations

Visibility, Threat Detection & Response

A secure SD-WAN must also be observable. Application flows, identity activity, device behaviour, DNS events, security alerts and path changes provide the telemetry required to detect abnormal behaviour, investigate incidents and respond before a local compromise becomes a wider WAN security problem.

OBSERVE
›
CORRELATE
›
INVESTIGATE
›
CONTAIN
›
RECOVER
Engineering Question
How do we recognise when a normal SD-WAN flow becomes suspicious, correlate the evidence and contain the affected identity, device or segment?
Investigate an Incident →

A secure SD-WAN cannot be judged only by whether its tunnels are encrypted or whether its firewall rules appear correct. Modern WAN environments are dynamic: paths change, applications move to the cloud, devices change state, Internet breakout is distributed and policy is continually updated. Security therefore depends on being able to observe what the fabric is doing and recognise when normal behaviour becomes suspicious.

Visibility turns SD-WAN from a connectivity platform into an operational security system. Telemetry from the WAN edge, applications, users, security controls, DNS services and cloud platforms can be combined to establish what happened, where it happened and what response is appropriate.

Engineering Principle

You cannot reliably secure what you cannot observe. Security telemetry should connect the original policy decision to the resulting traffic behaviour so that engineers can investigate both successful and suspicious flows.

From Visibility to Security Evidence

SD-WAN generates a significant amount of operational information. Tunnel status, path quality, application performance, routing changes and device health are all useful, but security teams need more than raw counters.

Useful security telemetry should help answer questions such as:

  • Which device generated the traffic?
  • Which user or application was involved?
  • Which segment carried the flow?
  • Which path did the traffic use?
  • Which security policy was applied?
  • Was the traffic inspected or bypassed?
  • What destination did the device contact?
  • Did the device subsequently exhibit other suspicious behaviour?

The goal is to create an evidence chain rather than a collection of disconnected alerts.

01 Identity
02 Device State
03 Flow
04 DNS / Web
05 Security Alert
06 Policy Change
07 Response

WAN Telemetry and Application Visibility

The first layer of operational visibility comes from the WAN itself. SD-WAN platforms can typically expose information about transport health, tunnel state, packet loss, latency, jitter, bandwidth utilisation and application performance.

This information is valuable for both network operations and security investigation. A sudden change in traffic behaviour can be an operational problem, a security event or both.

For example, a branch may suddenly send substantially more traffic than normal to an unfamiliar destination. The initial symptom could appear as a bandwidth anomaly, but when correlated with DNS activity and endpoint telemetry it may become evidence of data exfiltration or malware activity.

Path Telemetry

Latency, loss, jitter, tunnel state and transport availability provide context for how traffic is moving through the WAN.

Application Telemetry

Application classification and traffic patterns help determine what services are actually using the network.

Security Telemetry

Firewall, DNS, web, IPS and other controls provide evidence about suspicious or prohibited behaviour.

Identity & Device Context

User and endpoint information can add the context required to distinguish normal business activity from risky behaviour.

Security Events Need Correlation

A single alert is rarely enough to determine what is happening. Security investigation becomes more effective when multiple events are correlated across time.

Consider a branch endpoint that has been operating normally. It suddenly begins resolving a newly observed domain, establishes an unusual outbound session and then generates an IPS alert. Shortly afterwards, it attempts to connect to systems in another internal segment.

Each event provides only part of the story. Together they create a much stronger indication that the endpoint may have been compromised.

09:41:12
DEVICE
Endpoint posture changes from normal to elevated risk.
09:42:03
DNS
Device resolves a previously unseen external domain.
09:42:09
FLOW
Outbound traffic begins to the newly resolved destination.
09:42:17
IPS
Suspicious payload pattern detected.
09:43:01
SEGMENT
Device attempts communication with a restricted internal segment.

This type of correlated timeline is much more useful to an engineer than five independent alerts arriving from five different systems.

Threat Detection in the SD-WAN Environment

Threat detection can operate at several layers. Signature-based IDS/IPS controls can identify known attack patterns. DNS and web-security services can identify malicious destinations. Behavioural analytics can identify unusual traffic patterns. Endpoint systems can provide evidence about process or device compromise.

No single mechanism should be expected to identify every threat. Modern attacks can change infrastructure, encrypt payloads, use legitimate cloud services and deliberately avoid obvious signatures.

The SD-WAN environment therefore benefits from combining network and security telemetry rather than treating the WAN as a separate operational silo.

Detecting Behavioural Anomalies

Behavioural analysis looks beyond individual signatures and asks whether activity is unusual for a device, application, user or location.

Examples include:

  • A branch suddenly generating much more outbound traffic than normal.
  • A device contacting destinations it has never previously accessed.
  • A workstation communicating with a server segment that its policy normally prevents.
  • An application suddenly using a different transport or destination profile.
  • A privileged device attempting unusual Internet access.
  • A large increase in DNS requests from a single endpoint.

An anomaly is not automatically an attack. A software update, business event or network migration can produce unusual behaviour. The value of behavioural analytics is therefore to provide investigative signals that can be combined with other evidence.

Operational Principle

Anomaly detection should trigger investigation, not automatically become proof of compromise. Context and correlation determine whether unusual behaviour represents legitimate change, misconfiguration or an active security incident.

Threat Hunting Across the Fabric

Once telemetry is centralised, security teams can actively search for patterns rather than waiting for an alert.

Threat hunting might begin with a known malicious destination, an unusual DNS pattern, a suspicious application or an unexpected connection between two segments. Engineers can then work backwards and forwards through the available telemetry to identify affected devices and related activity.

The distributed nature of SD-WAN makes this especially valuable. A threat that appears at one branch may have related activity at another location, particularly when the same identity, application, policy or device type exists across the organisation.

SIEM and Centralised Security Analytics

A Security Information and Event Management platform can provide a central location for collecting and correlating events from SD-WAN infrastructure and associated security systems.

The SD-WAN platform may contribute tunnel events, application telemetry, configuration changes and policy decisions. Firewalls can contribute session and enforcement data. DNS systems can provide domain-resolution events. Endpoint platforms can provide device-level evidence. Identity systems can provide authentication and access information.

When these signals are combined, the security team can investigate an incident across the complete path rather than analysing each technology independently.

Architecture Note

The SD-WAN platform does not need to become the organisation's entire security analytics platform. Its role is to expose useful telemetry and policy evidence that can be consumed by the wider security operations architecture.

Investigating a Compromised Endpoint

One of the most useful operational scenarios is investigating a device that was previously trusted but has begun behaving abnormally.

The investigation should not immediately focus on blocking a single destination. Instead, engineers should establish the sequence of events.

1. Establish Identity

Determine which device, user, segment and branch are involved and whether the device is normally trusted.

2. Reconstruct the Flow

Identify destinations, applications, paths and security decisions associated with the suspicious activity.

3. Correlate Evidence

Compare DNS, web, firewall, IPS, endpoint and identity events to determine whether the activity is connected.

4. Contain

Restrict access, isolate the device or revoke trust while preserving enough telemetry to continue the investigation.

Response Should Be Proportional to Risk

Not every suspicious event requires the same response. A mature architecture provides several levels of enforcement so that the security team can respond proportionally.

Response Use Case Effect
Monitor Low-confidence anomaly Continue observation and collect evidence
Restrict Elevated risk Reduce available destinations or applications
Revoke Loss of trust Remove access previously granted to the device or identity
Isolate Likely compromise Contain the endpoint or segment to prevent further movement

This approach is particularly useful when SD-WAN policy is integrated with identity and endpoint security. A device can move from a normal state to a restricted state without requiring the network team to redesign the entire topology.

Policy Changes Are Security Events Too

Security teams often focus on traffic alerts while overlooking configuration changes. In a software-defined WAN, however, policy changes can have a significant impact on the entire environment.

An unexpected firewall rule, segmentation change, routing policy modification or administrator login may explain why traffic behaviour changed. Configuration history should therefore be treated as part of the security evidence.

A useful investigation asks not only “What traffic occurred?” but also “What changed immediately before the traffic occurred?”

Operational Resilience and Security

Security controls themselves can fail. A firewall service may become unavailable, a cloud security path may be unreachable, a tunnel may fail or a branch device may lose connectivity to its controller.

The SD-WAN policy should define what happens in these conditions.

Some applications may tolerate a temporary loss of a security service and fail closed. Others may require an alternative inspection path. Certain non-sensitive traffic may continue through another controlled route.

The correct behaviour depends on the application's risk and availability requirements. The important point is that security failure behaviour should be designed rather than left to chance.

Continuous Security Improvement

SD-WAN security is not a configuration that is completed once and then left unchanged. New applications appear, users change behaviour, branches are added, transports evolve and threats change.

Telemetry should therefore feed back into policy design. Security teams can use observed traffic to identify unnecessary access, missing segmentation, ineffective inspection rules and new application requirements.

This creates a continuous engineering cycle:

01 Observe
02 Investigate
03 Decide
04 Enforce
05 Measure
06 Refine
07 Repeat

The Complete SD-WAN Security Model

The four engineering stages in this guide are deliberately connected.

First, secure the fabric. Devices, management systems and control-plane relationships must be trusted before the network can be relied upon.

Second, protect the flow. Encryption, segmentation and policy-controlled forwarding determine how authorised traffic can move through the WAN.

Third, enforce security at the right point. DIA, firewalling, DNS security, web filtering, IPS and cloud security services provide inspection and enforcement where the traffic actually travels.

Finally, observe and respond. Telemetry connects the original decision to the resulting behaviour and allows the security team to identify anomalies, investigate incidents and change policy when risk changes.

The Engineering Model

SECURE FABRIC → PROTECT FLOW → ENFORCE POLICY → OBSERVE & RESPOND
Security becomes part of the WAN's operating model rather than a separate appliance positioned around the edge of it.

SD-WAN Security Operations Checklist

A mature SD-WAN security architecture should be able to answer the following questions continuously:

  • Are all participating devices still trusted?
  • Are management and control-plane relationships healthy and authorised?
  • Are encrypted overlays operating as expected?
  • Are segmentation boundaries preventing unintended communication?
  • Are application flows using appropriate paths?
  • Are Internet-bound flows receiving the required security controls?
  • Are DNS, web, firewall and IPS events being collected?
  • Can suspicious behaviour be correlated across branches?
  • Can security teams reconstruct the sequence of an incident?
  • Can a compromised device be restricted or isolated quickly?
  • Are policy and configuration changes auditable?
  • Does the architecture have defined behaviour when a security service fails?
The final engineering question

A secure SD-WAN should not simply tell you that a connection exists. It should provide enough evidence to explain who or what communicated, where the traffic travelled, which policy allowed or denied it, what security controls inspected it, and what changed when the risk level changed.

Section 04 · Engineering Takeaway

Visibility completes the SD-WAN security model. Secure connectivity and enforcement establish the controls, but telemetry determines whether those controls are actually producing the intended outcome. By correlating identity, device state, application flows, DNS activity, security alerts, configuration changes and policy decisions, engineers can move from reactive troubleshooting to structured investigation and response. The result is a WAN that can not only connect and protect, but also explain, detect and adapt.

imation. imation.
Engineering Lab · Section 04

SD-WAN Security Incident Investigation

Investigate a previously trusted SD-WAN endpoint as its behaviour changes. Correlate identity, device, flow, DNS, web and IPS evidence before choosing the least disruptive response that contains the risk.

INVESTIGATING
AUTH → DEVICE → FLOW → DNS/WEB → IPS → RESPONSE
Incident Evidence Timeline 1 / 7
09:14:02
Authentication
User authentication succeeded from Branch-17.
Baseline trust
09:18:44
Device
Endpoint posture changes from healthy to unknown.
Risk +18
09:21:07
Flow
Unusual outbound traffic volume appears.
Risk +16
09:22:31
DNS / Web
Endpoint queries a newly observed suspicious domain.
Risk +21
09:23:02
IPS
Exploit-like traffic pattern detected.
Risk +28
09:24:15
Lateral Movement
Endpoint attempts access to an internal server segment.
Risk +24
09:25:04
Policy
Security policy threshold is exceeded.
Response required
Selected Evidence
Authentication succeeded
The initial login is valid. This establishes a trusted starting point, but it does not prove that the endpoint remains trustworthy throughout the session.
BASELINE TRUST
Threat Assessment ELEVATED
Composite Risk
18
Continue monitoring
Correlated Signals
Identity
Valid
Device
Healthy
Flow
Normal
DNS / Web
Normal
IPS
Clear
Lateral
None
Response Decision
Engineering Readout
Authentication is valid, but identity alone is not sufficient evidence to establish ongoing trust.
Engineering Challenge
Correlate before responding. Advance through the evidence, identify the point where the risk becomes material, then choose a proportional containment action.
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
Cisco Umbrella

SD-WAN SASE

NETWORK ENGINEERING GUIDE

SD-WAN & SASE: From Intelligent Connectivity to Secure Access

SD-WAN and SASE address different parts of the modern connectivity problem. SD-WAN provides the software-controlled networking fabric that determines how traffic moves across available transports, while SASE extends security and access enforcement closer to users, devices, applications and Internet destinations.

ENGINEERING QUESTION
How do SD-WAN and SASE work together to connect users and applications while continuously deciding how access should be secured and enforced?
01
CONNECT
Build the intelligent connectivity fabric
02
DECIDE
Evaluate identity, context and policy
03
ENFORCE
Apply security controls at the edge
04
ADAPT
Respond when behaviour or risk changes

What This Guide Examines

The relationship between SD-WAN and SASE is often reduced to a product comparison. The engineering problem is broader: traffic may originate from a branch, remote user, cloud workload or SaaS application, traverse multiple transports, and encounter security controls distributed across different enforcement points.

This guide follows that traffic and examines how connectivity, identity, application context, path quality, security policy and behavioural signals combine to determine what should happen to each flow.

The objective is not to treat SD-WAN and SASE as interchangeable technologies, but to understand where their responsibilities meet and how they can form a coherent architecture.

CORE ENGINEERING MODEL
SD-WAN provides connectivity, routing, path selection and traffic steering across the WAN fabric.

SASE provides a distributed security and access architecture that evaluates context and applies security controls closer to users and applications.

Together they enable a more dynamic model of connectivity + policy + security + continuous adaptation.
ENGINEERING PROGRESSION
01 Architecture → understand where SD-WAN connectivity and SASE security responsibilities sit  ·  02 Decision → evaluate identity, context, path and policy  ·  03 Enforcement → determine where security inspection should occur  ·  04 Adaptation → respond when trust, behaviour or risk changes

SD-WAN & SASE Architecture

ENGINEERING FOCUS · 01
SD-WAN & SASE Architecture
CONNECT
ENGINEERING QUESTION How do SD-WAN and SASE fit together without treating them as the same technology?
UNDERLAY Transport
→
SD-WAN Connectivity
→
SASE Security Edge
→
APPLICATION Access
THIS SECTION EXAMINES

Underlay and overlay, SD-WAN edge functions, application-aware routing, distributed SASE enforcement and the boundary between connectivity and security.

INTERACTIVE LAB Modern Secure Connectivity Architecture

Section 01 — SD-WAN & SASE Architecture

The first step in understanding SD-WAN and SASE is to separate their responsibilities. They are complementary architectural capabilities, not two names for the same technology. SD-WAN focuses primarily on connectivity, routing, path selection and traffic steering, while SASE brings security and access controls closer to users, devices, applications and Internet destinations.

The SD-WAN Connectivity Fabric

SD-WAN creates a software-controlled abstraction over the available WAN transports. A branch may have broadband, private connectivity, 5G, LTE or other transport options, and the SD-WAN edge can use policy and real-time path information to determine how application traffic should be carried.

The important distinction is between the underlay and the overlay. The underlay provides the physical or provider connectivity. The overlay provides the logical networking relationships, routing information, tunnels and policy-controlled paths that operate across those transports.

This separation allows the network to make decisions based on application requirements rather than treating every available link as equivalent. A latency-sensitive application may require a different path from bulk data transfer, while a critical business service may be given a higher-quality path when conditions change.

Where SASE Enters the Architecture

SASE extends this model beyond connectivity. Instead of assuming that security enforcement must occur at a central enterprise data centre, security capabilities can be delivered through distributed cloud-based enforcement points, commonly referred to as SASE Points of Presence or security service edges.

Depending on the architecture and provider, these enforcement capabilities may include secure web access, firewall services, DNS security, intrusion prevention, URL filtering, cloud access controls, data protection and other security functions.

The architectural objective is to place security enforcement in a location that is appropriate for the traffic rather than automatically backhauling every Internet or SaaS request through a traditional central security stack.

SD-WAN and SASE Are Not the Same Decision

A useful engineering model is to treat connectivity and security as related but distinct decisions.

SD-WAN
Which available network path should carry this traffic?
SASE
What security and access controls should apply to this traffic?

In practice these decisions interact. Application identity, user identity, device posture, path quality and security policy can all influence the resulting treatment of a flow. However, combining the technologies does not mean that routing and security become a single function.

From Branch Connectivity to Application Access

Consider a user at a branch accessing a cloud application. The request may begin at a local endpoint, cross the branch LAN, reach the SD-WAN edge and then use an available WAN transport. Rather than automatically sending the request through a central data centre, the architecture may steer it toward an appropriate cloud or SASE enforcement point.

At the security edge, the request can be evaluated using identity, device context, application classification, destination, policy and risk signals. The resulting decision may permit the request, require additional verification, restrict access or block the flow.

This creates a much more distributed architecture than the traditional model of branch → WAN → central data centre → Internet. The important change is not simply that security has moved into the cloud. It is that connectivity and security can now be coordinated around the location of the user, application and enforcement point.

The Architecture in Four Layers

01 · UNDERLAY
Physical and provider transports that supply connectivity.
02 · OVERLAY
Logical paths, routing and policy-controlled traffic steering.
03 · SECURITY EDGE
Distributed security services and access enforcement.
04 · POLICY
Identity, context, application and risk determine treatment.

Why the Architecture Matters

The value of combining SD-WAN and SASE is therefore not simply operational convenience. It is the ability to create a consistent policy model across increasingly distributed environments where users, applications and workloads are no longer concentrated inside one enterprise perimeter.

SD-WAN provides the connectivity intelligence required to move traffic efficiently across the available network. SASE provides security and access enforcement that can follow the traffic toward the user, application or destination.

The result is an architecture in which connectivity is dynamic, security is distributed, and access decisions can continuously adapt to context.

SD-WAN + SASE

Modern Secure Connectivity Architecture

SD-WAN provides the connectivity and application-aware path selection. SASE adds cloud-delivered security, identity-aware policy and continuous protection. Click each layer to explore its role.
01
User / Branch
Identity + device
›
02
SD-WAN Edge
Routing + telemetry
›
03
Secure Overlay
IPsec + segments
›
04
SASE Policy
Identity + context
›
05
Security Services
Inspect + enforce
›
06
Application
SaaS + cloud + private

User / Branch

Traffic originates from a branch, remote user, device or workload. The request carries identity, application and device context that can influence the security decision.

SD-WAN Responsibilities

Connect: build the WAN fabric.
Measure: latency, loss and jitter.
Classify: identify applications.
Steer: select an appropriate path.

SASE Responsibilities

Evaluate: identity and context.
Inspect: apply security services.
Enforce: allow, restrict or block.
Protect: maintain policy at the cloud edge.

Engineer’s mental model: SD-WAN answers “How should this traffic move?” while SASE answers “What security policy should apply?”. Together they create an identity-aware connectivity fabric rather than treating networking and security as separate systems.

Identity, Context & Traffic Decision

ENGINEERING FOCUS · 02
Identity, Context & Traffic Decision
DECIDE
ENGINEERING QUESTION How do we decide which path, security controls and access policy should apply to a flow?
IDENTITY Who?
DEVICE Trusted?
APPLICATION What?
PATH Which route?
RISK How risky?
POLICY DECISION
ALLOW
STEP-UP
RESTRICT
BLOCK
THIS SECTION EXAMINES

Identity, device posture, application classification, link quality, risk signals and the difference between routing decisions and security decisions.

INTERACTIVE LAB SD-WAN → SASE Traffic Decision

Section 02 — Identity, Context & Traffic Decision

Once SD-WAN provides a programmable connectivity fabric, the next engineering problem is deciding how an individual flow should be treated. Modern access decisions cannot rely only on an IP address or the network from which a request originated. User identity, device posture, application identity, destination, path conditions and security policy can all contribute to the final decision.

From Network Location to Context

Traditional network security often associated trust with location. A request arriving from an internal subnet or corporate WAN was generally treated differently from traffic arriving from the public Internet. Distributed applications and remote access have made that model increasingly difficult to maintain.

A modern architecture can instead evaluate the context surrounding the request. The same user accessing the same application may receive different treatment depending on the device being used, authentication strength, security posture, destination, current risk and other policy signals.

This does not mean that every architecture uses exactly the same signals. The engineering principle is that access decisions should be based on relevant context rather than network location alone.

The Context Used by a Traffic Decision

IDENTITY
Who is requesting access and how strongly has that identity been verified?
DEVICE
Is the endpoint known, managed and compliant with the required security posture?
APPLICATION
What service is being accessed and what level of protection does it require?
DESTINATION
Where is the traffic going and is that destination permitted?
RISK
Are there signals indicating unusual behaviour or elevated security risk?
PATH
Which available network path currently meets the application's requirements?

Routing Decision vs Security Decision

One of the most important distinctions in a combined SD-WAN and SASE architecture is that path selection and security enforcement are related but different decisions.

CONNECTIVITY DECISION
Which transport, tunnel or forwarding path should carry the traffic?
Common inputs include latency, packet loss, jitter, availability, application requirements and routing policy.
SECURITY DECISION
Should this request be allowed, challenged, restricted or blocked?
Common inputs include identity, device posture, application, destination, policy and risk.

These decisions may influence one another without becoming the same decision. For example, an application may require a low-latency path while a security policy requires the traffic to pass through a particular inspection service. The resulting architecture must satisfy both requirements.

Application-Aware Connectivity

SD-WAN can classify traffic according to application characteristics and apply different forwarding policies. This allows the network to distinguish between business-critical collaboration, voice, SaaS, bulk data and less-sensitive traffic rather than treating every packet identically.

Path selection can then consider measured conditions across the available transports. If one path develops excessive loss or latency, traffic may be moved to another path when the policy permits that change.

This creates an important feedback loop: application requirements influence connectivity, while real-time network telemetry influences path selection.

Identity-Aware Access

SASE architectures extend the decision beyond the network path. A request can be evaluated against an identity-aware policy that considers who the user is, what device they are using and what application they are attempting to reach.

A successful authentication does not necessarily mean that every subsequent request should receive unrestricted access. Additional signals can change the decision. A managed device may receive normal access, while an unmanaged device may be restricted. A high-risk sign-in may trigger stronger authentication, while an explicitly prohibited destination may be blocked.

This is where Zero Trust principles become relevant: trust should not be treated as a permanent property of a user, device or network location. Access should be evaluated according to the policy and context applicable to the request.

Four Possible Policy Outcomes

ALLOW
The request satisfies the applicable policy and can proceed.
STEP-UP
Additional verification is required before access continues.
RESTRICT
Access is permitted with reduced capability or additional controls.
BLOCK
The request violates policy or presents unacceptable risk.

A Policy Decision Is a Point-in-Time Evaluation

A major advantage of combining identity, network and security telemetry is that policy can respond to changing conditions. A flow that was acceptable several minutes ago may no longer satisfy policy if the user's risk changes, the device loses compliance, the destination becomes suspicious or the traffic pattern becomes anomalous.

This is why modern access architectures increasingly treat authorisation as a continuing control rather than a single event that occurs only at login.

The engineering model therefore becomes: IDENTITY + DEVICE + APPLICATION + DESTINATION + NETWORK + RISK → POLICY DECISION. The resulting decision can then determine both how the traffic is connected and which security controls are required.

DECISION ENGINE

SD-WAN → SASE Traffic Decision

A traffic flow is evaluated using application, identity, device, network and security context before the final access and forwarding decision. Click each stage to inspect the logic.
Example request: A user opens a business SaaS application from a branch. The SD-WAN fabric must select an appropriate path while SASE determines what security controls and access policy should apply.
01
Application
What is being accessed?
›
02
Identity
Who is requesting it?
›
03
Device
Is the device trusted?
›
04
Link Health
Which path performs?
›
05
Policy
What controls apply?
›
06
Inspection
Inspect + enforce
›
07
Decision
Allow / restrict / block

Application Request

The flow arrives with source, destination, protocol, port and application information. The first task is to understand what traffic is being requested.

APPLICATION SaaS
IDENTITY Validated
DEVICE Compliant
LATENCY 28 ms
LOSS 0.2%
RISK Low

Possible Policy Outcomes

The final result depends on the combined evidence rather than a single signal.

ALLOW Trusted identity, compliant device and acceptable risk.
STEP-UP Additional authentication is required.
RESTRICT Limited access or a controlled security path is applied.
BLOCK Policy prevents the connection from proceeding.
Example result: SaaS application + validated identity + compliant device + low risk + healthy preferred transport → appropriate SD-WAN path + normal SASE security policy → ALLOW.

Secure Internet Access & SASE Enforcement

ENGINEERING FOCUS · 03
Secure Internet Access & SASE Enforcement
ENFORCE
ENGINEERING QUESTION When users and branches connect directly to cloud and Internet services, where should security inspection occur?
USER / BRANCH Traffic source
→
SD-WAN EDGE Connectivity
→
SASE ENFORCEMENT
Security service path
→
INTERNET / SaaS Destination
DNS FIREWALL IPS URL FILTER CASB / DLP TLS INSPECTION
THIS SECTION EXAMINES

Direct Internet Access, SASE PoPs, secure web access, firewall services, threat inspection, cloud controls, data protection and policy-driven service chaining.

INTERACTIVE LAB SD-WAN Secure DIA / Internet Breakout Explorer

Section 03 — Secure Internet Access & SASE Enforcement

Once a traffic flow has been classified and a connectivity decision has been made, the next question is where security enforcement should occur. Modern users and applications increasingly communicate directly with SaaS platforms, public cloud services and the Internet. Sending every request back through a central enterprise security stack can introduce unnecessary latency and complexity, particularly when users and branches are geographically distributed.

Secure Internet Access combines direct connectivity with distributed security controls. SD-WAN can provide the path toward the Internet or cloud destination, while SASE security services can inspect and enforce policy closer to the source or destination of the traffic.

Direct Internet Access Changes the Traffic Path

In a traditional branch architecture, Internet-bound traffic may be backhauled across the WAN to a central data centre where firewalls, proxies and other security controls are located. This can provide centralised control, but it also means that traffic may travel farther than necessary before reaching its destination.

Direct Internet Access, or DIA, allows a branch or user location to connect directly to Internet destinations. The important security requirement is that direct connectivity must not mean direct, uncontrolled access.

TRADITIONAL MODEL
Branch / User → WAN → Central Security Stack → Internet / SaaS
DISTRIBUTED MODEL
Branch / User → SD-WAN Edge → SASE Enforcement → Internet / SaaS

The advantage is not simply shorter routing. The architecture can select an appropriate security enforcement point while preserving policy visibility and control.

The SASE Enforcement Point

A SASE architecture can provide a distributed security edge through cloud-based enforcement points. Traffic is directed to an appropriate security location where multiple controls can be applied according to the policy associated with the request.

SECURE WEB
Inspect and control web access according to security policy.
FIREWALL
Apply network and application-aware security rules to permitted flows.
THREAT CONTROL
Detect suspicious destinations, exploits, malware and other threats.
DATA CONTROL
Apply controls for cloud applications, sensitive data and organisational policy.

Security Service Chaining

Not every request needs every security service. An important part of SASE enforcement is determining which controls should inspect a particular flow.

For example, a request to a known business SaaS application may require identity-aware access control and policy enforcement, while general web traffic may require secure web filtering and DNS security. A suspicious destination may trigger deeper threat inspection or be blocked before the connection proceeds.

This creates a policy-driven security service path rather than a fixed sequence in which every packet is forced through every available inspection engine.

Common SASE Security Controls

DNS Security
Detect and control requests to known malicious or inappropriate destinations.
URL Filtering
Apply organisational policy to web destinations and content categories.
Firewall
Control network and application traffic according to policy.
IPS / Threat Prevention
Identify traffic patterns associated with known or suspected attacks.
CASB / Cloud Controls
Apply visibility and policy to cloud application usage.
DLP
Detect and control sensitive information leaving approved boundaries.

TLS Inspection Requires Deliberate Design

Encrypted traffic can limit the visibility available to security controls. Where an organisation chooses to perform TLS inspection, the architecture must account for certificate deployment, application compatibility, privacy requirements, performance overhead and regulatory or organisational policy.

TLS inspection should therefore be treated as a deliberate security control rather than an assumption that every encrypted session should automatically be decrypted and inspected.

Choosing the Enforcement Path

SOURCE
User / Branch
SD-WAN
Path
SASE
Policy
INSPECT
Controls
DESTINATION
Internet / SaaS

The ideal path is therefore not necessarily the shortest network path. It is the path that satisfies the combined requirements of connectivity, security, application performance and organisational policy.

Resilience is equally important. Distributed security introduces dependencies on SASE enforcement locations, Internet connectivity and cloud security services. Organisations should therefore consider availability, alternate enforcement locations, failure behaviour and what traffic should happen when a preferred security path is unavailable.

The engineering model for this section can be summarised as: DIRECT CONNECTIVITY → SECURITY ENFORCEMENT → INSPECTION → POLICY DECISION → DESTINATION. The goal is secure, observable access without introducing unnecessary traffic detours.

SECURE INTERNET ACCESS

SD-WAN Secure DIA / Internet Breakout Explorer

Direct Internet Access moves traffic closer to cloud and SaaS applications. The security question is what controls should protect that traffic before it reaches the Internet.
01
Branch / User
Traffic source
›
02
SD-WAN Edge
Classify + steer
›
03
DIA
Direct breakout
›
04
SASE PoP
Security enforcement
›
05
Internet / SaaS
Protected destination

Branch / User

A branch or remote user generates traffic destined for an Internet or SaaS application. Identity, device and application information can accompany the request.

Active security path: DNS Security → Firewall → URL Filtering → Identity Policy

Choose the Traffic Type

Trusted SaaS Known business application with validated identity and normal risk.
General Web Internet browsing subject to DNS, URL and firewall controls.
High-Risk Destination Destination has elevated reputation or policy risk.
Current path: Trusted SaaS traffic → direct Internet access → normal security inspection → ALLOW.

Secure Internet Access & SASE Enforcement

ENGINEERING FOCUS · 04
Behaviour, Analytics & Adaptive Security
ADAPT
ENGINEERING QUESTION What happens when a previously trusted user, device or flow begins behaving differently?
NORMAL Expected behaviour
→
TELEMETRY Signals change
→
ANALYSE Correlate risk
→
ADAPT Change enforcement
IDENTITY DEVICE POSTURE TRAFFIC PATTERN DESTINATION ERRORS RISK SCORE
THIS SECTION EXAMINES

Behavioural telemetry, anomaly detection, trust scoring, correlated signals, adaptive policy, isolation and the feedback loop between networking and security operations.

INTERACTIVE LAB SD-WAN SASE Through Behaviour-Driven Trust

Section 04 — Behaviour, Analytics & Adaptive Security

A secure SD-WAN and SASE architecture cannot depend entirely on decisions made when a user first authenticates or when a device initially connects. Conditions change. Devices lose compliance, identities become compromised, applications behave differently and traffic patterns can move outside their expected baseline.

Behavioural analytics and continuous telemetry provide the feedback required to recognise those changes. Instead of treating trust as a permanent state, the architecture can continuously evaluate whether the current behaviour still satisfies policy and adjust enforcement when the risk changes.

From Static Trust to Continuous Evaluation

Authentication establishes an important identity signal, but it does not guarantee that every action performed by that identity is legitimate. A valid account can be compromised, a trusted endpoint can become infected, or a legitimate session can begin behaving in a way that is inconsistent with normal activity.

Continuous evaluation introduces additional signals into the security decision. These can include authentication events, device posture, application activity, destination changes, traffic volume, connection frequency, error rates and other behavioural indicators.

CONTINUOUS TRUST MODEL
Identity + Device + Application + Network Telemetry + Behaviour = Current Risk Context

What Behavioural Analytics Looks For

Behavioural analysis does not necessarily mean that one unusual event is automatically treated as an attack. Useful detection normally comes from combining multiple signals and comparing activity against expected behaviour, policy thresholds or known threat indicators.

ACTIVITY RATE
Is the frequency or volume of activity significantly different from the expected pattern?
DESTINATION
Is the identity communicating with destinations that are unusual or outside policy?
ERROR PATTERN
Are repeated failures, authentication errors or connection attempts appearing?
DEVICE STATE
Has the security posture or management state of the endpoint changed?
IDENTITY
Are there identity changes, unusual authentication patterns or impossible combinations of signals?
FLOW PATTERN
Does the traffic pattern remain consistent with the application's expected behaviour?

Correlation Is More Valuable Than a Single Alert

A single unusual event may have a legitimate explanation. A user accessing a new application, for example, is not automatically evidence of compromise. The risk becomes more meaningful when multiple independent signals occur together.

IDENTITY
Change
+
DEVICE
Posture
+
BEHAVIOUR
Anomaly
Correlated signals can produce a stronger risk assessment than any individual event.

Risk Is a Signal, Not the Final Decision

A risk score or behavioural anomaly should not automatically become a block action. Security policy determines how the organisation responds to the assessed risk. A moderate anomaly may justify additional authentication or monitoring, while a combination of severe signals may justify restricting or isolating the session.

MONITOR
Continue access while increasing visibility and observation.
STEP-UP
Require stronger verification before permitting continued access.
RESTRICT
Reduce permissions or limit access to lower-risk resources.
ISOLATE
Contain the user, device or flow when the risk warrants stronger action.

Adaptive Security Changes the Policy State

Adaptive security means that policy can change when the underlying conditions change. A session does not necessarily remain in the same enforcement state for its entire lifetime.

NORMAL
Trusted activity
→
MONITORED
Risk emerging
→
RESTRICTED
Elevated risk

Telemetry Connects Networking and Security Operations

One of the strengths of a combined SD-WAN and SASE architecture is the amount of telemetry available across the environment. Network performance, application behaviour, identity events and security detections can be correlated rather than investigated as completely separate data sources.

For example, an application slowdown might initially appear to be a network problem. Telemetry could reveal that the traffic pattern changed at the same time as a new destination was contacted and an identity risk signal appeared. The incident then becomes a security investigation rather than simply a path-performance issue.

This correlation is particularly valuable to security operations because it provides a broader view of what happened before, during and after a policy change.

Closing the Feedback Loop

The architecture introduced throughout this guide is therefore not a one-way traffic pipeline. It is a feedback system. Connectivity produces telemetry. Security controls produce detections. Identity systems produce context. Behavioural analytics correlate those signals. Policy then determines whether the current treatment should remain unchanged or be modified.

CONNECT
Move traffic
OBSERVE
Collect signals
ANALYSE
Assess risk
ADAPT
Change policy

The resulting model is CONNECT → DECIDE → ENFORCE → ADAPT. SD-WAN provides the intelligent connectivity foundation, SASE extends security enforcement toward users and applications, and continuous telemetry allows the architecture to respond when the assumptions behind an access decision change.

Engineering Lab · 04 · Adaptive Security

Behaviour, Analytics & Adaptive Security

Observe a trusted session as its behaviour changes. Correlate identity, device, traffic and destination signals, then determine when policy should adapt.

LIVE TELEMETRY
◎
Identity
Normal session
◈
Device Posture
Compliant
↗
Traffic Pattern
Baseline
⌁
Destination
Trusted SaaS
Behavioural Risk Over Session
BASELINE
00:00
User authenticated successfully. Session trust established.
Composite Risk
18
LOW
Identity 10
Device 5
Behaviour 2
Destination 1
Advance the investigation to observe how the trust state changes.
Trust is continuous.
A session that was acceptable at authentication time may require stronger controls later when identity, device posture, behaviour, destination or other risk signals change.
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```