Chapter 2 — Networks and protocols

Lesson map

Lesson 02 published. Map, example, EX005.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Branch networks"]
  N2["2.2 Card payment requirements"]
  N3["2.3 Documenting changes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX005"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Branch networks"]
  N2["2.2 Card payment requirements"]
  N3["2.3 Documenting changes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX005"]

[Learning outcomes]
    |
    v
[2.1 Branch networks]
    |
    v
[2.2 Card payment requirements]
    |
    v
[2.3 Documenting changes]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX005]

Learning outcomes

You will (1) describe a branch network design; (2) identify card payment network requirements; (3) document network changes.

2.1 Branch networks

Each Fenwick branch has a network for tills and card terminals, office computers and a guest Wi-Fi for trade customers. Amina learns that these should be separated so a problem in one cannot easily spread to another. She checks two branches: one has separate segments; the other connects everything to one switch. She records the difference and learns that branches built at different times often vary, which governance must find and fix. The branch with one switch lets a compromised guest device reach the tills, so she records it as the higher priority of the two.

2.2 Card payment requirements

Card terminals and the till software handle payment card data, which brings PCI DSS v4.0 requirements. Amina learns that keeping payment systems on their own segment, with only necessary connections allowed, reduces the number of systems in scope. She lists the connections the payment segment needs: to the payment gateway for authorisation and to IT management for updates. Anything else should be blocked, and the list itself becomes evidence for assessments. A connection from office computers to the payment segment, for instance, would bring those computers into PCI DSS scope as well.

2.3 Documenting changes

When a branch technician adds a new device or rule, the change should be recorded: what, why, who approved and when. Amina finds that branch changes are often made by phone with no record. She drafts a simple change form and explains that without records, nobody can tell whether the network still matches its design. She learns that change documentation is a basic control supporting both security and troubleshooting. A change form with fields for what, why, approver and date takes a technician only a minute on the phone call itself.

Worked example

Amina compares two branch networks, lists required payment connections and drafts a change record form.

Synthetic case. Branch networks are synthetic; PCI DSS v4.0 is real.

Errors and limits

Diagrams drift. Change forms get skipped in emergencies.

Exercises

• EX005 — Unsegmented branch. What problem did the second branch have?
  Show marking criteria

  Rubric: 3 = everything on one switch without segments;; 2 = flat network;; 1 = vague;; 0 = none.
• EX006 — Payment connections. Which connections does the payment segment need?
  Show marking criteria

  Rubric: 3 = payment gateway and IT management;; 2 = two;; 1 = internet;; 0 = none.
• EX007 — Change record. What should a change record capture?
  Show marking criteria

  Rubric: 3 = what, why, who approved and when;; 2 = four;; 1 = vague;; 0 = none.
• EX008 — Scope reduction. How does segmentation help with PCI DSS?
  Show marking criteria

  Rubric: 3 = reduces systems in scope;; 2 = scope;; 1 = vague;; 0 = none.

Synthesis

Segmented, documented networks keep payment scope small and designs verifiable.

Continue studying — chapter 02 of 18

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →