◇ OpenCyber Academy
Bachelor's · Chapter 16 · English

Chapter 16 — Security architecture

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 16 — Security architecture

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 Defence in depth"]
  N2["16.2 Zones and boundaries"]
  N3["16.3 Management separation"]
  N4["16.4 Documenting architecture"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 Defence in depth"]
  N2["16.2 Zones and boundaries"]
  N3["16.3 Management separation"]
  N4["16.4 Documenting architecture"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX046"]
[Learning outcomes]
    |
    v
[16.1 Defence in depth]
    |
    v
[16.2 Zones and boundaries]
    |
    v
[16.3 Management separation]
    |
    v
[16.4 Documenting architecture]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) apply defence in depth; (2) design zones and boundaries; (3) document architecture.

16.1 Defence in depth

No single control is perfect, so security architecture layers controls so that one failing does not expose everything. At the clinics, Priya plans separate wireless networks, a firewall between groups, host firewalls on devices, encrypted connections to servers and central logging. If a visitor device is infected, the guest network separation stops it reaching clinical devices; if separation is misconfigured, host firewalls still limit what it can reach; and logging records the attempts for investigation either way. Each layer is chosen to cover a different failure, not to repeat another layer.

16.2 Zones and boundaries

A zone groups devices with similar trust and needs; a boundary between zones is where controls apply. Priya proposes four zones for each clinic: staff, clinical, guest and management. Traffic between zones passes through a firewall that permits only needed flows, following NIST SP 800-41r1 guidance on firewall policy, which recommends denying by default and allowing specific traffic. Within a zone, traffic flows more freely, which is why zones should be kept small and similar in purpose. Each zone's purpose is written in one sentence so new devices can be placed consistently.

16.3 Management separation

The devices that run the network, such as switches, access points and the firewall, need their own protected zone. If an attacker reaches a management interface, they can change the network itself, undoing every other control. Priya places management interfaces in a management zone reachable only from a dedicated administrator workstation, with administrator accounts protected by a second factor. This separation is often missing in small organisations, where management pages are reachable from the same network as everyone else. All administrative logins are logged centrally.

16.4 Documenting architecture

An architecture document records zones, boundaries, permitted flows and the reasons behind them. Priya includes a diagram, a table of zones with their subnets and a list of needed flows. She writes the reasoning for key choices, such as why clinical devices are separated from staff laptops. Documentation lets others review the design before it is built, and later lets the clinic team understand why a rule exists before changing it, which prevents well-intended changes from weakening the design. The document is reviewed whenever zones or flows change.

Worked example

Priya's architecture document has a one-page diagram, a four-zone table and eight needed flows between zones.

Synthetic case. The architecture is synthetic.

Errors and limits

Zones defined by building location rather than trust and purpose tend to mix devices with very different needs.

Exercises

Synthesis

Layered controls, purposeful zones and a protected management zone form a resilient architecture.

Continue studying — chapter 16 of 40

← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →