Chapter 18 — Security architecture

Chapter 18 — Security architecture

Lesson map

Lesson 18 published. Map, example, EX052.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 Design principles"]
  N2["18.2 Zones and boundaries"]
  N3["18.3 Evaluating options"]
  N4["18.4 Open design"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX052"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["18.1 Design principles"]
  N2["18.2 Zones and boundaries"]
  N3["18.3 Evaluating options"]
  N4["18.4 Open design"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]

[Learning outcomes]
    |
    v
[18.1 Design principles]
    |
    v
[18.2 Zones and boundaries]
    |
    v
[18.3 Evaluating options]
    |
    v
[18.4 Open design]
    |
    v
[Worked example] --> [Exercise EX052]

Learning outcomes

You will (1) apply classic design principles; (2) design zones and trust boundaries; (3) evaluate architectures against principles.

18.1 Design principles

Lindiwe reads Saltzer and Schroeder's 1975 paper on protecting information in computer systems. It lists principles that still guide architecture: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism and psychological acceptability. She maps them to Saltmarsh. Fail-safe defaults mean new staff get no access until approved; complete mediation means every request is checked, not just the first. She notes the principles are old but widely cited. Prof. Hale asks her to give one Saltmarsh example for every principle.

18.2 Zones and boundaries

Lindiwe designs zones for Saltmarsh: an internet-facing zone for the website and driver app interface, an internal zone for staff, a restricted zone for payroll and a management zone for administrators. Traffic between zones passes through controls that enforce rules. She marks trust boundaries on her earlier diagram. Prof. Hale asks her which principle each boundary supports; she identifies least privilege and complete mediation as the main ones. She lists the permitted traffic between each pair of zones in a table, and the network team uses it as the starting rule set.

18.3 Evaluating options

Two architecture options exist for the driver app interface: direct access to the dispatch database or an intermediate service exposing only needed functions. Lindiwe evaluates both against the principles. The intermediate service follows least privilege and economy of mechanism better, because the database is never exposed. It adds development work. She records the evaluation in a decision record, and the developers choose the intermediate service. The decision record lists both options, the principles each supports and the estimated extra development time. Prof. Hale praises the record for making the reasoning visible.

18.4 Open design

Saltzer and Schroeder argued that security should not depend on attackers not knowing the design. Lindiwe applies this to Saltmarsh's custom file transfer tool, whose security relied on an undocumented port. She recommends authentication and encryption that remain secure even if the design is published. Prof. Hale notes that open design also enables review, since outside experts can examine a published design and find weaknesses before attackers do. The tool is replaced with a standard encrypted transfer service within the year. Its configuration is documented openly for the operations team.

Worked example

Lindiwe maps Saltzer and Schroeder's principles to Saltmarsh, designs four zones, chooses an intermediate service for least privilege and replaces reliance on secrecy of design.

Synthetic case. Architectures are synthetic.

Errors and limits

Relying on an undocumented port is obscurity, not protection.

Exercises

• EX052 — Fail-safe defaults. What does fail-safe defaults mean for new staff? Rubric: 3 = no access until approved;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX053 — Chosen option. Which option do developers choose? Rubric: 3 = the intermediate service;; 2 = partly correct;; 1 = direct;; 0 = none.
• EX054 — Open design. What did the transfer tool rely on? Rubric: 3 = an undocumented port;; 2 = partly correct;; 1 = other;; 0 = none.

Continue studying — lesson 18 (chapter 18 of 50)

← Chapter 17 · Course chapter index · Chapter 19 →

Continue to the next authored lesson.