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.
PrefixesUPDATEsPolicyAttributesRIBFIB
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.
FOUNDATIONARCHITECTUREPROPAGATIONDECISION
☕
Support Network Insight
Help support the development of interactive networking labs,
BGP simulations, and educational content.
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.
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-AAS 65001Established
ISP-BAS 65002Established
ISP-CAS 65003Established
Enterprise R1AS 650103 BGP Neighbours
Remote NetworkAS 6502010.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 65001Provider
Internet connectivity and external reachability
AS 65002Transit
Provides connectivity between other networks
AS 65010Enterprise
Owns internal infrastructure and routing policy
AS 65020Cloud
Hosts services and advertises reachable prefixes
BGP
InterdomainREACHABILITY
01 · IndependenceEach AS operates its own network
Infrastructure, addressing, routing policy and operational decisions remain under the control of the organisation operating the AS.
BGP speakers exchange reachability information across AS boundaries so destinations can become reachable through neighbouring networks.
03 · ReachabilityPrefixes describe destinations
BGP advertises IP prefixes and associated path information rather than carrying the user packets themselves.
04 · PolicyEach 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
R1AS 65010Internal
R2AS 65010Core Router
R3AS 65010BGP Edge
ISPAS 65001eBGP
Remote Prefix10.10.10.0/24External
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
eBGP
IGP
IGP
IGP
iBGP
iBGP
eBGP
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.
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_PATHPath through autonomous systems
NEXT_HOPNext-hop information
LOCAL_PREFLocal routing preference
MEDMulti-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.
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.
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_PREF200
AS_PATH65001 65020
MED50
ORIGINIGP
Path B
Candidate
10.10.10.0/24
LOCAL_PREF150
AS_PATH65002 65020
MED20
ORIGINIGP
Path C
Candidate
10.10.10.0/24
LOCAL_PREF100
AS_PATH65003 65020
MED10
ORIGINIGP
01
PolicyApply local routing policy
02
WeightPrefer higher local weight
03
Local PreferencePrefer higher local preference
04
AS PathCompare path length
05
MED / Tie-breakersContinue until one path wins
WEIGHTLocal router preference where supported.
LOCAL_PREFControls preferred exit from the AS.
AS_PATHProvides path information and loop prevention.
ORIGINRanks how the route was originated.
MEDCan 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 Hop192.0.2.1
Weight0
Local Preference100
AS Path65002 65010
MED50
Learned viaeBGP
PATH B
CANDIDATE
Next Hop192.0.2.5
Weight0
Local Preference200
AS Path65003 65010
MED100
Learned viaeBGP
PATH C
CANDIDATE
Next Hop192.0.2.9
Weight0
Local Preference150
AS Path65004 65010
MED20
Learned viaeBGP
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:
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.
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.
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.
Diagram: Displaying the different firewall types.
Related: Additional links to internal content for pre-information:
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.
♦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.
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.
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.
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.
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,
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
♦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.
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.
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.
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.
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.
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.
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.
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.
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.
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 securitytells 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
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.
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.
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.
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.
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.
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.
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.
CloudLock Security Domains — Select a Domain
Cloud Security Workflow
01Visibility
02Analysis
03Policy
04Response
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:
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.
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.
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?
WHAT NEXT?
What policy or security response should follow?
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:
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.
2. Decision Chain
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.
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.
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:
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.
EthernetARP / NDPSwitchingRouting
Interactive Lab
Packet & Protocol Explorer
02
Addressing, Transport & Security
→
Follow the dependencies between addressing, neighbour discovery, ACLs, firewalls, NAT, MTU and transport.
IPv4 / IPv6TCP / UDPACLNAT
Interactive Lab
Connectivity Decision Engine
03
Routing & Network Fabric
→
See how routing protocols become forwarding state and how VRFs, overlays and fabrics extend connectivity.
OSPFIS-ISBGPVXLAN / EVPN
Interactive Lab
Routing & Fabric Explorer
04
Cloud-Native Networking
→
Trace traffic through namespaces, veth pairs, CNI networking, datapaths, services and policy.
KubernetesCNIOVSNetworkPolicy
Interactive Lab
Cloud-Native Network Explorer
05
Connectivity Investigation
→
Investigate an unreachable application by proving where the connectivity chain breaks and why.
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 DecisionREADY
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 TelemetryPACKET STATE
10.10.10.10
10.20.20.20
—
—
—
Application
Packet LifecycleWAITING
01Application
02TCP
03IPv4
04ARP
05Ethernet
06Switch
07Router
08Route
09New L2
10Server
11TCP
12Application
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 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:
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 / Domain
Primary Function
Typical Technologies
Endpoint
Generates and receives traffic
OS networking, sockets, NIC
Access
Provides local attachment
Ethernet, Wi-Fi, VLAN
Switching
Moves frames within Layer 2
MAC tables, 802.1Q, STP
Routing
Selects Layer 3 paths
OSPF, IS-IS, BGP, static routes
Segmentation
Separates routing domains
VRF, VLAN, tenant networks
Security
Applies traffic policy
ACL, firewall, security groups
Transport
Establishes communication
TCP, UDP, QUIC
WAN / Cloud
Extends connectivity domains
VPN, SD-WAN, VPC, transit
Platform
Connects workloads
Kubernetes, CNI, service networking
Application
Provides the actual service
HTTP, 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.
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.
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 PlaneWhich routing information is available?
OSPFEvaluating
Interior Path
Provides an internal route toward the destination network.
BGPWaiting
Policy Path
Candidate path carries policy attributes and an AS path.
IS-ISWaiting
Fabric Path
Underlay reachability provides transport between fabric nodes.
02 · Routing StateControl-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 ForwardingUnderlay transport + overlay tenant reachability.
LEAF-01Ingress
Host Attachment
VLAN 120 · VNI 10120
SPINE-01Underlay
IP Transport
ECMP next hop
LEAF-02Egress
VTEP Decapsulation
VNI 10120 → VLAN
SERVEREndpoint
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 · WorkloadApplication starts inside a network namespace.
POD-01Active
frontend-7c9f
10.244.1.20 · TCP/8080
NETNSAPPTCP
POD-02Target
api-65d4
10.244.2.31 · TCP/8080
NETNSBACKENDREADY
02 · Node NetworkingTraffic 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 DeliveryCluster 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.
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
Symptom
First Investigation
Interface down
Physical / virtual interface state
Same-subnet host unreachable
VLAN, MAC learning, ARP/NDP
Gateway unreachable
Local addressing, VLAN, neighbour resolution
Remote subnet unreachable
Routing table, next hop, return path
Ping fails
Routing, ICMP policy, Layer 2/3
Ping works, TCP fails
Firewall, ACL, service, NAT
TCP connects, application fails
TLS, DNS, authentication, application
Small packets work, large packets fail
MTU, MSS, PMTUD
One direction works
Asymmetric routing, stateful firewall
Intermittent connectivity
ECMP, packet loss, unstable control plane
IPv4 works, IPv6 fails
NDP, RA, IPv6 routing, IPv6 policy
Pod-to-Pod fails
CNI, routes, NetworkPolicy
Pod works locally but not externally
Service, ingress, node routing, cloud policy
Cloud one-way connectivity
Return routes, security groups, NACLs, transit
Application suddenly degraded
Control-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.
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
ENGINEERING GUIDE · INVESTIGATION PATH
From Packet to Verified Security Decision
Follow the traffic, inspect the evidence, investigate the failure,
then verify the security control.
4 ENGINEERING STAGES
Learning path
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 · PACKETTraffic arrives
Source, destination, protocol and port information enter the security device.
02 · CONTEXTSecurity zone
Interface and zone information establish the security context.
03 · STATEFlow identified
The firewall determines whether the connection already exists.
04 · POLICYAccess 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.
Source10.20.10.25
Destination172.16.20.50
ProtocolTCP / HTTPS
Ports49152 → 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
Inside → Outside
▶
◆
STATEFUL FIREWALL
FW-EDGE-01
Inside: 10.20.0.1
Outside: 198.51.100.10
NAT / Egress
▶
▣
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
RuleOUT-HTTPS-01
Source zoneINSIDE
DestinationWEB / 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 metadatapayload
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 · INPUTPacket
Raw network traffic enters the inspection path.
02 · DECODEDecoder
Protocol headers and packet structure are interpreted.
03 · CONTEXTFlow / Session
Traffic is associated with the relevant connection.
04 · PROTOCOLInspector
Application and protocol behaviour can be examined.
05 · RULESRule Matching
Detection logic is evaluated against the observed traffic.
06 · DETECTDetection
A security condition may be identified.
07 · ACTIONIPS Action
Alert, allow, drop or another configured response is applied.
08 · EVIDENCETelemetry
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.
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 · CLIENTEndpoint
What did the client actually send and receive?
02 · FIREWALLFlow
Did the firewall recognise and track the session?
03 · POLICYAccess
Which security rule handled the connection?
04 · NATTranslation
Was the source or destination transformed?
05 · IPSInspection
Did deeper inspection identify a security condition?
06 · APPApplication
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.
01Identify
Isolate one failed transaction and its exact flow tuple.
02Correlate
Match the transaction across security telemetry sources.
03Compare
Compare successful and failed requests for meaningful differences.
04Prove
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.
“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 · DETECTIdentify the signal
A firewall, IPS, endpoint or network control produces an event.
Output: security signal
02 · CORRELATEAdd context
Relate the event to flows, users, applications, timestamps and other
telemetry.
Output: evidence set
03 · DECIDEAssess the risk
Determine whether the event represents a real threat, expected
behaviour or a false positive.
Output: action decision
04 · PREVENTApply control
Enforce the appropriate policy, inspection or containment response.
Output: changed traffic state
05 · VERIFYProve 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.
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.
01Retest traffic
Reproduce the relevant flow after the control change.
02Check telemetry
Confirm logs, counters, events and state reflect the expected result.
03Check application
Verify that legitimate application behaviour remains functional.
04Confirm 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.
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.
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.
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.
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.
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 Progress12%
Live Security Readout
SourceWEB-01
DestinationAPP-01
TrafficHTTPS / TCP 443
Trust StateUnknown
ActionClassify
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 classificationWEB EPG
Application relationshipHTTPS
Security contextTrusted
EnforcementPermit
Policy Engine Decision
ALLOW
Expected WEB → APP HTTPS communication matches the security policy.
Risk Score18 / 100
Decision Evidence
Source GroupWEB
DestinationAPP
ApplicationHTTPS
IdentityWeb Role
ContextTrusted
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 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:
Traffic
Security approach
WEB → APP
Application-aware inspection
APP → DB
Restricted database traffic
Monitoring → Workload
Permit required telemetry
Backup → Storage
Permit approved backup services
Unknown → Production
Deny
Quarantined → Application
Restrict
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.
Layer
Question
Endpoint
What is communicating?
Group
What security class does it belong to?
Contract
Are these groups allowed to communicate?
Filter
Which traffic is permitted?
Redirect
Does the flow require a service?
Inspection
Does deeper security analysis occur?
Telemetry
What 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.
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
SourceWEB-01
DestinationAPP-01
ProtocolHTTPS / 443
Current NodeWEB
Next FunctionACI 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:
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
SourceWEB-01
DestinationAPP-01
ProtocolHTTPS / 443
IdentityWeb Role
BehaviourExpected
Incident Timeline
Detection → Response
T+00:00Normal WEB → APP traffic
T+00:18New east-west behaviour observed
T+00:24WEB → DB connection attempted
T+00:27Identity / behaviour mismatch detected
T+00:31Risk score crosses investigation threshold
T+00:34Security policy blocks lateral movement
T+00:38Incident response initiated
T+00:42WEB-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.
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.
TraditionalPassword
ModernAuthentication
ContextIdentity + Device
DecisionRisk + 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.
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.
ENGINEERING GUIDE · IDENTITY SECURITY
Identity Security Engineering Guide
Navigate the guide from identity foundations through
adaptive access, enforcement and identity threat response.
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
IDENTITYwho exists?
AUTHENTICATEprove identity
MFAincrease assurance
DEVICEassess posture
WORKLOADservice identity
SIGNALgenerate 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.
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 Score100 / 100
Policy Explanation
Identity is authenticated with strong MFA, the device is healthy,
context is expected and current behaviour risk is low.
IdentityStandard User
ApplicationStandard
ContextExpected
RiskLow
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.
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
01IDENTITY
02TOKEN
03POLICY
04ENFORCE
05APPLICATION
06AUDIT
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.
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
01OBSERVE
02CORRELATE
03INVESTIGATE
04CONTAIN
05REVOKE
06RECOVER
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.
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.
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.
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. CiscoTalos 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:
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.
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.
**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
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.
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 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 & 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.
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.
01USER
02DEVICE
03NETWORK
04CLOUD / INTERNET
05APPLICATION
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
Applicable Security Controls
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.
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.
IDIdentity
User, service account or workload identity making the request.
DVDevice
Device posture, management state, security controls and compliance.
CXContext
Location, time, network characteristics, application and request context.
RKRisk
Signals indicating unusual, suspicious or potentially compromised behaviour.
PLPolicy
Rules defining which combinations of signals should permit access.
ENEnforcement
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.
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:
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
01IDENTITY
02DEVICE
03CONTEXT
04RISK
05POLICY
06DECISION
Identity State
Verified
Device Posture
Healthy
Context
Normal
MFA Signal
Passed
Application
Standard
Privilege
Normal
Calculated Access Risk
10
LOWMODERATEHIGHCRITICAL
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?
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
DNSDNS Security
Blocks or redirects access to known malicious or prohibited destinations.
Early destination control
SWGSecure Web Gateway
Applies security policy to web and Internet traffic.
Web security enforcement
FWFWaaS
Applies distributed firewall policy to network traffic.
Network policy enforcement
CASBCASB
Provides visibility and policy controls for cloud applications.
Cloud application control
DLPDLP
Evaluates sensitive information against data protection policy.
Data protection
ZTZTNA
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.
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?
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.
Device posture, endpoint alerts, process activity and security-control status.
DNSDNS Activity
Domain queries, blocked destinations, threat classifications and unusual lookup behaviour.
NETNetwork Flows
Source, destination, application, transport and traffic-volume information.
APPApplication Events
SaaS activity, private-application access and application-level policy events.
POLPolicy 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.
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.
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.
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.
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
UserExperience
→
L
LAN / Wi-FiLocal access
→
I
ISPInternet path
→
S
SASE PoPSecure edge
→
C
CloudProvider path
→
A
ApplicationResponse
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
EndpointIs the user actually connected normally?
NetworkWhere does latency or loss first increase?
SASEIs the selected service edge healthy?
CloudIs the destination path behaving normally?
ApplicationDoes 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 AgentUser experience
EN · Enterprise
Enterprise AgentSite visibility
CA · Cloud
Cloud AgentCloud / 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 AgentUser experience · Wi-Fi · LAN · path
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 incidentUsers in one location report increased application response time. The application is reachable, but transactions are slow.
01Endpoint
Wi-Fi / device
→
02LAN
Gateway / access
→
03ISP
Internet path
→
04SASE PoP
Secure edge
→
05Cloud / 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 ScenarioMicrosoft 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
IdentityAuthentication and user context establish access.
SD-WANConnectivity determines the available transport path.
ISPInternet performance influences the underlay.
SASE PoPThe security edge processes and forwards traffic.
DNSName resolution can influence application reachability.
SaaSExternal services may use distributed delivery networks.
ApplicationThe 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.
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 · FABRICSecure the architecture
02 · POLICYControl access
03 · ENFORCEMENTInspect the flow
04 · OPERATIONSDetect & respond
Network Insight · Engineering Guide
SD-WAN Security Engineering Map
Navigate the guide from secure fabric architecture through traffic protection, enforcement and continuous response.
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?
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.
01Device Identity
02Authentication
03Control Plane
04Policy & Routes
05Secure 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 IdentityUse strong authentication and appropriate MFA for privileged management access.
Role-Based AccessSeparate operational responsibilities so users receive only the permissions required for their role.
Configuration ControlTrack policy changes, configuration versions and administrative activity.
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?
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.
01Identity
02Application
03Segment
04Context
05Policy
06Secure 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.
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?
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.
01Branch User
02SD-WAN Edge
03Security Controls
04DIA Breakout
05Internet / 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.
01Classify
02Firewall
03DNS / Web
04Threat Inspect
05Internet
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.
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?
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.
01Identity
02Device State
03Flow
04DNS / Web
05Security Alert
06Policy Change
07Response
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:
01Observe
02Investigate
03Decide
04Enforce
05Measure
06Refine
07Repeat
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.
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 Guide · Navigation
SD-WAN & SASE
Follow the architecture from connectivity through policy decision,
security enforcement and adaptive response.
ENGINEERING QUESTIONHow 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.
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 QUESTIONHow 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?
POLICYDECISION
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 LABSD-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.
APPLICATIONSaaS
IDENTITYValidated
DEVICECompliant
LATENCY28 ms
LOSS0.2%
RISKLow
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 QUESTIONWhen 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
DNSFIREWALLIPSURL FILTERCASB / DLPTLS 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 LABSD-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 SaaSKnown business application with validated identity and normal risk.
General WebInternet browsing subject to DNS, URL and firewall controls.
High-Risk DestinationDestination 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 QUESTIONWhat happens when a previously trusted user, device or flow begins behaving differently?
Behavioural telemetry, anomaly detection, trust scoring, correlated signals,
adaptive policy, isolation and the feedback loop between networking and security operations.
INTERACTIVE LABSD-WAN SASE Through Behaviour-Driven Trust
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.
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
Correlated Behaviour Signals
◎
Identity
Normal session
◈
Device Posture
Compliant
↗
Traffic Pattern
Baseline
⌁
Destination
Trusted SaaS
Behavioural Risk Over Session
BASELINE
Investigation Timeline
00:00
User authenticated successfully. Session trust established.
Adaptive Risk Engine
Composite Risk
18
LOW
Identity10
Device5
Behaviour2
Destination1
Choose Adaptive Response
Advance the investigation to observe how the trust state changes.
Engineering Principle
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.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.