← CISSP: security, risk, and operations
14 / 15 · 60 MIN

Network paths, identity, and control planes

Assess communication by source, destination, operation, and context while protecting mechanisms that change the rules.

Describe flows with direction and purpose

A supplier integration needs an understandable communication list: who initiates, to which destination, using which transport and port, and for what purpose. A supplier→gateway:443 rule does not imply supplier→app:8443. Nor does it automatically imply reverse direction in a directional stateless filter. Define device behavior before interpreting a test. This lesson’s model uses exact matching and does not reproduce a real firewall. At work, consider state, effective rules, translations, routes, and alternative paths. A working legitimate flow is positive evidence; isolation also requires observing relevant denials.

Protect the decision mechanism

A gateway may filter requests correctly while remaining vulnerable if the same support account can freely change its policy. Distinguish the data plane carrying requests from channels configuring and administering decisions. Restrict change authority, protect access, and retain traceability. A forgotten management interface retaining factory access is another path even if the main interface has strong authentication. If containment disables the only telemetry path, plan how to confirm its effect without declaring success merely because logs stopped. Protection needs to cover the mechanism as well as its outputs.

Validate channel identity

A trusted certificate chain alone does not establish that the endpoint is the intended one. If a request uses api.fundos.example and the certificate identifies only ficheiros.fundos.example, a mismatch needs correction. Disabling hostname verification turns an identity problem into a removed protection. For certificate-authenticated clients, keep operation and data authorization separate. A supplier with valid mTLS does not automatically receive access to every client of the fictional bank. Use authenticated identity as an input to a scoped decision instead of treating every accepted certificate as universal permission.

Follow data after the channel

TLS protects communication between that channel’s endpoints. After a proxy terminates TLS, consider the next segment, cache, and exported files. A personal response reused for another user is an isolation and cache-policy problem even when both used HTTPS. A plaintext downloaded report still needs destination access and retention controls. For auditing, the proxy IP identifies the intermediary, not each person. If propagating identity or a correlation identifier, protect its origin and prevent arbitrary client data from being treated as a trusted assertion. Channel protection does not settle those downstream questions.

Cover alternative paths and capacity

A policy implemented only in IPv4 does not demonstrate equivalent isolation while IPv6 remains available without equivalent control. Restricting DNS over UDP is also insufficient if TCP to arbitrary destinations remains allowed against the requirement. Inventory variants actually used and scope the rehearsal. When sharing links, reserve capacity for critical functions instead of assuming the total is free. With 100 usable Mbit/s, 25 reserved for transactions and 15 for management, 60 remain. A copy requiring 70 creates a ten-unit deficit in the model. This calculation does not predict real throughput under congestion.

Guided practice: permit and deny

In the synthetic table below, identify both extra flows before choosing a change. Remove unintended paths and confirm authorized integration remains functional. Record source, destination, transport, port, result, and assessed configuration. Do not generalize the rehearsal to another environment without checking equivalence. Then discuss telemetry loss during containment: what alternative evidence remains authorized? At work, prepare firewall requests and operational acceptance with complete dependencies so network and APS teams know both what must work and what should be denied. State the model’s limits before applying its result.

Synthetic directional flow fixture; exact matches only
Allowed: supplier -> gateway TCP443
Allowed: gateway -> app TCP8443
Observed: supplier -> app TCP8443 [extra]
Observed: supplier -> management TCP22 [extra]
Retest permitted AND denied paths after an authorized correction.
IN PRACTICE

A supplier correctly accesses the portal, but rehearsal reveals direct backend and management access. Acceptance requires removing both paths while retaining legitimate flow.

Common pitfalls

Treating a port as authorization, overlooking IPv6 or TCP, confusing proxy IP with user identity, and reading missing logs as completed containment.

Related topics: Architecture, cryptography, and common failures · Networks, channels, and access boundaries · Secure software and supply chain

Take this idea with you

A useful boundary controls effective paths and operations, validates identity, and retains means to confirm behavior.

Create account

Reference: Zero Trust Architecture · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29

CISSP® is a registered trademark of ISC2, Inc. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by ISC2. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.