Loading module…
Loading module…
Module 1 of 13
Rung one · the lens — a network read by its defender
A network that works looks like a network that is fine. Email arrives, the ERP answers, the line at the plant runs, and the person who keeps it all running has learned, sometimes the hard way, that the safest change is no change at all: it works, don't touch it. But most networks were never designed; they grew. A switch added under a desk for a test bench. A firewall rule opened "temporarily" for a supplier three years ago. A guest Wi-Fi plugged into the office network because that was the quickest way to have it working before a customer visit. A newly acquired site joined by a tunnel that lets everything through, because the integration project would sort it out later. Each decision was reasonable on the day it was taken. Together they produce a network that nobody can fully describe: no one can say what is connected to it, which devices talk to which, which of several hundred firewall rules still matter, or what anyone would see if something hostile were moving across it. This course's subtitle is its thesis: if you do not understand your network, you cannot defend it. It teaches the discipline of network defence from the point of view of the person who owns or is authorised to manage a network — how a network works, how to see what crosses it, how to arrange and maintain the controls that decide what may cross, and how to detect and respond when something does that should not. The method rests on six elements that every network has, from a ten-desk office to a multi-site manufacturer. Topology is what is connected to what: sites, zones, links, and the cloud services the business now depends on. Addressing and naming is how things find each other: the IP address plan, DHCP (the service that hands out addresses), and DNS (the service that turns names into addresses). Flows are who talks to whom, on which service, how much and when. Controls are the points where a flow can be allowed or refused: firewalls, the boundaries between segments, remote-access gateways and proxies. Visibility is what the defender can actually see: logs, flow records (one summary line per conversation: who, to whom, on which port, how many bytes, when) and detection sensors. And operations is the routine that keeps the other five true over time: change control, rule review, monitoring and response. Every read in the course answers four questions: what is connected, and should it be? what normally flows, and what changed? where can we control a flow, and do we? what would we see, and what would we do? One fictional organisation carries the whole course. Kestrel Motion, the servo-motor and drive maker you may know from earlier courses in this catalogue — above all Course 014 — has plants at Aldren and Brask in the Meridian Union, about 1,100 employees, an IT team of 9 that includes a security lead and one analyst, a managed-service provider, Corvane IT Services, and Brenholt Foundry, acquired in Course 013 and not yet integrated. In Course 014 the security lead's posture assessment produced a programme of fixes approved by the board; three of its parts are network work — segmenting office IT from the Aldren plant (014's K3), securing remote and supplier access (K1, K7), and centralising logs into a detection service (K6). This course follows Kestrel's network engineer — a role, not a named person — who implements those parts over 12 months with the security lead. At Month 0 the engineer inherits, in round illustrative numbers: one flat network at Aldren in which office PCs, servers and the plant's line controllers can all reach one another; one internet firewall with about 410 rules, many of them "any-any" (any source to any destination on any service) with no owner and no expiry; a staff VPN that accepts a password alone, with no multi-factor authentication (MFA), plus VPN accounts for two suppliers; firewall and email logs kept 30 days, endpoint logs not centralised, no flow records and no DNS logging; a guest Wi-Fi bridged into the office network; and Brenholt joined by a site-to-site VPN with an allow-all rule. Only Brask's plant network already sits behind its own firewall. This module lays out the network defender's map, the transformation the course produces and the thirteen-rung method — and it draws the boundary first. This is a defender's and network owner's course. It never teaches offensive technique: no exploitation, no payloads, no attack-tool usage, no evasion of firewalls or intrusion detection, no interception of other people's traffic, nothing on persisting in or moving through a network. Adversary behaviour appears only as what it looks like on the wire to a defender, named at the level of MITRE ATT&CK tactics and public advisories, together with how to detect and block it. Discovery and testing happen only on networks you own or are authorised in writing to manage or test, and only within the agreed scope. Configuration is taught as vendor-neutral policy — tables of intent, source zone, destination zone, service, action, owner, expiry and logging — never as device commands to copy. Traffic data is personal data more often than it looks, so collection is kept to what the purpose needs. Every claim about traffic is labelled fact, assessment or speculation with its source; judgements carry a probability from the course's seven-band yardstick and a separate confidence of high, moderate or low (or not known); and every money and time figure is a range or marked illustrative.
The six elements are the periodic table of this course, and the map draws them in the one arrangement that shows how they act on each other — so read it as a mechanism, not as a list of boxes. The zones are the first idea. A zone is a group of devices that share a business function and a level of risk and that should therefore share one access policy: the office PCs, the business servers, the plant's control systems, the guest devices, the administrative interfaces. Zones are a defender's idea, not a cabling fact; on the wire they are usually built as VLANs (virtual LANs that let one physical switch carry several separate networks) and subnets (ranges of IP addresses, written like 10.20.0.0/16, where the number after the slash says how many leading bits are fixed — a /16 holds about 65,000 addresses, and inside one flat /16 every device can usually reach every other unless something sits between them). Internal networks normally use the private address ranges of RFC 1918, which are not routed on the public internet; that is why the edge, where private addresses are translated to public ones, is a natural control point. The second idea is the conduit: the permitted path between two zones, with the gate — a firewall or other filtering point — that enforces what may use it. The words zones and conduits come from IEC 62443, the standards family for industrial automation security, and they work as well for an office as for a plant: the defender's question is never just "do we have a firewall?" but "which conduits exist, and does each one pass through a gate that allows only what the business needs?" A conduit with no gate is the defining weakness of a flat network: nothing stops traffic moving east-west (sideways, between internal devices), so the first compromised laptop can reach every server and every line controller. The edge firewall only governs north-south traffic (in and out of the organisation), which is why a strong edge around a flat inside is often described as a hard shell with a soft centre. The third idea is the flow, drawn as an arrow whose weight shows volume: a defender needs to know not only that a conduit exists but who uses it, on which service, how much and at what hours — the baseline of normal against which a change becomes visible. The fourth is the sensor: the eye on the map where traffic is recorded or inspected. Firewall logs, flow records in the or formats (the common standards for exporting one summary record per conversation from switches, routers and firewalls), DNS query logs and sensors each see different things, and none sees what does not cross it — which is why sensor placement is a design decision rather than a purchase. The fifth idea is the : the internet firewall, the remote-access gateway through which staff and suppliers enter, and the (a separate zone for services the internet must reach, so that a public web service does not sit inside the office network). And on the right sits the — map, baseline, control, detect, respond, review — because every other part of the map decays: devices are added, flows change, rules accumulate, and a map that was true in January is wrong by June unless a routine keeps it true. The four questions are exactly the parts of the drawing: is the zones and the devices in them; is the arrows and their baseline; is the gates; and is the sensors and the loop. The central idea follows from the drawing. A network's defensibility is an of its arrangement: an excellent firewall at the edge, an expensive detection tool and a strict password policy can each be "in place" while the arrangement still leaves a straight, unwatched path from one stolen login to a plant controller — and a defender who audits the parts one at a time will never see it. Every later module lights one part of the map: Module 3 the layers and a single flow, Module 4 the zones and the inventory, Module 5 the flows and their baseline, Module 6 one anomalous flow, Module 7 the gates, Module 8 the new conduits, Module 9 the sensors, Module 10 the edge and its remote doors, Module 11 the incident path and its containment, Module 12 the operations loop, and Module 13 the whole map before and after.
Traced instance: Kestrel's map at Month 0, eight observations and ten changes. The network engineer's first job is not to change anything but to fill the map from evidence, and every item carries its basis; all figures in this universe are illustrative. With written authorisation and an agreed scope covering Kestrel's own networks only, the engineer runs discovery at Aldren, reads the switches' address tables and the DHCP leases, and compares the result with the asset records: about 1,350 devices answer, and about 180 of them are in no inventory at all — printers, cameras, test benches and two unmanaged switches (O1, fact). A review of the internet firewall finds that about 160 of the 410 rules have not matched a single packet in 90 days, that 27 are any-any, and that 4 expose internal services to the internet for reasons no one can explain (O2, fact). Two simple checks complete the picture of the doors: a guest Wi-Fi client can reach the office printers, because the guest network is bridged into the office VLAN (O6, fact); and the Brenholt site-to-site VPN allows everything, both ways (O7, fact). Other entries on the map cannot yet be filled, and the engineer marks them honestly as not known: what normally flows between IT and the Aldren plant, what the DNS servers are being asked, and whether anything inside talks where it should not — because at Month 0 there are no flow records and no DNS logs to answer from. The sequence of the plan follows from that gap. The cheapest, most urgent doors close first: N1, MFA on the staff VPN and on supplier access, and N2, the Brenholt tunnel cut to deny-all except the email and file-transfer flows the business needs, both logged, are done in Month 1. N5 separates guest and IoT devices into an internet-only zone in Month 2. N4, the rule clean-up, runs through Months 2–4: every rule gets an owner and an expiry date, unused rules are disabled, then removed after 30 days, and the 4 unexplained exposures are closed. N3, in Month 3, gives the engineer eyes: flow records exported from the switches and firewalls and DNS query logging, kept 90 days and sent into the security information and event management () platform run by Kestrel's managed detection and response () provider. Only then do the hidden flows appear. Traffic from the IT side into the Aldren plant turns out to come from just in the office and the in the servers zone — the server that records process data from the line controllers — when it should come only from the historian (, fact). DNS logs show look-ups a day to newly registered domains, almost all from ordinary web browsing and benign (, assessment). And a lab PC in the office opens file-sharing (SMB) connections to office hosts every night (, fact), which, investigated rather than assumed, proves to be a legitimate but misconfigured backup job. With the baseline in hand, the larger changes can be designed rather than guessed: creates a management zone in , so that admin interfaces are reachable only from a jump host (one hardened machine that administrators log in to first) with named accounts; moves supplier access onto a brokered, logged, MFA-protected path in ; segments Aldren's IT from its OT over , putting the plant behind an internal firewall that only the historian may cross, on two ports, and moving the engineering PCs into an OT-engineering zone of their own — with the production line stopped for a planned window in ; places IDS sensors at the OT boundary and at the internet edge over , tuned for 6 weeks; and adds egress filtering for servers in , so that they may reach only listed external destinations. One observation came late and at a cost: Corvane's old remote-access tool was still listening on a Brenholt server, and it was found only in , after an incident (, fact). The map was right about what it showed; what it did not yet show was an inventory of Brenholt.
The gap between the two is the whole value of the course — and it is worth being fair to the admin first. "It works, don't touch it" is not laziness; it is a lesson learned from real outages, because a careless change to a firewall or a switch can stop a plant as surely as an attacker can. The network defender does not reject that lesson; it replaces fear of change with discipline of change (Module 2's B5: a reason, a record, an approval and a way back), so that the network can be improved without being broken. Each of the admin's habits fails in its own way. The first is having no current map. Without one, the question what is connected? has no answer, and every later control is built on a guess: Kestrel's 180 unknown devices (O1) included two unmanaged switches — links no one had approved — and the old remote tool at Brenholt (O8) was exactly the kind of forgotten device an inventory exists to find; Module 4 is built on that lesson. The second is running one flat network. Flatness turns any single foothold into access to everything, and the public record shows the cost. In the Target breach of 2013, attackers are widely reported to have entered with credentials belonging to an HVAC (heating and ventilation) contractor and to have moved from there towards payment systems on a network that was not well segmented. In 2017, NotPetya spread rapidly across flat, well-connected corporate networks; the shipping company Maersk was among those badly hit and rebuilt its network afterwards. In both cases the damage was shaped less by the first foothold than by how far the network let it travel. The third habit is keeping any-any rules that nobody owns. A rule without an owner cannot be reviewed, because no one can say whether it is still needed, and a rule without an expiry outlives the project that justified it; Kestrel's 160 rules that matched nothing in 90 days and its 4 unexplained internet exposures (O2) are what a rulebase looks like after years of that. NIST SP 800-41, the US government's general guidance on firewalls and firewall policy, recommends the alternative this course teaches in Module 7: deny by default and allow only the traffic that is needed. The fourth habit is keeping logs nowhere anyone looks — 30 days of firewall logs that no one reads, and no flow records at all — so that when a question arises, the evidence either never existed or has already been deleted. The fifth is having no baseline, which makes every observation meaningless: without knowing that nothing on the IT side should talk to the plant except the historian, three engineering PCs talking to the line controllers (O3) look like any other traffic. The sixth is , which is the real reason the admin fears change: when nobody recorded what was changed, nobody can undo it. The seventh is . In the ransomware attack of , which led the company to shut down its pipeline, initial access was reported to have come through a legacy VPN account that did not have MFA. And the eighth is : if the help-desk queue is the detection system, time to detect is measured in days. The replaces each habit with a discipline. It keeps a , updated by every change rather than by an annual project. It , so that a foothold in the office does not reach the plant. It runs at every gate, with every rule carrying an intent, an owner and an expiry. It builds of what normally flows, zone by zone, hour by hour, so that something new stands out. It where the important traffic actually crosses — the edge, the boundary of the plant — rather than wherever a box was easiest to install. It until the ones that fire are worth reading, because an alert nobody trusts is the same as no alert. It , so that any change can be undone. And it has a — who confirms, who scopes, who may isolate a host or cut a link — before the first real incident. None of these habits is exotic: they line up closely with the network monitoring and defence safeguards of the , a widely used prioritised list of security practices; what the course adds is how to do each one on a real network, in the right order. At Kestrel, the network defender's work was tested twice. In (, the same incident Course 014 follows), credentials were phished from a Brenholt employee; the attempted VPN login was (N1); a second attempt through Corvane's old remote tool on a Brenholt server was , using the new flow and endpoint data (N3), and contained; and because the Brenholt tunnel had been cut to deny-all in Month 1 (N2), the session — the attempt stayed at Brenholt. Seen on the wire, an episode of this kind is a login from somewhere unusual followed by connections that do not match the baseline, which is the level at which this course describes adversary behaviour (ATT&CK's and , as a defender observes them). The blameless review found the network lesson (B6): the old tool should have been found by inventory, so O8 became the reason Brenholt's discovery work moved up the list. In (), the edge IDS (N9) flagged a server in the servers zone trying to reach an unlisted external address every night; egress filtering (N10) had already it, so the engineer could investigate without urgency. The cause was an outdated software-update component calling a vendor's old address — — fixed by updating the component and listing the new address. E2 is as instructive as E1: egress filtering plus logging make the strange both and . By the review (illustrative), unknown devices had fallen from about , firewall rules from , every one owned and expiring, any-any rules from ; the Aldren plant was reachable only from the historian and the OT-engineering zone; and network alerts in both incidents were detected . Two items remained open, and the review said so plainly: Brenholt's full integration, and a second network detection and response () sensor at Brask.
The course is thirteen modules, and their order follows the four questions: you cannot control what you have not mapped, and you cannot detect what you have not baselined. After this orientation, Module 2, The Network Defender's Discipline & Boundary, installs the six commitments that govern everything else, tagged B1–B6 and cited by those tags throughout. B1, defend and never attack: no offensive technique and no evasion, with adversary behaviour read only as what a defender observes. B2, authorisation and scope: work only on networks you own or are authorised in writing to manage or test — scanning anyone else's network is out. B3, evidence over hunch: every claim about traffic is sourced from a log, a flow record or a capture, and graded as fact, assessment or speculation, with probabilities taken from the seven-band yardstick — almost no chance (1–5%), very unlikely (5–20%), unlikely (20–45%), roughly even chance (45–55%), likely (55–80%), very likely (80–95%), almost certain (95–99%) — and a separate confidence of high, moderate or low, or not known where the gap is real. B4, privacy in the traffic: collect only what the purpose needs, protect who can see it, set retention, and inspect content only with a legal basis. B5, change discipline: no change without a reason, a record, an approval and a way back. B6, blameless incident learning and honest reporting. Module 2 is a gate: the rest of the course assumes it. Modules 3 and 4 answer the first question. How Networks Work — the Defender's Model gives the working model a defender needs, without the textbook detours: the layers of the TCP/IP and OSI models in practice and where each kind of control sits (L1), IP addressing, subnets and routing (L2), TCP, UDP and ports — the sessions a defender can read (L3), DHCP, ARP (how a device finds its neighbour's hardware address on the local segment) and the local segment (L4), DNS as the network's phone book and one of its most useful signals (L5), and where NAT, VPNs and cloud links put the real boundary (L6). Inventory & Mapping Your Own Network covers why the map is always out of date (Y1), authorised discovery of your own estate from scans, switch and DHCP tables and asset systems (Y2), the network diagram that is actually useful (Y3), address management and naming (Y4), shadow devices and unmanaged links (Y5), and keeping the map alive through change (Y6). answer the second question. covers what to capture — full packets, flow records or logs (F1) — reading flow records (F2), baselines by hour, day and zone (F3), DNS and web-proxy logs as signals (F4), what encrypted traffic still reveals through its metadata (F5), and privacy and retention in traffic data (F6). separates the strange from the dangerous: anomaly versus attack, since most oddities are benign (A1), volume and timing anomalies (A2), new talkers and new destinations (A3), east-west traffic that should not exist (A4), what common adversary tactics — initial access, lateral movement, command and control, exfiltration — look like to a defender, at observation level only (A5), and triage from anomaly to case (A6). answer the third question and begin the fourth. covers what firewalls do and do not do (W1), default-deny and least privilege for flows (W2), rules with an intent, an owner and an expiry (W3), rule review and clean-up of shadowed, unused and too-broad rules (W4), egress filtering (W5), and logging and change control for the rulebase (W6). covers why flat networks fail (S1), zones and conduits (S2), designing segments from business function and risk (S3), IT/OT separation with IEC 62443 and the (the layered reference model for industrial networks) at a general level (S4), micro-segmentation and identity-aware access following the zero-trust principles of (S5), and migrating from flat to segmented without stopping the business (S6). covers IDS and IPS and where to place sensors, with as general guidance (D1), signatures versus behaviour and anomaly detection (D2), tuning against false positives, false negatives and alert fatigue (D3), network detection and response with SIEM correlation (D4), detection engineering at a defender's level — from a known threat to a detection idea (D5), and measuring detection by coverage and time to detect (D6). covers VPN versus brokered, zero-trust access (R1), MFA on every remote door (R2), supplier and third-party access paths (R3), business Wi-Fi with and guest isolation (R4), internet-facing services, the DMZ and exposure review (R5), and DNS and email protections at the edge, including the general purpose of (R6). answer and keep it true. covers the first hour — confirm, scope, contain (I1) — containment options and their side effects (I2), preserving logs, flows and captures lawfully (I3), coordination with IT, OT and the business (I4), recovery and verification (I5), and post-incident network improvements (I6). turns the work into a routine: the operations calendar, configuration management and backups, the metrics that matter (unknown devices, rule age, time to detect and contain), reporting to the security lead and the board, authorised testing and tabletop exercises, and continuous improvement. runs the whole method on Kestrel, from the Month 0 map to the Month 12 review, and compresses it into a master equation and a self-assessment. Every module from 2 to 12 is built the same way: six , the sub-techniques of its rung, each with a tag (Module 3's L1–L6, Module 7's W1–W6, and so on) and each dissected through six fixed fields — it is, its (drawn on the network defender's map), the as a numbered procedure, its and failure modes, to use it and when not, and it connects to the rest. Kestrel is traced through every atom, with its observations , its network changes with their months, and its incidents and . The world is fictional so that a whole network can be shown — weaknesses included — without exposing anyone's real systems, and its people are named by role only: the network engineer, the security lead, the analyst, Corvane, the MDR provider. Where the course uses real-world material — public standards and frameworks and a handful of well-documented incidents — it stays at the level the public record supports.
This is a dissection course, not a product tour: every technique is broken down to its mechanism and its procedure, so you finish not with a list of tools but with a repeatable way to understand, control and watch a real network — and to explain it to the people who must fund and approve the work. Three things to hold onto as you go. First, see before you change: map what is connected, then baseline what flows, and only then design the gates. Kestrel's engineer closed the obvious doors in Month 1, but designed the Aldren segmentation only after flow records showed which devices actually crossed into the plant (O3); a segmentation project designed from a guess either breaks production or leaves the real path open. Second, every claim has a source and a grade: "the lab PC is scanning the office" is a hunch; "the lab PC opened SMB connections to 40+ office hosts every night this week, per flow records (fact); we judge it more likely a scheduled job than hostile activity (assessment), moderate confidence, pending a check with its owner" is evidence a colleague can act on — and in Kestrel's case the check found a misconfigured backup job (O5). Most anomalies are benign; the discipline is to find that out rather than assume it in either direction. Third, stay on the defender's side of the line: this course reads adversary behaviour only as it appears on the wire to a defender, at the level of ATT&CK tactic names and public advisories, and never at the level of how to act (B1); you discover, scan and test only what you own or are authorised in writing to test, within the agreed scope (B2) — Kestrel's discovery ran only on its own networks, under written authorisation and an agreed scope; and you collect from traffic only what the purpose needs (B4). One note on scope: the course teaches policy and design in vendor-neutral terms, so its rule tables translate to any firewall but are not commands for any particular one; and it is not legal advice on monitoring, retention or evidence in any real jurisdiction — wherever a question turns on the law, the course's answer is to take it to counsel. Hold those three and the rest is detailed machinery. Module 2 makes the discipline explicit first, because the same knowledge that lets a defender see a network clearly must be held to a strict standard of authorisation, restraint and honesty.
Before the first device is mapped, the course installs the discipline that governs the whole method. Module 2 is the network defender's boundary, in six commitments tagged B1–B6: defend, never attack — no offensive technique and no evasion, with adversary behaviour read only as what a defender sees (B1); authorisation and scope — only networks you own or are authorised in writing to manage or test (B2); evidence over hunch — every claim about traffic sourced from a log, flow or capture and graded fact, assessment or speculation, with calibrated probability and confidence (B3); privacy in the traffic — collect what the purpose needs and protect what you collect (B4); change discipline — no change without a reason, a record, an approval and a way back (B5); and blameless incident learning with honest reporting (B6). The network defender's map is a powerful instrument; Module 2 is what keeps it lawful, accurate and safe to use.
The signature image of the course: one network drawn the way its defender must see it — here Kestrel Motion at Month 0. At the top left, the internet, from which staff working from home, suppliers and Corvane connect. Below it, the edge: the internet firewall with its ~410 unowned rules, a remote-access VPN on passwords alone, and the internet-facing services, with 4 internal services exposed that no one can explain. Inside, zones as rounded boxes, joined by conduits that pass through gates — present, weak, missing or wide open. Aldren is one flat network with no internal gate between the office, the servers and the plant (OT); Brask is gated; Brenholt hangs off an allow-all tunnel. Arrows are flows, drawn heavier where there is more traffic; eyes are sensors, dashed where no one is looking. On the right, the operations loop that does not yet exist, the four questions keyed to the parts of the map, and the illustrative Month 12 review; below, the ten network changes N1–N10 and the two incidents E1 and E2.
The transformation the course produces. The "it works, don't touch it" admin has no current map, runs one flat network, keeps any-any rules nobody owns, keeps logs nowhere anyone looks, has no baseline, changes things live with no record or way back, leaves remote doors on a password alone and learns of trouble from the help desk. The network defender keeps a current map, segments by business function and risk, runs default-deny with owned and expiring rules, baselines what normally flows, places sensors where traffic crosses, tunes alerts until they are worth reading, records every change and backs up every configuration, and has a practised first hour. At Kestrel, by Month 12 (illustrative), unknown devices fall from ~180 to ~12, rules from ~410 to ~190 and any-any rules from 27 to 0, and the Month 5 incident is detected in 40 minutes and held at Brenholt. Same network, same people; one keeps it running, the other can also see, control and recover it.
How the course is built. Phase 1 sets the lens and the line (Modules 1–2). Phase 2 answers what is connected, and should it be? — how networks work and how to map your own (Modules 3–4). Phase 3 answers what normally flows, and what changed? — traffic and flow analysis, and anomaly detection (Modules 5–6). Phase 4 answers where can we control a flow, and do we? and begins what would we see? — firewalls, segmentation, intrusion detection and the edge (Modules 7–10). Phase 5 answers what would we do? — incident response, running network defence as a routine, and the capstone (Modules 11–13). Under every rung run the six commitments of Module 2, B1–B6.