Enterprise Isometric Internet security firewall protection information

Network Security Components

ENGINEERING GUIDE · NETWORK SECURITY

Network Security Components — From Isolated Controls to an Integrated Security Fabric

Modern network security is not a single appliance or perimeter. It is a coordinated system of identity, access control, segmentation, inspection, endpoint protection, cloud controls, telemetry and response. The engineering challenge is understanding how these components work together to make — and validate — security decisions.

!
Engineering Observation A security component is only useful when we understand the decision it makes, the evidence it uses, where it is enforced, and how it connects to the rest of the architecture.
01 · IDENTITY

Establish Trust

Determine who or what is requesting access and establish the context required for a security decision.

02 · CONTROL

Enforce Policy

Apply authentication, authorization, ACLs, firewalls and segmentation to control permitted communication.

03 · INSPECT

Detect Threats

Inspect traffic, applications, endpoints and behaviour using IDS/IPS, NDR, WAF and endpoint controls.

04 · CORRELATE

Drive Response

Combine identity, network, endpoint and application telemetry so suspicious behaviour can be investigated and acted upon.

Security Decision Flow
IDENTITY
→
ACCESS
→
SEGMENT
→
INSPECT
→
PROTECT
→
OBSERVE
→
RESPOND
Engineering View

A security architecture is a decision system, not simply a collection of security appliances.

Identity Device Network Application Data Telemetry
Core Engineering Question

Can we prove that every security decision is intentional, visible and connected to the rest of the defence system?

Components Covered
Firewalls IDS / IPS NDR Identity NAC Segmentation EDR / XDR DLP VPN ZTNA SWG DNS Security CASB SIEM SOAR SASE
Interactive Security Architecture

Network Security Components

Security is not a single firewall. Modern protection combines identity, segmentation, inspection, endpoint controls and centralized intelligence. Select a layer to see its role in the security architecture.

Architecture Status
● DEFENDED
01
ID
Identity
Authentication, MFA and authorization
02
AC
Access Control
AAA, NAC and policy enforcement
03
FW
Firewall
Stateful inspection and filtering
04
SG
Segmentation
Macro and micro-segmentation
05
ID
IDS / IPS
Detection and threat prevention
06
EP
Endpoint
EDR, malware and workload security
07
SI
SIEM / SOAR
Correlation, visibility and response
Selected Component
Identity Security
Identity becomes the first security decision. Authentication verifies who or what is requesting access, while authorization determines what that identity is permitted to access.
MFA AAA Zero Trust Authorization
Security Mode
Protection Coverage 86%
Identity
OK
Firewall
ON
IDS
ON
SIEM
LIVE
Interactive Network Security Component

Firewall & Security Placement Explorer

Security controls work best when each layer protects a different part of the attack surface. Explore where firewalls, IDS/IPS, segmentation and application controls fit into a modern security architecture.
External
→
Perimeter
→
Internal
→
Workload
REQUEST
INSPECT
ENFORCE
WORKLOAD
FW
Firewall
Policy enforcement point

Controls traffic according to security policy and creates an enforcement boundary between trusted and untrusted zones.

Primary role Allow / deny traffic
Visibility Flows, sessions and policy
Placement Internet / internal boundary
Security value Defense in depth
SECURITY DECISION
A firewall should enforce the policy at the boundary where traffic crosses security zones.

Why placement matters

A single perimeter firewall cannot provide complete protection once an attacker reaches the internal network. Additional controls reduce lateral movement and protect individual workloads and applications.

MACRO

Protects larger network zones such as Internet, DMZ, user and server segments.

MICRO

Applies granular controls around individual workloads, applications or identities.

INTERACTIVE SECURITY ARCHITECTURE

How the Security Components Connect

Select an architectural layer to see the security decision it makes, the evidence it requires and the controls commonly deployed there.

ARCHITECTURE ACTIVE
Security Decision Chain · Select a Layer
LAYER 01 · TRUST

Identity Security

Identity establishes the context behind a connection. Modern security decisions increasingly consider the identity, device and session rather than relying only on network location.

Who is requesting access?
Identity, authentication state, device and session context
Authentication establishes identity; authorization determines what that identity may access.
MFA AAA RBAC ZTNA
Architecture Model
LAYERED
Primary Objective
CONTROL
Evidence Model
CORRELATED
SECTION 01 · DEFINE · TRUST BOUNDARY LAB

Map the Security Decision

A security architecture starts by understanding the relationship between the requester, the identity context, the destination and the boundary where policy is enforced. Change the variables and observe how the decision path changes.

Source
Identity Context
Destination
Boundary
Engineering Principle

Trust should be explicit. The network location alone should not automatically determine whether a request is safe.

01 · Source
Remote User Request origin
→
02 · Identity
Trusted Identity Authentication context
→
03 · Boundary
Identity-Aware Access Policy enforcement
→
04 · Destination
Internal Application Requested resource
Authenticated
Trusted posture
Application resource
Identity-aware enforcement
Low contextual risk
Least privilege
ALLOW
Identity, device and destination context provide sufficient evidence for the requested application access.
Decision Confidence 88%
16:00:01 [ARCH] Security decision engine initialised.
16:00:02 [AUTH] Identity context available.
16:00:03 [POLICY] Waiting for scenario evaluation.
ENGINEERING MODEL · NETWORK SECURITY

Security Is a System of Connected Decisions

Modern network security is not one firewall or one perimeter. It is a coordinated system in which identity, access, segmentation, inspection, protection and telemetry work together to control communication and reduce the attack surface.

01 · IDENTITY Establish Trust Understand who or what is requesting access and the context surrounding the request.
02 · CONTROL Enforce Policy Apply authentication, authorization, firewall and access policies at the appropriate boundary.
03 · INSPECT Understand Traffic Inspect network and application behaviour to identify unwanted or suspicious activity.
04 · CORRELATE Drive Response Combine security evidence so decisions can be investigated, explained and acted upon.
Identity
→
Access
→
Segmentation
→
Inspection
→
Protection
→
Telemetry
→
Response
01 · DEFINE · SECURITY ARCHITECTURE

Security Architecture & Trust Boundaries

Security begins by defining what is trusted, what is exposed, what is being accessed and where security decisions are enforced. The objective is not simply to deploy more controls, but to place the right control at the right point in the communication path.

A modern environment may contain users, endpoints, workloads, cloud services, branches and applications distributed across multiple networks. These systems cannot be protected effectively by treating the traditional Internet edge as the only security boundary.

Instead, security architecture creates a series of decision points. Identity establishes context, access controls determine whether communication should proceed, segmentation limits the reachable attack surface, and inspection and protection controls examine what happens after access has been permitted.

The security decision path

From request to protected workload
01 Identity Who is requesting?
→
02 Access What is permitted?
→
03 Segmentation Where can it go?
→
04 Inspection What is happening?
→
05 Protection What must be protected?
→
06 Telemetry What evidence exists?

Where are the trust boundaries?

A trust boundary is the point where the security assumptions about a connection, identity, device or workload change. The boundary may exist between the Internet and an organization, between a user and an application, between network segments or directly around an individual workload.

01 · EXPOSURE External Environment Internet users, remote systems, third-party services and other untrusted sources represent the outer attack surface.
02 · ACCESS Identity & Policy Authentication, authorization and contextual policy determine whether a request should receive access.
03 · ENFORCEMENT Security Boundary Firewalls, segmentation, access controls and inspection points enforce the architecture's security policy.
04 · ASSET Application & Data The final objective is protecting workloads, applications and data while preserving legitimate communication.

Four questions every architecture should answer

01
Who is requesting? Identify the user, device, workload or service and establish the relevant context.
02
What should be allowed? Determine which application, destination, service or resource the requester is permitted to access.
03
Where is it enforced? Place enforcement at an appropriate network, identity, workload or application boundary.
04
How do we know? Generate sufficient telemetry to explain the decision and investigate unexpected behaviour.
Engineering evidence
A security boundary must have a decision behind it

Simply placing a firewall, NAC system or segmentation control between two networks does not automatically create effective security. The architecture should identify what the boundary protects, what policy governs communication across it, what evidence supports the decision and what happens when the expected behaviour changes.

Security components form layers, not isolated products

Identity Layer
Establish context
Authentication, MFA, authorization and identity-aware policy establish who or what is requesting access.
Network Layer
Control reachability
Firewalls, ACLs, NAC and segmentation restrict which systems, networks and services can communicate.
Workload Layer
Protect the asset
Endpoint, application, workload and data controls provide protection closer to the resource being accessed.
Inspection Layer
Understand behaviour
IDS/IPS, NDR and application-aware inspection provide deeper visibility into traffic and behaviour.
Data Layer
Protect information
Encryption, DLP and application controls help protect sensitive data as it moves through the environment.
Intelligence Layer
Correlate evidence
Telemetry, SIEM and response workflows connect individual security signals into an operational picture.
Section 01 · Engineering Principle
A security architecture is a decision system, not a collection of appliances.

The strongest architectures make the security decision path explicit: identify the requester, understand the resource, determine the required level of trust, enforce policy at the appropriate boundary and generate evidence that allows the outcome to be verified. The remaining security components in this guide build on that foundation.

01 · DEFINE · SECURITY ARCHITECTURE

Security Architecture & Trust Boundaries

Step through a security decision from identity to enforcement and observe where trust is established, where policy is applied and where evidence is generated.
Ready
Live Security Decision Path
0 / 6
◉
USER
Identity
Request
◎
IDENTITY
Authentication
Trust
◇
ACCESS
Policy
Authorization
▣
WORKLOAD
Application
Data
Architecture principle: security is not one control. A request moves through multiple decision points where identity, context, policy and enforcement can each change the outcome.
Architecture Inspector
Click an architecture component to inspect its security responsibility.
Security Role
Current decision
Identity Unknown
Device trust Unknown
Authorization Pending
Enforcement Pending
Evidence None
Control Health
Live
IDENTITY
Authentication
READY
ACCESS
Authorization
READY
ENFORCEMENT
Policy control
READY
Decision Evidence
Live
Signal Value
Identity Pending
Device Pending
Policy Pending
Outcome Pending
Security Decision Timeline
Identity → enforcement
01
IDENTITY
User presents an identity to begin the access request.
02
AUTH
Authentication verifies whether the claimed identity can be trusted.
03
CONTEXT
Device and request context are evaluated before authorization.
04
POLICY
Authorization determines what the authenticated identity is permitted to access.
05
ENFORCE
A network, application or workload control enforces the decision.
06
EVIDENCE
Telemetry records the decision so it can be investigated later.
Architecture Telemetry
Live interpretation
Current Event
Press Step Forward to begin
Investigation Progress
Engineering takeaway: a security architecture should connect identity, policy, enforcement and telemetry rather than treating each control as an isolated product.
ENGINEERING MODEL · ACCESS CONTROL

Control Who Can Communicate With What

Access control turns security architecture into enforceable policy. Authentication establishes identity, authorization determines what that identity may access, and network controls enforce those decisions at appropriate boundaries.

01 · AUTHENTICATE Verify identity Establish that the user, device, workload or service is who it claims to be.
02 · AUTHORIZE Determine access Decide which resources, applications and services the requester is permitted to use.
03 · ENFORCE Apply policy Use ACLs, firewalls, NAC and other controls to enforce the security decision.
04 · ACCOUNT Record evidence Maintain useful audit and telemetry information so access decisions can be investigated later.
Identity
→
Policy
→
Firewall / ACL
→
Application
→
Audit
02 · CONTROL · ACCESS & FIREWALL ENFORCEMENT

Access Control & Firewall Enforcement

Once the security architecture defines its trust boundaries, the next requirement is enforcement. Access control determines who or what may communicate with a resource, while firewalls and related controls enforce that policy against actual network traffic.

This distinction is important. Authentication answers whether an identity has been established. Authorization answers what that identity is allowed to do. Enforcement is the point where the resulting policy is applied to a real connection, request or flow.

Effective access control therefore combines identity, context, policy and enforcement rather than relying on a single allow or deny rule.

From identity to enforcement

The access-control decision path
01 Identity User / Device / Workload
→
02 Authentication Establish identity
→
03 Authorization Determine permission
→
04 Enforcement Apply policy
→
05 Telemetry Record outcome

Authentication, authorization and accounting

AAA provides a useful conceptual model for access control. Authentication establishes identity, authorization determines permitted actions and accounting records relevant activity for auditing and investigation.

A · AUTHENTICATION
Who are you?
Credentials, certificates, MFA and other mechanisms can establish the identity of a user, device or service.
A · AUTHORIZATION
What can you do?
Policy determines which resources, applications, services or actions the authenticated identity is permitted to access.
A · ACCOUNTING
What happened?
Access and activity records provide evidence for auditing, troubleshooting and security investigation.

Where firewalls fit

Firewalls provide an enforcement point for network security policy. They can evaluate characteristics such as source and destination, protocol, ports, connection state and, depending on the platform, application or user context.

The important engineering question is not simply whether a firewall is present. It is whether the firewall is positioned where the required decision can actually be made and whether its policy matches the intended trust boundary.

Network enforcement
Packet & state policy
ACLs and stateful firewalls can control traffic according to addresses, protocols, ports and connection state.
Context-aware control
Identity & application
Modern platforms may combine network attributes with identity, application and other contextual information when enforcing policy.
Application boundary
WAF protection
A web application firewall focuses specifically on HTTP and HTTPS application-layer requests rather than acting as a general network firewall.

Good security policy is explicit

A well-designed policy should make its intent clear. The engineer should be able to identify the source, destination, service, identity or context where relevant, the expected action and the reason the communication is permitted.

01
Least privilege

Permit only the access required for the intended function. Broad connectivity should not become the default simply because it is operationally convenient.

02
Explicit policy

Rules should describe an intentional security requirement rather than becoming an accumulation of undocumented exceptions.

03
Context matters

Identity, device posture, application, location and risk can provide useful context beyond a simple source and destination address.

04
Evidence matters

Access decisions should generate sufficient telemetry to determine what was permitted, denied and why the decision occurred.

Engineering evidence
An allow rule is a security decision

Every permitted connection creates an exposure. The engineering task is therefore to understand why that connection is allowed, what boundary controls it, what identity or context is associated with it and how the resulting activity will be observed. Security policy should be explainable before it is deployed.

Access control becomes stronger when the layers agree

Identity should not have to operate independently from network policy. Authentication and authorization establish context, while firewalls, ACLs, NAC and segmentation provide enforcement. Endpoint and application controls add further protection closer to the resource.

This creates a layered model in which a single failure does not automatically provide unrestricted access to the rest of the environment. The architecture becomes progressively more difficult to bypass because different controls make different decisions at different points.

Section 02 · Engineering Principle
Authentication establishes identity. Authorization defines permission. Enforcement controls the communication.

Effective access control connects those three concepts with useful telemetry. The goal is not simply to create more rules, but to ensure that every important communication has an intentional policy, an appropriate enforcement point and enough evidence to explain the resulting decision.

02 · CONTROL · ACCESS & FIREWALL ENFORCEMENT

Access Control & Firewall Policy Builder

Build a security decision from identity, device context and destination. Step through the policy chain and see where authorization becomes enforcement.
Policy Ready
Live Policy Evaluation
0 / 6
Identity
Who is requesting access?
Device Trust
Can the endpoint be trusted?
Destination
What is being accessed?
◉
IDENTITY
Authentication
◇
CONTEXT
Device / Risk
▤
POLICY
Authorization
◈
FIREWALL
ACL / State
PENDING
Waiting for policy evaluation
Configure the request and press Step Forward.
Decision Inspector
Live
Identity Pending
Authentication Pending
Device Pending
Destination Pending
Decision Pending
Control Stack
Security enforcement
AAA / Identity
READY
Authentication verifies the security principal.
Authorization
READY
Identity and context are evaluated against policy.
Firewall / ACL
READY
The resulting decision is enforced on traffic.
Policy Evaluation Timeline
Identity → enforcement
01
IDENTITY
The request arrives with a claimed identity.
02
AUTH
Authentication verifies the identity.
03
CONTEXT
Device posture and destination are evaluated.
04
POLICY
Authorization calculates permit or deny.
05
FIREWALL
Firewall or ACL enforcement applies the decision.
06
OUTCOME
Access is either permitted or blocked.
Policy Telemetry
Live interpretation
Current Event
Configure a request and press Step Forward
Evaluation Progress
Engineering takeaway: authentication establishes identity; authorization determines permission; enforcement makes that decision real.
ENGINEERING MODEL · NETWORK SEGMENTATION

Contain the Attack Surface

Segmentation limits how far a user, device, workload or compromised system can communicate. Instead of treating the network as one trusted space, security boundaries divide it into controlled zones with explicit communication requirements.

01 · DEFINE Create zones Group systems according to function, trust level, sensitivity or business requirement.
02 · LIMIT Reduce reachability Prevent systems from communicating simply because they share network connectivity.
03 · CONTROL Permit required flows Define which applications, services and workloads are allowed to communicate across boundaries.
04 · CONTAIN Limit compromise A compromised system should have limited paths to other sensitive resources.
User Zone
→
Application Zone
→
Data Zone
→
Management Zone
03 · SEGMENT · CONTAIN THE ATTACK SURFACE

Network Segmentation & Workload Boundaries

Access control determines whether communication is permitted. Segmentation determines how much of the environment a system can reach in the first place. By creating explicit boundaries between systems with different trust, sensitivity or operational roles, the potential impact of a compromise can be reduced.

A flat network creates unnecessary reachability. If every endpoint, server and workload can communicate freely with every other system, a compromised device may have many possible paths toward more valuable resources.

Segmentation changes that model by introducing controlled boundaries. Communication between zones becomes intentional rather than an automatic consequence of network connectivity.

The segmentation model

Controlled communication between security zones
01 · USER User / Endpoint Zone Workstations, managed devices and user-facing systems that require controlled access to applications.
→
02 · APPLICATION Application Zone Business applications and services exposed only through the communication paths they actually require.
→
03 · DATA Data / Sensitive Zone Databases and sensitive resources protected behind additional policy and tightly controlled access paths.

Macro-segmentation and micro-segmentation

Segmentation can operate at different levels. Macro-segmentation creates larger security zones such as user, server, management and data networks. Micro-segmentation applies more granular policy around individual workloads, applications or groups of systems.

Macro-segmentation
Separate major trust zones
Large security boundaries provide a straightforward way to separate environments according to function, sensitivity or trust.
Example: User → Server → Database → Management
Micro-segmentation
Control workload-to-workload access
More granular controls can restrict communication between individual workloads or application tiers even when those workloads share an underlying network or cluster.
Example: Web Tier → API Tier → Database Tier

East-west traffic matters

Traditional perimeter security focuses heavily on north-south traffic entering or leaving an environment. Modern workloads also generate large amounts of east-west traffic between systems inside the environment.

If internal communication is implicitly trusted, an attacker who gains access to one workload may be able to move laterally toward other systems. Segmentation introduces additional policy decisions into this internal communication path.

Example workload boundary model
Tier 01 Web Front End Public-facing application component with controlled downstream access.
Tier 02 Application API Business logic reachable only from explicitly permitted application sources.
Tier 03 Database Sensitive data service with narrowly defined application access.
Tier 04 Management Administrative systems isolated from normal application traffic.

Segmentation requires explicit policy

01 · SOURCE Who initiates? Identify the system, workload, user or service generating the communication.
02 · DESTINATION What is reached? Determine which zone, workload, application or data resource is being accessed.
03 · SERVICE What is required? Define the protocol, port, application or service that actually needs to communicate.
04 · DECISION Should it cross? Permit only the communication required by the application's intended architecture.

Designing useful boundaries

01
Separate by sensitivity

Systems holding more sensitive information should not automatically inherit the same connectivity as ordinary workloads.

02
Separate by function

User, application, database and management systems often have different communication requirements and should be treated accordingly.

03
Minimise lateral paths

Restrict unnecessary east-west communication so compromise of one system does not automatically expose neighbouring workloads.

04
Make exceptions visible

Required cross-zone communication should be documented, intentional and observable rather than hidden inside broad connectivity rules.

Engineering evidence
Segmentation reduces reachability — it does not replace inspection

A segmentation boundary limits where traffic can travel, but it does not automatically determine whether permitted traffic is malicious. Segmentation therefore works alongside firewalls, identity controls, inspection and endpoint protection rather than replacing them.

Section 03 · Engineering Principle
Containment begins by controlling reachability.

A well-segmented environment assumes that connectivity should be intentional. Macro-segmentation establishes major trust boundaries, while micro-segmentation can provide more granular workload controls. Together they reduce unnecessary lateral paths and limit the potential impact of a compromised system.

ENGINEERING MODEL · THREAT INSPECTION

Inspect the Traffic That Crosses Your Boundaries

Segmentation controls where traffic can travel. Inspection determines what that traffic is doing. Modern security architectures combine prevention, detection, behavioural analysis and application-aware controls at appropriate points in the traffic path.

01 · FILTER Enforce policy Firewalls determine whether traffic matches an explicitly permitted communication policy.
02 · DETECT Identify threats IDS and NDR analyse traffic and behaviour for indicators of malicious or abnormal activity.
03 · PREVENT Block activity IPS can actively prevent traffic when configured detection and policy conditions are met.
04 · PROTECT Inspect applications WAF controls HTTP and HTTPS application traffic using application context rather than treating all traffic as generic packets.
Traffic
→
Policy
→
Detection
→
Prevention
→
Evidence
03 · SEGMENT · CONTAIN THE ATTACK SURFACE

Network Segmentation Investigation Lab

Follow a communication attempt across identity, access and workload boundaries. Change the segmentation policy and observe where the traffic is allowed or stopped.

SCENARIO Employee → Application
SEGMENTATION ENFORCED
STEP 0 / 6
LIVE SEGMENTATION TOPOLOGY Waiting for traffic
USER / ACCESS ZONE
WORKLOAD ZONE
USER
Employee
Trusted device
NAC
Identity + posture
SEGMENT
Policy enforced
WORKLOAD
Application zone
Traffic path: waiting for inspection
EVENT TIMELINE 0 events
ENGINEERING EVIDENCE LIVE READOUT
Current Event No event processed.
Security Principle Segmentation limits unnecessary communication paths.
Investigation Finding No finding yet.
04 · INSPECT · DETECT & PREVENT THREATS

Threat Inspection: IDS, IPS, NDR & WAF

Network inspection adds another layer of security between connectivity and trust. A firewall can enforce whether communication is permitted, while detection and prevention technologies examine permitted traffic for indicators of attack, abnormal behaviour or application-level exploitation.

These controls perform different jobs. IDS primarily detects and alerts. IPS can actively block or prevent traffic when its detection and policy conditions are met. NDR focuses on network behaviour and communication patterns, while a WAF is designed specifically to protect web applications at the HTTP and HTTPS application layer.

The inspection pipeline

From connectivity to security evidence
01 · FLOW Traffic arrives A user, workload or external system initiates communication toward a permitted destination.
→
02 · POLICY Firewall decision Network policy determines whether the communication should be allowed, denied or otherwise handled.
→
03 · DETECT Threat analysis IDS, IPS or NDR can evaluate traffic, protocols and behavioural indicators.
→
04 · EVIDENCE Record the signal Alerts, flow records and other telemetry provide evidence for investigation and correlation.

Detection is not the same as prevention

IDS · Detect
Identify suspicious activity
An intrusion detection system analyses traffic or events and generates alerts when configured indicators or behavioural conditions are observed.
IPS · Prevent
Act on detected threats
An intrusion prevention system can take an enforcement action against traffic when a detection matches configured prevention policy.
NDR · Behaviour
Understand communication patterns
Network detection and response looks for suspicious communication behaviour and relationships across network activity rather than relying only on individual signatures.

Where the inspection technologies fit

IDS
Intrusion Detection

Useful when visibility and alerting are required without the inspection system directly blocking the traffic path.

IPS
Intrusion Prevention

Adds an enforcement capability where detected traffic can be blocked or otherwise prevented according to policy.

NDR
Network Detection & Response

Builds a broader view of network behaviour, helping analysts identify unusual relationships, lateral movement and anomalous communication.

WAF
Web Application Firewall

Applies application-layer controls to HTTP and HTTPS traffic, protecting web applications from classes of application attacks.

Application-layer inspection

Network controls and application controls operate at different levels. A firewall may determine whether a connection between two systems is permitted, while a WAF can inspect the HTTP request itself and apply application-specific security rules.

Client Browser or application initiating the HTTP(S) request.
Web Application Firewall Inspects application-layer requests and applies web security policy before forwarding permitted traffic.
Application Web service receiving the request after policy evaluation.

Engineering inspection principles

01 · VISIBILITY Inspect the right traffic Place controls where meaningful traffic can be observed without creating unnecessary blind spots.
02 · CONTEXT Use more than packets Useful detection can combine addresses, ports, protocols, identities, application context and behavioural patterns.
03 · ACTION Match response to confidence Detection, alerting and blocking should be aligned with the confidence of the finding and the operational risk.
04 · EVIDENCE Preserve the signal Inspection becomes more valuable when its alerts and telemetry can be correlated with identity, endpoint and other security evidence.
Engineering evidence
Inspection only works when the traffic and context are visible

A security control cannot reliably detect what it cannot observe. Encrypted traffic, distributed workloads, cloud services and changing application architectures therefore make visibility, telemetry and appropriate inspection placement critical parts of the design.

Section 04 · Engineering Principle
Allowing traffic does not mean trusting it.

Firewalls control communication policy, IDS provides detection, IPS adds prevention, NDR analyses network behaviour and WAF protects application-layer traffic. Used together, these controls provide multiple inspection points between connectivity and the final security decision.

04 · INSPECT · DETECT & PREVENT THREATS

Threat Inspection Pipeline

Follow a traffic flow through multiple security inspection layers. Each control answers a different question: can the traffic pass, does it contain a known threat, does its behaviour look suspicious, and is the application request safe?

TRAFFIC Web Request
INSPECTION READY
STAGE 0 / 6
LIVE INSPECTION PIPELINE Waiting for traffic
SOURCE
User / Device
FIREWALL
Policy / State
IDS / IPS
Threat signatures
NDR
Behaviour
WAF
HTTP / App
Traffic path: waiting for inspection
INSPECTION TIMELINE 0 events
ENGINEERING EVIDENCE LIVE READOUT
Current Event No inspection event processed.
Control Function Waiting for traffic.
Investigation Finding No threat finding yet.
ENGINEERING MODEL · ENDPOINT & DATA PROTECTION

Protect the Endpoint and the Data It Handles

Network controls cannot provide complete protection once a workload, endpoint or application becomes the target. Security therefore extends to the systems themselves, the data they process and the cryptographic controls protecting information in transit and at rest.

01 · ENDPOINT Protect the device EPP and EDR provide prevention, detection and investigation capabilities directly on endpoints and workloads.
02 · DATA Control sensitive information DLP and data-aware policies help reduce inappropriate movement or exposure of sensitive information.
03 · TRANSIT Encrypt communication TLS, VPNs and other cryptographic mechanisms protect information while it moves between systems.
04 · ASSURE Validate posture Security controls should provide evidence that endpoints and data protections remain appropriately configured.
Endpoint
→
Application
→
Data
→
Encryption
→
Evidence
05 · PROTECT · ENDPOINTS, DATA & ENCRYPTION

Endpoint, Data & Encryption Protection

Network security does not end at the network boundary. The endpoint executes the workload, the application processes the information and the data itself may remain valuable even when network controls are operating correctly. Protection therefore needs to extend across the systems and information being defended.

Endpoint protection provides controls close to the workload. EPP can provide preventative protection, while EDR provides telemetry and investigation capabilities for suspicious endpoint activity. XDR can extend correlation across multiple security domains where supported.

Data protection adds another perspective. DLP can help identify and control inappropriate movement of sensitive information, while encryption protects information from unauthorised disclosure when data is stored or transmitted.

The protection stack

Protection follows the workload and the information
01 · DEVICE Endpoint Establish a security control point close to the system executing the workload.
→
02 · APPLICATION Process Monitor application and process activity that may indicate compromise or misuse.
→
03 · DATA Information Apply appropriate controls to sensitive information regardless of where the data is processed.
→
04 · EVIDENCE Telemetry Feed endpoint and data security signals into wider investigation and correlation workflows.

Endpoint protection is a local security boundary

EPP · Endpoint Protection Platform
Prevent common endpoint threats
Endpoint protection can provide preventative controls against malware and other known threats, alongside additional host security capabilities.
Prevention happens close to the workload rather than relying entirely on network inspection.
EDR · Endpoint Detection & Response
Investigate what the endpoint is doing
EDR collects endpoint telemetry that can help security teams investigate processes, files, connections and other indicators of suspicious activity.
Detection becomes more useful when endpoint evidence can be correlated with network and identity signals.

Endpoint controls should produce evidence

01 · POSTURE Is the device protected? Security status, configuration and protection state provide useful context for access decisions.
02 · PROCESS What is executing? Process activity can reveal behaviour that is invisible from network addresses alone.
03 · CONNECTION Where is it communicating? Endpoint connection telemetry can be correlated with network and application activity.
04 · RESPONSE Can it be contained? Security operations may need to isolate or otherwise contain a compromised endpoint.

Encryption protects information in transit

Encryption changes the security properties of communication by making captured traffic substantially less useful to an unauthorised observer. TLS is commonly used to protect application sessions, while VPN technologies can create encrypted tunnels across otherwise untrusted networks.

Simplified encrypted communication model
Source Application or endpoint generating the protected information.
→
TLS / VPN Protection Cryptographic protection is applied to the communication path according to the protocol and architecture being used.
→
Destination Intended application or endpoint receives the protected session.

Encryption is not the same as access control. A correctly encrypted connection can still be made by an unauthorised identity if authentication and authorization controls are weak. Encryption protects the information in transit; identity and policy determine who should be allowed to access it.

Protecting sensitive data

CLASSIFY Know what matters Security policy becomes more useful when sensitive information can be identified and assigned appropriate handling requirements.
CONTROL Limit movement DLP and access controls can help prevent sensitive information from being transferred through inappropriate channels.
PROTECT Use encryption Encryption can protect information during transport and, where implemented, while stored.
Engineering evidence
Security must follow the data, not just the network

Modern applications move across endpoints, data centres, cloud platforms and remote access environments. A security architecture that protects only the network path can therefore miss activity occurring directly on the endpoint or around the data itself.

Section 05 · Engineering Principle
Protect the system, the information and the communication between them.

Endpoint security provides local protection and telemetry. DLP helps control sensitive information, while encryption protects data during transport and storage when appropriately implemented. Together these controls extend the security architecture beyond the network boundary and closer to the actual workload and data.

05 · PROTECT · ENDPOINTS, DATA & ENCRYPTION

Endpoint & Data Protection Console

Security does not stop at the network boundary. Follow an endpoint and the data it handles through device posture, process activity, data protection, encryption and security evidence.

ASSET Managed Endpoint
PROTECTION READY
STAGE 0 / 6
PROTECTION STACK Waiting for asset
01 · ENDPOINT POSTURE
Device state, patching, security controls
READY
02 · PROCESS CONTROL
Process behaviour and endpoint detection
READY
03 · DATA PROTECTION
Classification, access and DLP controls
READY
04 · ENCRYPTION
TLS / VPN protection for data in transit
READY
05 · SECURITY EVIDENCE
Logs, telemetry and response context
READY
PROTECTION TIMELINE 0 events
ENGINEERING EVIDENCE LIVE READOUT
Current Control No control evaluated.
Security Function Waiting for the protection workflow.
Investigation Finding No finding yet.
ENGINEERING MODEL · CLOUD & REMOTE ACCESS

Secure Access Across a Distributed Environment

Users, applications and workloads increasingly connect from locations outside the traditional enterprise perimeter. Secure access therefore needs to combine identity, device context, encrypted connectivity and application-aware security controls.

01 · IDENTITY Verify the user Authentication establishes who is requesting access before a protected service is exposed.
02 · ACCESS Reach the application ZTNA and other access controls can restrict users to the applications they are authorised to use.
03 · PROTECT Secure the session VPN, TLS, SWG and DNS security provide protection around remote communication and internet access.
04 · CORRELATE Keep the evidence Access and security events should feed broader monitoring and investigation workflows.
User / Workload
→
Identity
→
Access Policy
→
Cloud / App
→
Telemetry
06 · CONNECT · SECURE CLOUD & REMOTE ACCESS

Secure Cloud, Internet & Remote Access

The traditional enterprise perimeter becomes less useful when users work remotely, applications move into cloud platforms and services are consumed directly from the internet. Security controls therefore need to follow the identity, device and application rather than assuming that everything important exists behind one physical firewall.

VPN remains useful when an encrypted tunnel to a private network is the appropriate access model. Zero Trust Network Access takes a different approach by providing identity- and application-aware access without necessarily placing the user onto the entire network.

The secure access journey

Identity and policy follow the connection
01 · REQUEST User or workload A user, endpoint or workload requests access to an internal, cloud-hosted or internet service.
→
02 · IDENTITY Verify context Authentication and policy establish whether the requesting identity should receive access.
→
03 · CONTROL Apply access policy ZTNA, VPN or other controls determine the permitted connectivity model.
→
04 · SERVICE Reach the application Access is provided to the intended service rather than assuming unrestricted network trust.

VPN and ZTNA solve different access problems

VPN · Encrypted Network Connectivity
Create a protected tunnel
A VPN can provide encrypted connectivity across an untrusted network and, depending on its design, provide access to a private network or defined network resources.
Typical model: Remote user → VPN tunnel → Private network
ZTNA · Application-Aware Access
Connect the user to the service
ZTNA can use identity and contextual policy to provide access to authorised applications without necessarily exposing the underlying network to the user.
Typical model: User → Identity Policy → Application

Cloud security is a collection of control functions

Cloud and internet security is rarely one product. Different control functions address different parts of the access path, including web traffic, DNS resolution, SaaS usage and identity-aware application access.

01 · SWG Secure Web Gateway Applies security policy to web access and can provide inspection, filtering and visibility for internet-bound traffic.
02 · DNS DNS Security Uses DNS requests as a policy and detection point, including blocking known malicious or inappropriate destinations where configured.
03 · CASB Cloud Access Security Broker Provides visibility and policy controls around the use of cloud applications and services.
04 · SASE Distributed Security Model SASE combines networking and security functions as a cloud-delivered architectural model for distributed users and locations.

Choosing the control point

Scenario
Primary question
Useful control
Security focus
Remote private access
Should this user reach the private environment?
VPN / ZTNA
Identity + access policy
Internet browsing
Should this destination be reachable?
SWG / DNS security
Web + destination policy
SaaS usage
How is the cloud service being used?
CASB
Application + data policy
Distributed workforce
Where should security policy execute?
SASE functions
Distributed enforcement

SASE as an architectural model

User / Branch Distributed users, branch locations and devices generating network requests.
SASE Security Functions Networking and security capabilities delivered closer to distributed users and applications, according to the architecture.
Cloud / Internet SaaS, public cloud and internet applications accessed through the controlled service path.

Secure access principles

01 · IDENTITY Start with the requester Access decisions should establish who or what is requesting the service before assuming trust.
02 · APPLICATION Expose what is required Where possible, access should be scoped to the application or service rather than unnecessarily exposing an entire network.
03 · CONTEXT Use more than credentials Device state, location, risk and other contextual signals can improve the quality of an access decision.
04 · TELEMETRY Record the decision Authentication, access and security events should remain available for monitoring and investigation.
Engineering evidence
The perimeter has moved closer to the user and application

Distributed applications and remote users do not eliminate network security. They change where security decisions need to occur. Identity, device context, application policy, web controls and cloud-delivered enforcement increasingly operate alongside traditional network boundaries.

Section 06 · Engineering Principle
Secure access should follow the user, device and application.

VPN provides an important encrypted connectivity model, while ZTNA can provide more granular application-aware access. SWG, DNS security, CASB and SASE extend policy into internet and cloud environments. Together, these controls adapt the security architecture to a distributed environment rather than relying on a single fixed perimeter.

06 · CONNECT · CLOUD & REMOTE ACCESS

Secure Cloud & Remote Access Journey

Follow a user or device from the initial access request through identity verification, device context, access policy, security services, application access and telemetry.

ACTOR Employee
ACCESS PENDING
STAGE 0 / 6
SECURE ACCESS PATH Waiting for access request
01 · TRUST
IDENTITY
Verify who is requesting access.
READY
02 · CONTEXT
DEVICE
Evaluate device posture and trust.
READY
03 · DECISION
ACCESS POLICY
Determine what the actor may reach.
READY
04 · PROTECT
SECURITY SERVICE
Apply VPN, ZTNA, SWG or related controls.
READY
05 · RESOURCE
APPLICATION
Reach the permitted cloud or internal service.
READY
06 · EVIDENCE
TELEMETRY
Record the access decision and session evidence.
READY
ACCESS TIMELINE 0 events
ENGINEERING EVIDENCE LIVE READOUT
Current Stage No access stage evaluated.
Security Function Waiting for the access workflow.
Investigation Finding No finding yet.
ENGINEERING MODEL · SECURITY INTELLIGENCE

Turn Security Signals Into Evidence

Individual security controls see different parts of an event. Identity systems see authentication, firewalls see connections, endpoints see processes and DNS controls see destinations. Security intelligence connects those signals so an investigation can understand the wider behaviour.

01 · COLLECT Gather telemetry Capture identity, network, endpoint, application and cloud security events.
02 · CORRELATE Connect the signals Relate events by identity, device, address, application, time and other useful context.
03 · INVESTIGATE Understand behaviour Determine whether apparently separate events form a meaningful security pattern.
04 · RESPOND Drive action Use validated findings to support analyst decisions or appropriate automated workflows.
Identity
+
Network
+
Endpoint
+
Application
→
Security Evidence
07 · CORRELATE · SECURITY INTELLIGENCE

SIEM, SOAR & Cross-Layer Security Intelligence

A modern security architecture produces enormous amounts of telemetry. The challenge is not simply collecting more events. It is connecting the right evidence so analysts can distinguish isolated activity from a meaningful attack pattern and then respond appropriately.

SIEM platforms provide centralised collection, search and correlation of security telemetry. SOAR extends the operational model by orchestrating response workflows and actions. Neither replaces the underlying security controls; both depend on the quality and context of the evidence they receive.

One event rarely tells the whole story

Different controls observe different parts of the same activity
IDENTITY Authentication Login attempts, MFA events, identity changes and access decisions.
NETWORK Connections Flows, firewall events, DNS activity and network security alerts.
ENDPOINT Processes Process execution, files, connections and endpoint detection telemetry.
APPLICATION Service activity Application authentication, errors, transactions and security events.
Raw Events Individual observations from separate control points.
→
Correlation Connect events using identity, asset, address, time and behavioural context.
→
Security Finding A contextualised event suitable for investigation.

SIEM and SOAR have different responsibilities

SIEM · Security Information & Event Management
Build the evidence picture
SIEM provides a central platform for collecting, searching and correlating security telemetry. It can help analysts identify relationships between events that would otherwise remain distributed across individual systems.
Primary role: collect → normalise → correlate → investigate
SOAR · Security Orchestration, Automation & Response
Orchestrate the response
SOAR can coordinate predefined workflows across security tools, reducing repetitive analyst tasks and helping execute approved response procedures.
Primary role: validate → orchestrate → execute → record

Security telemetry spans multiple layers

01 · IDENTITY Who? User, service account, authentication and authorization context.
02 · DEVICE What system? Endpoint identity, posture, process and security state.
03 · NETWORK Where? Source, destination, protocol, flow and network security context.
04 · APPLICATION What service? Application behaviour, transactions and service-level security events.
05 · TIME When? Temporal relationships can reveal sequences that isolated events hide.

Correlation turns separate events into an investigation

Example: a suspicious remote access sequence
09:14:02 Identity event Successful authentication from an unusual location.
09:14:18 Network event New connection established to an internal service.
09:14:41 Endpoint event Previously unseen process begins making outbound connections.
09:15:07 DNS event Endpoint resolves a newly observed external destination.
Correlation result: these events become more significant when linked by the same identity, endpoint and time window. The result is an investigation lead rather than four unrelated alerts.

Automation should follow validated evidence

01 · DETECT Generate the finding Correlation identifies behaviour that meets the defined detection criteria.
02 · VALIDATE Establish confidence Analysts or additional automated checks determine whether the finding is sufficiently reliable for action.
03 · RESPOND Execute the workflow Approved actions can then be orchestrated across identity, endpoint, network or other security systems.
Engineering evidence
More telemetry does not automatically mean better security

Effective security intelligence depends on useful context, consistent timestamps, meaningful asset and identity relationships, appropriate retention and well-tuned detection logic. A large event store without correlation can simply create a larger investigation queue.

Section 07 · Engineering Principle
Collect broadly, correlate intelligently and automate carefully.

SIEM provides the evidence and correlation layer while SOAR can orchestrate response workflows. The strongest architecture connects identity, endpoint, network and application telemetry so that security decisions are based on a contextual view of behaviour rather than an isolated alert.

07 · CORRELATE · SECURITY INTELLIGENCE

SIEM & SOAR Correlation Engine

Security events become useful when they are correlated across identity, network, endpoint and application layers. Build the evidence chain, calculate incident confidence and select an appropriate response.

SIGNALS 0 / 4
CONFIDENCE LOW
INCIDENT OPEN
SECURITY SIGNALS Waiting for telemetry
IDENTITY
Unusual Authentication
Authentication occurs from an unusual context or location.
WAIT
NETWORK
Suspicious Traffic
Network telemetry identifies unusual communication behaviour.
WAIT
ENDPOINT
Process Anomaly
Endpoint telemetry reports an unexpected process or execution chain.
WAIT
APPLICATION
Resource Access
Application telemetry shows access to a sensitive resource.
WAIT
CORRELATION CHAIN Confidence: LOW
Identity —
Network —
Endpoint —
Application —
CORRELATION TIMELINE 0 events
ENGINEERING EVIDENCE LIVE READOUT
Current Finding No correlated finding yet.
SIEM Function Collect and correlate security telemetry across layers.
SOAR Function No response workflow selected.
ENGINEERING MODEL · INTEGRATED SECURITY ARCHITECTURE

Validate the Security Architecture as a System

Security controls become more effective when they operate as a connected architecture rather than isolated point solutions. Validation asks whether identity, enforcement, segmentation, inspection, endpoint protection, telemetry and response work together as one security decision system.

01 · CONNECT
Integrate Controls Connect identity, policy, enforcement and telemetry.
02 · OBSERVE
Collect Evidence Make security decisions visible across the architecture.
03 · CORRELATE
Understand Context Combine signals instead of treating every alert independently.
04 · VALIDATE
Prove the Design Test whether the controls actually produce the intended outcome.
IDENTITY → ACCESS → SEGMENT → INSPECT → PROTECT → OBSERVE → RESPOND
Engineering Principle A security architecture should be evaluated as a decision chain, not as a collection of products.
Validation Question Can we prove that a security event is detected, understood, enforced and responded to across the complete control path?
08 · VALIDATE · INTEGRATED SECURITY ARCHITECTURE

Integrated Security Architecture

A mature security architecture connects individual controls into a decision and evidence chain. The objective is not to eliminate every point solution, but to ensure that identity, enforcement, detection, telemetry and response operate together.

SECURITY DECISION CHAIN
IDENTITY Who is the user, device or workload?
ACCESS CONTROL What is this identity permitted to reach?
SEGMENTATION Which trust boundary contains the resource?
INSPECTION Does the traffic or request contain suspicious behaviour?
PROTECTION Are endpoint, application and data controls active?
TELEMETRY Can the architecture produce evidence of the decision?
RESPONSE Can the appropriate action be executed and validated?
ARCHITECTURE PRINCIPLES
Least Privilege Grant only the access required for the task and context.
Explicit Policy Make security decisions intentional and explainable.
Continuous Visibility Capture telemetry across identity, network, endpoint and application layers.
Evidence-Based Response Use correlated evidence before escalating or containing an event.
Point Solutions Individual controls can provide strong protection, but disconnected systems increase integration and visibility gaps.
Integrated Architecture Controls remain specialised while sharing identity, telemetry, policy context and response workflows.
Engineering Test

If an attack crosses several security layers, can the organisation trace the event from initial identity signal through enforcement, detection, correlation and response?

The objective is integration, not simply accumulation.

Adding more security products does not automatically create a stronger architecture. The engineering question is whether each control has a defined role, produces useful evidence and connects to the controls responsible for the next security decision.

08 · VALIDATE · INTEGRATED SECURITY ARCHITECTURE

Integrated Security Assurance Console

Validate whether the complete security architecture can establish identity, enforce access, contain trust boundaries, inspect activity, protect assets, generate evidence and trigger an appropriate response.

CONTROLS 0 / 7
ASSURANCE 0%
ARCHITECTURE UNVALIDATED
END-TO-END CONTROL CHAIN Validation not started
01
Identity & Trust
Establish who or what is requesting access.
WAIT
02
Access Enforcement
Apply authentication, authorization and policy.
WAIT
03
Segmentation
Constrain communication within the intended trust boundary.
WAIT
04
Inspection & Detection
Inspect traffic, requests and behaviour for threats.
WAIT
05
Endpoint & Data Protection
Protect the endpoint, application and information.
WAIT
06
Telemetry & Correlation
Produce evidence and correlate events across layers.
WAIT
07
Response & Recovery
Execute, validate and recover from the security decision.
WAIT
ARCHITECTURE ASSURANCE 0%
Validate each layer to determine whether the architecture forms a complete security decision and evidence chain.
VALIDATION TIMELINE 0 events
ENGINEERING EVIDENCE LIVE READOUT
Current Finding No controls validated yet.
Architecture Test Can the security chain be traced from identity to response?
Final Assurance Architecture validation pending.
```
☕
Support Network Insight
Help support independent engineering guides, interactive networking tools, and future learning labs.
Support Network Insight ```
Interactive Security Fabric

Point Solutions vs Integrated Security

Modern security requires more than isolated tools. Explore how identity, device posture, segmentation, threat detection and security analytics combine to produce a stronger security decision.
Unified security decision
Identity
→
Device
→
Network
→
Threat
→
Intelligence
→
Enforcement
Combined Security Risk
LOW · 18%
ID
Identity
Identity security signal

Identity provides context about who is requesting access and whether authentication requirements have been satisfied.

Signal User + MFA
Question Who is requesting access?
Control Authentication
Value Identity-aware policy
CURRENT DECISION
Identity signal is healthy. Continue evaluating device and network context.

Why correlation matters

A single security product sees only part of the story. Correlating identity, device, network and threat telemetry creates a much stronger basis for enforcement.

IDENTITY Who is accessing the resource?
DEVICE Is the endpoint trusted and healthy?
NETWORK Is the requested communication permitted?
THREAT Is there evidence of malicious activity?
SIEM / SOAR Can multiple signals be correlated and acted upon?