◇ OpenCyber Academy
Engineering · Chapter 27 · English

Chapter 27 — Security architecture and engineering: control design

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 27 — Security architecture and engineering: control design

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Designing to requirements"]
  N2["27.2 Defence in depth with purpose"]
  N3["27.3 Precise specifications"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Designing to requirements"]
  N2["27.2 Defence in depth with purpose"]
  N3["27.3 Precise specifications"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Designing to requirements]
    |
    v
[27.2 Defence in depth with purpose]
    |
    v
[27.3 Precise specifications]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) design controls that meet specific requirements; (2) layer preventive, detective and corrective controls; (3) specify controls precisely enough to implement and test.

27.1 Designing to requirements

Sofia designs controls for the requirement that tariff tables must be authentic before use. The preventive control is a digital signature: tariff tables are signed in the tariff office with a key held in a hardware security module, and every consumer verifies the signature with a pinned public key before loading. The detective control logs every load with the table's version and hash, and alerts if a version appears that the tariff office did not publish. The corrective control lets operations roll back to the last verified table within minutes. Each control links to the requirement and abuse case it serves.

27.2 Defence in depth with purpose

Layering controls is useful only if layers fail independently. Sofia checks her tariff-table design: if the signing key were stolen, signatures would verify, so the detective control compares loaded versions with an independent publication list kept by finance. If verification code had a bug, the detective control would still notice unexpected versions. If both failed, rollback limits damage. She notes that two controls depending on the same key or the same database do not provide real depth. Defence in depth means asking, for each layer, what happens if the previous one fails.

27.3 Precise specifications

A control specification must say enough to implement and test. Sofia writes: the signature algorithm is Ed25519 as specified in RFC 8032; the public key is pinned in configuration and rotated only through change control; verification failure stops loading and raises a high-priority alert; logs include table identifier, version, hash and verifying component. She attaches test cases: a correctly signed table loads; a modified table is rejected; a table signed with an unknown key is rejected. Precise specifications prevent each implementer from making different assumptions that leave gaps between components.

Worked example

Sofia designs signed tariff tables with an HSM-held key, independent version checks and rollback, tests layer independence and writes a specification with three test cases.

Synthetic case. The tariff design is synthetic; RFC 8032 is real.

Errors and limits

Pinned keys complicate emergency rotation. Detective controls depend on someone responding to alerts.

Exercises

Synthesis

Good control design ties each control to a requirement, layers controls that fail independently and specifies them precisely.

Continue studying — chapter 27 of 50

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →