Chapter 8 — Security architecture basics

Chapter 8 — Security architecture basics

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["8.1 Trust boundaries and segmentation"]
  N2["8.2 Architecture for response"]
  N3["8.4 Small changes, large effect"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["8.1 Trust boundaries and segmentation"]
  N2["8.2 Architecture for response"]
  N3["8.4 Small changes, large effect"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes and connection]
    |
    v
[8.1 Trust boundaries and segmentation]
    |
    v
[8.2 Architecture for response]
    |
    v
[8.4 Small changes, large effect]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes and connection

You will be able to (1) read an architecture diagram for trust boundaries, segmentation and control points; (2) evaluate whether the architecture supports detection, containment and recovery; and (3) propose small architectural changes that make response faster. Chapters 1–7 described parts; this chapter looks at how they are arranged.

8.1 Trust boundaries and segmentation

A trust boundary is where data or control passes between zones with different trust: internet to edge, edge to application, application to database, corporate network to production, supplier to Fernmoor. Segmentation limits which zones can talk to which. Good segmentation turns a compromise of one zone into a contained case; flat networks turn it into a city-wide outage. NIST SP 800-207 describes zero trust architecture, which moves from network location to per-request verification of identity and device; few organizations are there yet, but its principles guide incremental change.

8.2 Architecture for response

Ask four questions of any design. Visibility: do logs at each boundary reach central collection? Containment: can one zone, host or identity be isolated without stopping unrelated services? Recovery: are backups separated from production administration (different credentials, immutability)? Administration: is privileged access through controlled paths (jump hosts, privileged access management) rather than from any workstation? NIST SP 800-160 Vol. 2 frames these as cyber-resiliency techniques such as segmentation, redundancy and non-persistence. Fernmoor's water-billing review used exactly these four questions, and each produced a finding with an owner.

8.3 Worked example (synthetic): the water-billing design review

Fictional. Fernmoor's water-billing system has a web front end, an application server, a database and a nightly file transfer to a payment supplier. Review findings:

Each change was entered in the service-management system (Chapter 21) with the response rationale, so that the change board saw why it mattered.

8.4 Small changes, large effect

Technologists rarely redesign a system; they make it respondable. Typical high-value changes: forward one missing log source; create a quarantine segment and test moving a VM into it; give backups their own credentials; put administration behind a jump host. Each change should have an acceptance test ("from the quarantine segment, only the evidence share is reachable"). The water-billing review produced changes of this size: a separate billing VLAN, a dedicated backup credential with an immutable copy, and a jump host with MFA. Each was entered as an ordinary change with a response rationale, and none required rebuilding the system. Their acceptance tests become the evidence that the change worked.

8.5 Common errors and limits

• Drawing segments that exist on paper but not in firewall rules — verify with a connectivity test.
• Assuming cloud resources are segmented by default.
• Security changes without a rollback or owner.
• Ignoring supplier connections as trust boundaries.

The water-billing review met two of these directly. The billing VLAN had to be checked with a connectivity test, not just a diagram, and the nightly file transfer to the payment supplier was treated as a trust boundary whose logs had to be forwarded. Every proposed change had a named owner from the start, so none was left without someone to roll it back.

Exercises — chapter 8

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX022 — Boundary list. Steps: list five trust boundaries in the water-billing system. Rubric: 3 = internet–web, web–app, app–DB, admin–servers, Fernmoor–payment supplier; 2 = four; 1 = two; 0 = none.

EX023 — Acceptance test. Steps: write acceptance tests for the four proposed changes in the water-billing design review. Rubric: 3 = each test observable and pass/fail; 2 = three; 1 = vague; 0 = none.

EX024 — Prioritize. Steps: rank the four changes and justify by response impact and effort. Rubric: 3 = defensible ranking with both impact and effort (backup separation commonly first); 2 = impact only; 1 = no reasons; 0 = none.

Chapter synthesis

Read architecture for trust boundaries and ask four response questions: visibility, containment, recovery and administration. Propose small, testable changes with owners and acceptance tests that make each system respondable.

Continue studying — chapter 08 of 30

← Chapter 07 · Course chapter index · Chapter 09 →

Continue to the next authored lesson.