OpenCyber AcademyLesson map
Lesson 27 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes"]
N1["27.1 Policy specification"]
N2["Lab — Evaluating flows"]
N3["27.2 Reading the evaluation"]
N4["27.3 Management access"]
N5["27.4 Logging design"]
N6["Policy for internet access"]
N7["Configuration consistency"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["27.1 Policy specification"]
N2["Lab — Evaluating flows"]
N3["27.2 Reading the evaluation"]
N4["27.3 Management access"]
N5["27.4 Logging design"]
N6["Policy for internet access"]
N7["Configuration consistency"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]
[Learning outcomes]
|
v
[27.1 Policy specification]
|
v
[Lab — Evaluating flows]
|
v
[27.2 Reading the evaluation]
|
v
[27.3 Management access]
|
v
[27.4 Logging design]
|
v
[Policy for internet access]
|
v
[Configuration consistency]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes
You will (1) specify firewall policies; (2) design management access; (3) design logging.
27.1 Policy specification
The policy is specified as a table and as code. Each rule names zones, services and action, ending in default deny.
The policy specification states, for every pair of zones, which services are allowed and why, with everything else denied. It is written in a structured table that both people and scripts can read. Because it is the source of truth, the firewall configuration is checked against it, not the other way round, and changes to access start by changing the specification and getting it approved.
Lab — Evaluating flows
"""Evaluate synthetic flows against a first-match zone policy with default deny (stdlib only)."""
policy = [("staff", "servers", 443, "allow"), ("staff", "servers", 445, "allow"), ("voice", "servers", 5061, "allow"),
("cctv", "servers", 554, "allow"), ("mgmt", "*", 22, "allow"), ("*", "*", None, "deny")]
flows = [("staff", "servers", 443), ("staff", "servers", 3389), ("guest", "servers", 443), ("cctv", "servers", 554),
("cctv", "staff", 445), ("mgmt", "cctv", 22), ("voice", "servers", 5061), ("staff", "cctv", 554)]
def decide(f):
for i, (s, d, p, a) in enumerate(policy, 1):
if s in ("*", f[0]) and d in ("*", f[1]) and p in (None, f[2]): return a, i
for f in flows:
a, i = decide(f); print(f"{f[0]:6}->{f[1]:8}:{f[2]:<5} {a:5} (rule {i})")
print("allowed", sum(decide(f)[0] == "allow" for f in flows), "of", len(flows))
Run with python3 lab_policy.py. Verified output:
staff ->servers :443 allow (rule 1)
staff ->servers :3389 deny (rule 6)
guest ->servers :443 deny (rule 6)
cctv ->servers :554 allow (rule 4)
cctv ->staff :445 deny (rule 6)
mgmt ->cctv :22 allow (rule 5)
voice ->servers :5061 allow (rule 3)
staff ->cctv :554 deny (rule 6)
allowed 4 of 8
27.2 Reading the evaluation
Of eight synthetic flows, four are allowed by specific rules and four denied by the default rule, including guest to servers and staff to servers over remote desktop. The latter is a deliberate decision: remote desktop to servers is only allowed from management.
Evaluating the policy against the flow model shows which needed flows are covered and which allowed flows are unneeded. Any mismatch is investigated before deployment.
Typical findings include allowed flows left over from earlier testing, needed flows that the specification forgot, and rules broader than the flow requires, such as a whole subnet where one server would do. Each finding is resolved by updating either the specification or the rules.
27.3 Management access
Management uses a jump host with multi-factor authentication; device management interfaces accept connections only from it.
Management access to network devices is limited to a dedicated management zone reached only from approved administration workstations. Administrators authenticate individually, with multi-factor authentication, so actions are attributable to a person. Every session is logged. Separating management traffic this way means a compromised staff laptop cannot reach device consoles, and audit records show exactly who changed what and when.
Emergency access procedures are also documented and tested.
27.4 Logging design
All denies and a sample of allows are logged with the common schema.
Logging design decides what each device records and where it goes. Firewalls log denied connections and selected allowed ones, VPN gateways log connections and authentications, and devices log configuration changes. Logs are sent promptly to a central store with synchronised clocks, so they survive if a device is wiped. The design also sets retention and access controls, since logs themselves contain sensitive information.
Log volumes are estimated in advance to size storage.
Policy for internet access
Each zone's access to the internet is also controlled. Staff browse through the council's web filter; phones reach only the provider's services; cameras reach only the supplier's update server during maintenance; guest Wi-Fi reaches the internet but nothing internal. Kofi writes these outbound rules with the same care as internal ones, because unrestricted outbound access lets compromised devices contact attackers' systems freely, and limiting it is one of the most effective controls a small organisation can apply. Outbound denies are reviewed weekly alongside internal ones, since they can reveal infected or misconfigured devices.
Configuration consistency
With nine firewalls across eight offices, consistency matters. Kofi generates each branch policy from a common template and a small per-site file listing local subnets. Differences between branches are limited to these local values. A script compares deployed policies with generated ones and reports any drift, which addresses a common failure where one site's firewall is changed during an emergency and never brought back into line. Any drift found is either corrected or, if intended, added to the per-site file through a normal reviewed change.
Worked example
Adding a test for each flow ensures future changes do not alter these outcomes unnoticed.
Synthetic case. Flows are synthetic.
Errors and limits
Logging every allow on busy links can overwhelm storage; sample or summarise.
Exercises
- EX079 — Allowed count. How many flows were allowed?
Show marking criteria
Rubric: 3 = 4 of 8;; 2 = four;; 1 = vague;; 0 = none. - EX080 — RDP decision. Why is staff→servers RDP denied?
Show marking criteria
Rubric: 3 = only management may administer;; 2 = policy;; 1 = vague;; 0 = none. - EX081 — Allow sampling. Why sample allowed flows rather than log all?
Show marking criteria
Rubric: 3 = volume;; 2 = storage;; 1 = vague;; 0 = none.
Synthesis
A specified, tested policy with controlled management access is the core control.
Continue studying — chapter 27 of 50
← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →