Chapter 29 — Network and communications security: measurement
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 What to measure"]
N2["Lab — Denied flows"]
N3["29.2 Reading the result"]
N4["29.3 Investigation"]
N5["Allowed flow analysis"]
N6["Trends over time"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 What to measure"]
N2["Lab — Denied flows"]
N3["29.2 Reading the result"]
N4["29.3 Investigation"]
N5["Allowed flow analysis"]
N6["Trends over time"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 What to measure]
|
v
[Lab — Denied flows]
|
v
[29.2 Reading the result]
|
v
[29.3 Investigation]
|
v
[Allowed flow analysis]
|
v
[Trends over time]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) measure policy effects; (2) analyse denied flows; (3) identify issues.
29.1 What to measure
After enforcement, Kofi measures denied flows by zone pair. Expected denies, such as guest to servers, show the policy working; unexpected denies point to missing rules or misbehaving devices.
Measures follow the success criteria agreed earlier: reachable zone pairs, required flows working, denied connections from guest devices, and change-related incidents. Each is collected the same way as the baseline.
Using the same collection method matters, because a change in method can produce a difference that looks like improvement but is really just a different way of counting. Kofi documents each method alongside the numbers so the comparison stays honest.
Lab — Denied flows
"""Summarise a week of synthetic denied flows by zone pair to find expected vs unexpected denies (stdlib only)."""
from collections import Counter
denies = [("staff","servers",3389)]*41 + [("cctv","staff",445)]*3 + [("guest","servers",443)]*118 + [("staff","cctv",554)]*9 + [("voice","staff",5060)]*2
c = Counter((a, b) for a, b, _ in denies)
expected = {("guest", "servers")}
for (a, b), n in c.most_common():
print(f"{a:6}->{b:8} {n:4d} {'expected' if (a,b) in expected else 'investigate'}")
print("total denies", len(denies), "| to investigate", sum(n for k, n in c.items() if k not in expected))
Run with python3 lab_flows.py. Verified output:
guest ->servers 118 expected
staff ->servers 41 investigate
staff ->cctv 9 investigate
cctv ->staff 3 investigate
voice ->staff 2 investigate
total denies 173 | to investigate 55
29.2 Reading the result
Of 173 denies in a week, 118 are guest to servers, expected. The remaining 55 need investigation: 41 staff remote desktop attempts to servers, nine staff connections to cameras, three camera connections to staff devices and two phone connections to staff.
Results are compared with baseline and target, noting uncertainty and anything unusual in the measurement period.
For example, a fall in reachable zone pairs from fifty-six to nine shows segmentation is in place, but the meaning depends on whether all nine remaining pairs are needed. Results are presented with their limits, so readers do not assume more certainty than the evidence supports.
29.3 Investigation
Remote desktop attempts come from staff who used to administer servers informally; they are directed to the jump host. Camera connections to staff are cameras trying to send email alerts; the supplier reconfigures them. Staff connections to cameras are a training issue: footage is viewed via the recorder.
Where results differ from expectations, Kofi investigates causes rather than adjusting the numbers, and records findings.
An investigation starts from the measurement, gathers relevant logs and configuration history, forms possible explanations, and tests each against the evidence. Findings may show a measurement error, a design gap, or an operational issue, and each leads to a different follow-up action.
Allowed flow analysis
Denied flows tell only half the story. Kofi also reviews a sample of allowed flows to check that permitted rules are used as expected. One rule permitting staff access to a legacy application shows no traffic for a month; its owner confirms the application was retired, and the rule is removed. Regularly reviewing rule usage keeps the policy from accumulating unused rules, the problem that research on firewall policies has repeatedly found in long-lived rule bases. Rule owners are asked to confirm their rules each quarter, which spreads responsibility beyond the network team.
Trends over time
A single week can mislead. Kofi tracks denied flows weekly for two months after each office migration. Unexpected denies spike in the first week as hidden dependencies surface, then fall as rules and habits adjust. A rise later would suggest a change elsewhere, such as a new device type, and triggers investigation. Plotting these trends gives managers a simple picture of the migration settling down. Each trend chart is annotated with migration dates and policy changes, so managers can link changes in counts to causes.
Worked example
After fixes, unexpected denies fall to four per week.
Synthetic case. Data are synthetic.
Errors and limits
Treating all denies as attacks wastes effort; most reveal configuration or habit issues.
Exercises
- EX085 — Expected share. What share of denies were expected? Rubric: 3 = 118 of 173;; 2 = most;; 1 = vague;; 0 = none.
- EX086 — Camera denies. What caused cameras to contact staff devices? Rubric: 3 = email alerts misconfigured;; 2 = config;; 1 = vague;; 0 = none.
- EX087 — Interpretation. Why not treat all denies as attacks? Rubric: 3 = most are configuration or habits;; 2 = noise;; 1 = vague;; 0 = none.
Synthesis
Measuring denies reveals hidden dependencies and habits.
Continue studying — chapter 29 of 50
← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →