Chapter 18 — Security architecture and engineering: controls

Chapter 18 — Security architecture and engineering: controls

Lesson map

Lesson 18 published. Map, example, EX052.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 Controls from scenarios"]
  N2["18.2 Checking coverage"]
  N3["18.3 Evidence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX052"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["18.1 Controls from scenarios"]
  N2["18.2 Checking coverage"]
  N3["18.3 Evidence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]

[Learning outcomes]
    |
    v
[18.1 Controls from scenarios]
    |
    v
[18.2 Checking coverage]
    |
    v
[18.3 Evidence]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX052]

Learning outcomes

You will (1) map controls to risk scenarios; (2) use a control catalogue to check coverage; (3) record evidence for each control.

18.1 Controls from scenarios

Tomás lists the controls already chosen for Brightwater's risk scenarios: upload portal with multi-factor sign-in, manifest validation, offline backups, remote wipe, time-limited vendor access, USB restrictions on the conveyor workstation and monthly updates. He maps each to the scenarios it reduces. A control that reduces several scenarios, such as monthly updates, deserves extra attention because its failure would weaken many defences at once. The map also shows that no control yet addresses invoice fraud in finance. He adds invoice fraud to the list of gaps to close next.

18.2 Checking coverage

Tomás uses ISO/IEC 27002:2022 as a catalogue to look for gaps. Its controls on supplier relationships, information transfer and secure disposal prompt three additions: a supplier security clause for the conveyor vendor, a call-back rule for bank detail changes in finance, and wiping handhelds before return to the leasing company. The catalogue is used as a reminder list, not a checklist to implement in full. Tomás records why other catalogue controls are not needed at Brightwater's size. The reasons are kept in a short appendix for auditors and customers.

18.3 Evidence

For each control Tomás records what proves it works: a screenshot of the portal's multi-factor setting, a restore test log, a list of wiped handhelds, vendor session approvals and the update report. Evidence must be produced regularly, not once. He sets reminders for monthly and quarterly checks. Sam notes that the evidence list will also help when a large retail customer sends its supplier security questionnaire, which happens every year and previously took days of searching. Each item names who produces it and where it is stored.

Worked example

Tomás maps seven controls to scenarios, uses ISO/IEC 27002 to add three, and defines regular evidence for each control.

Synthetic case. Controls and evidence are synthetic; ISO/IEC 27002:2022 is real.

Errors and limits

Evidence can show configuration without proving effectiveness. Catalogues tempt over-implementation.

Exercises

• EX052 — Shared control. Why does monthly updating deserve extra attention? Rubric: 3 = its failure weakens defences against many scenarios;; 2 = many scenarios;; 1 = vague;; 0 = none.
• EX053 — Catalogue additions. Name two controls added from ISO/IEC 27002. Rubric: 3 = supplier clause, bank change call-back, handheld wiping;; 2 = one;; 1 = vague;; 0 = none.
• EX054 — Questionnaire benefit. How will the evidence list help with customers? Rubric: 3 = answering supplier security questionnaires quickly;; 2 = questionnaires;; 1 = vague;; 0 = none.

Synthesis

Controls mapped to scenarios, checked against a catalogue and backed by regular evidence form a coherent defence.

Continue studying — chapter 18 of 30

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