Chapter 20 — Network and communications security: engineering context | Engineering Network and communications security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 20 — Network and communications security: engineering context

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 Current state"]
  N2["20.2 Constraints"]
  N3["20.3 The engineering problem"]
  N4["20.4 Success measures"]
  N5["Learning from the incident"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX058"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["20.1 Current state"]
  N2["20.2 Constraints"]
  N3["20.3 The engineering problem"]
  N4["20.4 Success measures"]
  N5["Learning from the incident"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 Current state]
    |
    v
[20.2 Constraints]
    |
    v
[20.3 The engineering problem]
    |
    v
[20.4 Success measures]
    |
    v
[Learning from the incident]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) describe the council's current network; (2) identify constraints; (3) frame the engineering problem.

20.1 Current state

Ashcombe's eight offices connect over leased lines to the main office, which hosts most servers and the internet connection. Inside each office, one flat subnet holds all devices. Guest Wi-Fi shares this subnet, separated only by a captive portal. The CCTV supplier reaches cameras through a remote access appliance that bypasses the edge firewall. Kofi documents this from configuration exports and site visits, never by scanning.

Kofi records this state with dated evidence so later improvements can be measured.

This baseline is shared with the council.

20.2 Constraints

The council has a limited budget, two network engineers and services that cannot be interrupted during working hours. Some devices, like older phones and cameras, cannot be reconfigured easily. Any design must be implemented in phases over a year and operated by the existing team afterwards. These constraints rule out designs that need specialist skills or continuous tuning.

Constraints include budget, staff skills, existing equipment, and the need to keep services running during change. Writing them down early prevents designs that cannot be delivered.

20.3 The engineering problem

Kofi states the problem: design and implement segmentation and secure inter-office connectivity so that guest and compromised devices cannot reach internal services, supplier access is controlled, and services remain available, within budget and team capacity. Each part of this statement becomes a group of requirements in the next chapter.

Stated clearly, the problem is to separate devices into zones with only needed flows allowed, and secure links between offices, within the constraints and without disrupting services. A clear statement keeps later work focused on what matters.

20.4 Success measures

He proposes measures: reachable zone pairs, unexpected denied flows, VPN availability, added latency and change failure rate. These will be measured before and after implementation.

Success measures turn goals into checks. Examples include the number of reachable zone pairs before and after, the share of required flows working on day one, time to detect a denied connection from the guest zone, and the number of incidents caused by changes. Each measure has a baseline, a target, and a method of collection, agreed with the council before work starts so that results cannot later be reinterpreted to look better.

Learning from the incident

The guest laptop incident is the clearest evidence of the problem. Council logs show the infected laptop attempted connections to file servers on the file-sharing port for several hours before a staff member noticed the slow network. Nothing in the flat design stopped the attempts, and nothing alerted anyone. Kofi treats the incident as a case study rather than a crisis: it shows that a single untrusted device could reach internal services, and that monitoring would not have caught it. Both gaps become requirements, and the incident timeline becomes a test scenario for the finished design.

Worked example

The current-state document includes a site table, a logical diagram of the flat network and a list of eleven known issues.

Synthetic case. The council and network are synthetic.

Errors and limits

Documenting current state from old diagrams alone misses undocumented changes; use configuration exports.

Exercises

EX058 — Supplier bypass. Why is the CCTV supplier's appliance a concern? Rubric: 3 = bypasses edge firewall, uncontrolled entry;; 2 = risk;; 1 = vague;; 0 = none.
EX059 — Constraint impact. How do team constraints shape the design? Rubric: 3 = simple, operable by two engineers;; 2 = simpler;; 1 = vague;; 0 = none.
EX060 — Measure list. List five success measures. Rubric: 3 = five;; 2 = four;; 1 = fewer;; 0 = none.

Synthesis

A precise problem statement with constraints and measures guides the whole design.

Continue studying — chapter 20 of 50

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →