Chapter 8 — Security architecture basics

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Layers"]
  N2["8.2 Human roles"]
  N3["8.3 Containing mistakes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Layers"]
  N2["8.2 Human roles"]
  N3["8.3 Containing mistakes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Layers]
    |
    v
[8.2 Human roles]
    |
    v
[8.3 Containing mistakes]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) describe layered defences for a clinic group; (2) place human roles in the architecture; (3) design so that a single mistake is contained.

8.1 Layers

Lucas sketches Brightwell's security layers: email filtering, external tags, multi-factor authentication, least privilege, backups and monitoring by the IT contractor. Saltzer and Schroeder (1975) described principles such as least privilege and psychological acceptability, which means protection should be easy to use correctly. Lucas checks each layer for both principles. He finds that backups exist but have never been tested, and that monitoring alerts go to a mailbox nobody reads after hours. He lists both issues for the IT contractor, who agrees to run a restore test and to forward urgent alerts to an on-call phone.

8.2 Human roles

Lucas adds human roles to the architecture: receptionists who report suspicious emails, managers who approve exports, the practice manager who approves payments and the IT contractor who reviews reports. Each role needs tools and time. He notes that reporting is a detection layer: staff who report quickly let IT block an attack before others fall for it. Treating staff as part of the defence encourages designs that support them rather than designs that work around them. He writes the needs beside each role.

8.3 Containing mistakes

Lucas designs so that one mistake does not become a disaster. A receptionist who enters a password on a fake page is protected by the security key. A manager who opens malware is limited by reduced rights and recovered by tested backups. A payment change request is held for callback verification. He presents a one-page diagram showing each mistake and the layer that contains it. This makes the architecture understandable to managers who are not technical. Managers find the diagram easy to follow.

Worked example

Lucas maps Brightwell's layers, adds human roles including reporting as detection and shows which layer contains each mistake.

Synthetic case. The architecture is synthetic; Saltzer and Schroeder (1975) is real.

Errors and limits

Untested layers give false confidence. Diagrams simplify.

Exercises

• EX022 — Backup finding. What problem did Lucas find with backups?
  Show marking criteria

  Rubric: 3 = they had never been tested;; 2 = untested;; 1 = vague;; 0 = none.
• EX023 — Reporting layer. Which layer does staff reporting provide?
  Show marking criteria

  Rubric: 3 = detection, letting IT block attacks early;; 2 = detection, without explanation;; 1 = prevention;; 0 = none.
• EX024 — Payment containment. What contains a fake payment change?
  Show marking criteria

  Rubric: 3 = a hold with callback verification;; 2 = callback;; 1 = vague;; 0 = none.

Synthesis

Layered architecture includes people and contains individual mistakes.

Continue studying — chapter 08 of 30

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →