Chapter 7 — Network and communications security: controls and verification
Lesson map
Lesson 07 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Why review changes"]
N2["7.2 Review criteria"]
N3["Lab — Change review"]
N4["7.3 Reading the review"]
N5["7.4 Verifying implemented changes"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Why review changes"]
N2["7.2 Review criteria"]
N3["Lab — Change review"]
N4["7.3 Reading the review"]
N5["7.4 Verifying implemented changes"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]
[Learning outcomes]
|
v
[7.1 Why review changes]
|
v
[7.2 Review criteria]
|
v
[Lab — Change review]
|
v
[7.3 Reading the review]
|
v
[7.4 Verifying implemented changes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) review firewall change requests; (2) apply review criteria; (3) verify implemented changes.
7.1 Why review changes
Most firewall weaknesses come from changes made over time rather than the original design. A rule added for a project, a supplier or an urgent problem can widen access far beyond its need. Grace proposes that every rule change request is reviewed against simple criteria before approval. Wool's 2004 study of firewall configurations found errors common and increasing with rule base complexity, which supports reviewing each change rather than relying on occasional audits. Reviewing each change also spreads knowledge of the rule base across the team.
7.2 Review criteria
Grace's criteria are: the rule is specific, naming source, destination and service rather than "any"; it has a named owner; temporary rules have an expiry date; guest networks never reach internal systems; and the rule matches a documented need. These criteria are simple enough for the IT team to apply quickly and catch the most common problems. She writes them as a short checklist attached to the change request form. A request failing any criterion is returned with a short note explaining what to fix, which teaches requesters over time.
Lab — Change review
"""Check synthetic firewall change requests against simple review rules (stdlib only)."""
reqs = [{"id": "CR1", "src": "staff", "dst": "case-files", "port": 445, "owner": "IT", "temp": False, "expiry": None},
{"id": "CR2", "src": "any", "dst": "any", "port": None, "owner": "vendor", "temp": True, "expiry": None},
{"id": "CR3", "src": "partners-vpn", "dst": "case-files", "port": 443, "owner": None, "temp": False, "expiry": None},
{"id": "CR4", "src": "staff", "dst": "print", "port": 631, "owner": "Facilities", "temp": True, "expiry": "2026-05-01"},
{"id": "CR5", "src": "guest", "dst": "case-files", "port": 443, "owner": "Reception", "temp": False, "expiry": None}]
def issues(r):
out = []
if "any" in (r["src"], r["dst"]) or r["port"] is None: out.append("too broad")
if not r["owner"]: out.append("no owner")
if r["temp"] and not r["expiry"]: out.append("temporary without expiry")
if r["src"] == "guest" and r["dst"] != "internet": out.append("guest to internal")
return out
for r in reqs: print(r["id"], "; ".join(issues(r)) or "ok")
print("approve as submitted:", [r["id"] for r in reqs if not issues(r)])
Run with python3 lab_review.py. Verified output:
CR1 ok
CR2 too broad; temporary without expiry
CR3 no owner
CR4 ok
CR5 guest to internal
approve as submitted: ['CR1', 'CR4']
7.3 Reading the review
Of five synthetic requests, two can be approved as submitted: staff access to case files on the file-sharing port, and a temporary printing rule with an expiry. CR2, a vendor's request for any-to-any access without expiry, fails two criteria and should be rejected and rewritten as specific flows with an end date. CR3, partner VPN access to case files, has no owner, so it waits until one is named. CR5, guest access to case files, breaks the guest rule and is refused outright regardless of who requests it.
7.4 Verifying implemented changes
Approval is not the end. After implementation, Grace checks that the configured rule matches the approved request exactly and tests it: the permitted flow works and a neighbouring flow is still denied. She records the result in the change ticket. Verification catches typos, such as a wrong address range, that reviews of the request cannot. Over time, verified changes keep the rule base aligned with documented needs. If verification fails, the change is rolled back and the request returned. Verification takes about five minutes per change, a small cost compared with discovering a mistake months later.
Worked example
Two of five requests are approved; one is refused, one needs an owner and one must be rewritten.
Synthetic case. Requests are synthetic.
Errors and limits
Approving broad vendor rules to save time creates long-lived exposure.
Exercises
- EX031 — Approved requests. Which requests are approved as submitted? Rubric: 3 = CR1 and CR4;; 2 = two;; 1 = all;; 0 = none.
- EX032 — Vendor request. What should happen to CR2? Rubric: 3 = reject, rewrite as specific flows with expiry;; 2 = rewrite;; 1 = approve;; 0 = none.
- EX033 — Guest request. Why is CR5 refused outright? Rubric: 3 = guests never reach internal systems;; 2 = guest rule;; 1 = no owner;; 0 = none.
- EX034 — Verification test. Describe post-change verification. Rubric: 3 = config matches request, permitted flow works, neighbour denied;; 2 = test;; 1 = vague;; 0 = none.
- EX035 — Review evidence. Which study supports reviewing each change? Rubric: 3 = Wool 2004 on firewall errors;; 2 = Wool;; 1 = vague;; 0 = none.
Synthesis
Simple review criteria and post-change verification keep firewall rules specific and justified.
Continue studying — chapter 07 of 12
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →