Chapter 14 — Network and communications security: methods I
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Requirements"]
N2["14.2 Planning migration"]
N3["14.3 Designing tests"]
N4["14.4 Fixed-address devices"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Requirements"]
N2["14.2 Planning migration"]
N3["14.3 Designing tests"]
N4["14.4 Fixed-address devices"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Requirements]
|
v
[14.2 Planning migration]
|
v
[14.3 Designing tests]
|
v
[14.4 Fixed-address devices]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) write requirements; (2) plan zone migration; (3) design tests from requirements.
14.1 Requirements
Tomás writes requirements that state what must be true. R1: students and guests cannot reach the administration or management zones. R2: traffic between zones is denied unless listed as a needed flow. R3: network devices are managed only from the management zone using encrypted protocols. R4: staff wireless uses individual accounts. R5: all zones use the school's DNS resolvers. R6: firewall and switch logs are sent to a central store and kept for ninety days. Numbered requirements let tests, changes and reports refer to them precisely.
14.2 Planning migration
Moving from one subnet to six zones affects every device. Tomás plans the migration in stages during the summer holiday: first create the management zone and move switches and access points into it; then create the administration zone and move finance and records systems; then separate students, staff, shared devices and guests. Each stage has a test list and a rollback step. Staging limits the number of things that can go wrong at once and makes problems easier to trace.
14.3 Designing tests
Tests come from requirements. For R1, a test device in the student zone attempts connections to administration and management services, expecting all to fail, and also to the learning platform, expecting success. For R3, Tomás confirms switch management works over SSH from the management zone and fails from the staff zone, and that Telnet is disabled. Each test has an expected result recorded before running. Testing both what should work and what should fail catches rules that are too strict as well as too loose.
14.4 Fixed-address devices
Many school devices have fixed addresses set by hand: printers, projectors and the heating controller. They will not move to new zones automatically. Tomás and Gareth list them from the inventory, plan new addresses and schedule each change. Projectors in classrooms need testing before term starts, because a projector that fails on the first day of term causes immediate disruption. Fixed-address devices are often the most time-consuming part of a migration, so they are planned in detail rather than handled ad hoc.
Worked example
Six requirements, three migration stages and twenty-two tests are planned; forty-one fixed-address devices are scheduled for readdressing.
Synthetic case. Plans are synthetic.
Errors and limits
Tests that only check permitted flows miss rules that allow too much.
Exercises
- EX040 — Migration order. Which zone is created first, and why? Rubric: 3 = management, so network devices are protected and reachable for later steps;; 2 = management;; 1 = students;; 0 = none.
- EX041 — R1 test design. Describe a test for R1. Rubric: 3 = student test device to admin/management fails, learning platform succeeds;; 2 = attempt;; 1 = vague;; 0 = none.
- EX042 — Projector timing. Why test projectors before term starts? Rubric: 3 = failures disrupt first lessons;; 2 = disruption;; 1 = vague;; 0 = none.
Synthesis
Clear requirements, staged migration and requirement-based tests make change safe.
Continue studying — chapter 14 of 30
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →