The exact introductory gap is addressed by a complete fictional flow artifact, explicit teaching and explained model checks. Closure is limited to this paper learning objective; it does not claim deployed network assurance or exam readiness.
Original editorial teaching and fictional application, informed by the linked primary passages. Compare your reasoning with the model; this is not independently marked learner work, an official examination key or a replacement for the selected course.
What this guide contributes.
Primary route: ISC2 CC. These are selected related scope positions, not a claim that the guide teaches the entire objective/application/statement. Full scope and remaining depth are in the coverage register.
See this guide’s exact scope links and remaining depth
What the source review checked
- Zones and enforced communication
- Allowed/blocked flow artifact
- Packet/connection and application distinction
- Stateful replies versus reverse initiation
- Management path
- Reachability counterexample and safe verification
Assigned public passages and original model guidance were checked. No learner work, paid course or full licensed standard was assessed; the remaining-needs section controls any closure claim.
1. Read with a purpose.
Australian Signals Directorate / Australian Cyber Security Centre · Implementing network segmentation and segregation: enforced flows and management separation
FREE PUBLIC READINGRead: Selected definitions, five implementation themes and filtering bullets.
Learn: A zone is a group with a purpose; separation needs enforced, necessary communication paths. Management access is its own flow.
Exact scope and exclusionsPublic HTML teaching read without registration or payment on 29 October 2026.
NIST · NIST SP 800-41r1: packet, application and inspection boundaries
FREE PUBLIC READINGRead: Selected layer-role figure, packet attributes, stateful section/table, application/proxy and inspection-limit passages only; then the case below.
Learn: A destination port is one condition. An application-aware policy can inspect supported protocol behaviour where it has visibility; destination authorization remains a separate question.
Exact scope and exclusionsFree public PDF opened and selected passages read without an account.
2. Try the fictional case.
Follow one booking request through five zones
Original editorial application. Every host and address is fictional. Example Studio uses: a public edge proxy in the DMZ (198.51.100.20); a booking API in the application zone (10.20.0.10); a database in the data zone (10.30.0.10); staff devices in a staff zone; and a named admin workstation plus jump host (10.40.0.20) in a management zone. A guest is allowed to use the public booking service but has no direct internal-system access. Customers may read their own booking; only an approved staff export role may export all bookings. The edge proxy terminates its approved HTTPS session and creates a separate encrypted API session. The API enforces the booking permissions. The database accepts only the API service identity for specified booking operations. The exercise starts after name resolution, with addresses already known. Only the paths below are approved; supporting-service flows would need their own documented rules in a real design.
Your tasks
- Draw the zones and new-session directions. Give each allowed flow a source, destination, transport/port, application purpose and permission condition. Add one management path and at least three denied paths.
- Walk through a customer's read-own-booking request from the initial TCP connection to the response. Explain the difference between stateful return traffic and permission to initiate a new reverse connection.
- For a read-another-customer request over the same open port, decide which control must reject it. State what a successful port check does and does not demonstrate.
- Produce a paper test table with positive and negative cases and the records that would justify the result. Do not send traffic to a real host.
3. Compare your reasoning.
Decide and write your explanation first. Where a table is wider than your screen, focus it and use the arrow keys, or scroll it sideways.
Open explained model guidance
Diagram (arrows mean approved new-session initiators; controls enforce policy at each zone boundary):
Business: visitor / staff -> DMZ edge -> application API -> database
Management: named admin -> management jump host -> named interfacesThe diagram deliberately shows only the exercise's approved business/management paths. A line on a drawing has no enforcement effect by itself.
Flow record:
| ID | Initiator → destination | Port/protocol | Additional rule and reason |
|---|---|---|---|
| F1 | Visitor/guest or staff → edge only | TCP 443, HTTPS | Expose the booking interface. The proxy checks the supported HTTP request policy after approved TLS termination; the service checks user permissions. |
| F2 | Edge host → API host only | TCP 8443, HTTPS API | Authenticate the edge service; accept only the defined booking API actions and valid inputs. A port filter alone does not express those actions. |
| F3 | API host → database host only | TCP 5432, encrypted database protocol | Authenticate the API service account and restrict database operations. This is a declared design choice, not a guarantee attached to port 5432. |
| F4 | Named admin workstation → jump host | TCP 22, SSH | Under this fictional design the jump host requires MFA and approved administrator access. Being in the management subnet is insufficient. |
| F5 | Jump host → named API/database management interfaces | TCP 22, SSH | Authorize the admin role, destination and maintenance purpose; log the session. No broad access to all hosts. |
| D1 | Guest/staff → database directly | Any new session | Deny: the business workflow uses the API, not direct database access. |
| D2 | Internet or DMZ edge → internal SSH management | TCP 22 | Deny: public-service access does not grant administration. |
| D3 | API → arbitrary internet host, or database → staff | Any new session | Deny unless a separately approved dependency is specified. |
Other new sessions are denied by the stated policy; this does not imply that a real service can operate without separately specified support flows.
Layer check for this TCP example: IP addresses identify network endpoints at OSI layer 3; TCP source/destination ports and connection state are transport-layer facts at layer 4; HTTP actions and inputs are application-layer content at layer 7 where visible. A client uses a temporary source port and the approved server destination port; replies reverse those endpoint/port pairs within that session. An application-aware firewall's supported protocol/content check does not replace the API's booking-owner/role authorization. Walkthrough: (1) the browser sends a new connection to edge TCP 443; the network rule decides whether that connection is permitted. (2) TLS establishes the protected browser-to-edge session under the stated design. (3) at the point that can actually see HTTP, the request is checked for the supported application action and input form. (4) the edge opens its separate F2 session; the API authenticates the service/user context and authorizes access to the requested booking. (5) the API makes an F3 database request using its restricted service identity; the database enforces that identity's rights. (6) the response returns through the established sessions. A stateful reply is associated with an approved session; it is not permission for the database to start arbitrary new connections back to staff.
Reachability counterexample: customer A can complete a TCP 443 connection and read booking A. A request to read booking B still traverses the permitted port and can be valid HTTP, but the API must deny it because the account lacks permission for B. Expected denial is an application result and no B content, not a firewall timeout. The successful connection proves that this route/port was reachable at that moment; it does not establish the caller's business authority, safe content, endpoint integrity or the confidentiality of every permitted path. This conclusion is editorial application of the sources' separate filtering/authentication/inspection concepts.
Paper verification record:
| Case | Expected result | Evidence that would be needed in an authorized implementation |
|---|---|---|
| Customer A reads A through F1–F3 | Allow correct A result | Correlated proxy/API request IDs and permission decision, relevant database action and expected response |
| Customer A requests B through TCP 443 | Reject at application authorization; no B data | API denied-object decision and response content check; an open-port result alone is insufficient |
| Guest attempts direct database TCP 5432 | Deny at boundary | Matched deny rule/log and absence of a database session, within the test's observation limits |
| Staff workstation attempts API SSH | Deny | Boundary deny record; staff network membership grants no management role |
| Approved admin uses jump host to named API management interface | Allow the approved session | Identity/MFA result, destination/role approval and host session log |
| Application filter is asked to inspect opaque end-to-end encrypted data it cannot decrypt | Record visibility limit | Evidence of where TLS terminates and which control sees plaintext; no invented content-inspection claim |
A real retest would also check alternate paths and current policy application at all relevant enforcement points; this exercise performs no such test.
Original source-grounded editorial teaching and model answers; not a publisher-issued exam key, independent learner assessment, complete architecture, permission to probe a real target or claim that any control has been deployed/tested.
4. Check the work, not just the score.
- Every allow row identifies a necessary initiator, named destination, service and purpose; no whole-zone trust or any-to-any shortcut replaces the rule.
- You can explain why TCP 443 being reachable does not authorize another person's booking, and can name the application decision that rejects it.
- Your management route has identity/role checks and its own restrictions; neither the guest network nor the public proxy is an administrator.
- You state where encrypted application content can be inspected and distinguish a proposed paper outcome from observed operational evidence.
These checks help you revise an explanation. They do not certify mastery or predict an examination result. Ask a qualified reviewer to assess a fresh case when independent feedback is needed.
5. Keep the limits in view.
Free coverage added
- Complete paper diagram and permitted-flow table with defined initiating endpoints, direction, ports, application checks and a separate management route.
- Step-by-step browser request, reply and application-authorization walkthrough, plus explained allowed/blocked examples.
- Explicit encrypted-traffic inspection boundary and a case in which a permitted TCP connection carries an unauthorized business request.
Still missing or outside this guide
- A live packet lab, actual firewall configuration and independent operational validation remain outside this introductory paper case.
- Supporting DNS, time, update and logging flows, full availability design, subnetting and real product capabilities need a fuller design; the case expressly does not hide them behind an allow-all rule.
- This is formative source-grounded learning, not an independently marked current CC assessment or pass prediction.
Payment and access
FREE for the selected readings and complete editorial paper exercise. No paid course or simulator is needed for this bounded gap. Extra current CC teaching, live labs or independent marking are optional purchases; exam/credential charges are separate.
Open this area in the gap register