Chapter 22 — Network and communications security: system and data models
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Flow model"]
N2["Lab — Reachability comparison"]
N3["22.2 Reading the model"]
N4["22.3 Data model for logs"]
N5["Host-level exceptions"]
N6["Model as a test oracle"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Flow model"]
N2["Lab — Reachability comparison"]
N3["22.2 Reading the model"]
N4["22.3 Data model for logs"]
N5["Host-level exceptions"]
N6["Model as a test oracle"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Flow model]
|
v
[Lab — Reachability comparison]
|
v
[22.2 Reading the model]
|
v
[22.3 Data model for logs]
|
v
[Host-level exceptions]
|
v
[Model as a test oracle]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) model zones and permitted flows; (2) compare reachability; (3) define data flows for logging.
22.1 Flow model
Kofi models the design as a directed graph of zones with permitted services on each edge. The model is derived from the needed-flows list collected from stakeholders: staff need file and web services, phones need the call server, cameras need the recorder and management needs administrative access to devices.
A flow model lists every needed communication as source zone, destination zone, service and purpose. It is built from interviews and synthetic flow summaries, and becomes the basis for rules.
Each flow names its owner.
Lab — Reachability comparison
"""Zone-to-zone reachability: flat network vs proposed segmented policy (synthetic, stdlib only)."""
zones = ["staff", "servers", "voice", "cctv", "guest", "mgmt"]
allowed = {("staff", "servers"), ("voice", "servers"), ("cctv", "servers"), ("mgmt", "servers"), ("mgmt", "staff"),
("mgmt", "voice"), ("mgmt", "cctv")}
pairs = [(a, b) for a in zones for b in zones if a != b]
print(f"directed zone pairs {len(pairs)}; flat reachable {len(pairs)}; segmented reachable {len(allowed)}")
print(f"reduction {1 - len(allowed)/len(pairs):.1%}; guest reaches internal zones: {any(a=='guest' for a,_ in allowed)}")
Run with python3 lab_reach.py. Verified output:
directed zone pairs 30; flat reachable 30; segmented reachable 7
reduction 76.7%; guest reaches internal zones: False
22.2 Reading the model
The flat network allows all thirty directed zone pairs. The segmented design allows seven, a 76.7 percent reduction. Guest reaches no internal zone, satisfying R1. Management reaches four zones for administration, which is necessary but makes management the most sensitive zone, reinforcing R3's jump host requirement.
Reading the model, Kofi looks for zones that talk to many others, which are critical, and flows without a stated purpose, which may be unnecessary. Both shape the rule design and review.
Unclear flows are queried.
22.3 Data model for logs
Each control point emits records with time, zones, service and action. Kofi defines this common format so that logs from different firewalls can be analysed together, matching the schema from chapter 13.
The log data model defines which fields every firewall and VPN record must carry, such as time, zone, address, service, action and rule identifier. Including the rule identifier is especially useful, because it lets analysts see exactly which rule allowed or denied each connection, linking monitoring back to the design.
Host-level exceptions
Some flows are narrower than zones. The staff zone may reach the recorder only for viewing footage, not every CCTV device. Kofi records such host-level rules in a separate table alongside the zone model, with each exception tied to a needed flow. This keeps the zone model readable while making exceptions explicit. When counting reachability, he reports both the zone-level figure and the number of host-level exceptions, so the simplicity of the zone picture does not hide additional paths that exist in practice.
Model as a test oracle
The model is more than a diagram. Kofi uses it as the expected answer for tests: for any proposed flow, the model says whether it should be permitted. Later, the actual firewall configuration is tested against the model with synthetic flows, and any disagreement is either a configuration error or a model that needs updating. Keeping one authoritative model, rather than separate understandings in documents and devices, is what makes the later verification chapters possible. The model is versioned alongside the configurations, so each test result can be tied to the model version it used.
Worked example
Kofi computes transitive closure on the seven allowed edges and confirms no indirect path reaches servers from guest.
Synthetic case. Model data are synthetic.
Errors and limits
A zone-level model can hide host-level exceptions; record any host-specific rules separately.
Exercises
- EX064 — Reduction value. State the reduction in reachable zone pairs. Rubric: 3 = 30 to 7, 76.7%;; 2 = percent;; 1 = vague;; 0 = none.
- EX065 — Management sensitivity. Why is the management zone most sensitive? Rubric: 3 = reaches many zones;; 2 = access;; 1 = vague;; 0 = none.
- EX066 — Closure check. Why compute transitive closure? Rubric: 3 = detect indirect paths;; 2 = completeness;; 1 = vague;; 0 = none.
Synthesis
Modelling reachability shows the design's effect quantitatively and confirms key requirements.
Continue studying — chapter 22 of 50
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →