Chapter 16 — Security architecture | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["16.1 Trust boundaries and control points"]
  N2["16.2 Separation and least privilege"]
  N3["16.3 Logging as an architectural property"]
  N4["16.4 Resilience"]
  N5["16.5 Threat models"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["16.1 Trust boundaries and control points"]
  N2["16.2 Separation and least privilege"]
  N3["16.3 Logging as an architectural property"]
  N4["16.4 Resilience"]
  N5["16.5 Threat models"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX046"]

[Learning outcomes and connection]
    |
    v
[16.1 Trust boundaries and control points]
    |
    v
[16.2 Separation and least privilege]
    |
    v
[16.3 Logging as an architectural property]
    |
    v
[16.4 Resilience]
    |
    v
[16.5 Threat models]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes and connection

You will be able to (1) identify trust boundaries and control points in an architecture; (2) evaluate an architecture for response visibility; (3) estimate blast radius under a stated threat model; and (4) compare designs for resilience. Chapters 2 and 6 modelled systems and access; this chapter asks how design choices make incidents easier or harder to see, contain and recover from. Chapter 22 builds provenance maps on these designs.

16.1 Trust boundaries and control points

A trust boundary is where data or control passes between components with different levels of trust: internet to proxy, user device to application, application to database, one tenant to another. Boundaries are natural control points: places to authenticate, authorize, filter, log and — during an incident — block. An architecture with few, well-defined boundaries is easier to defend and to investigate than one where everything talks to everything.

In Design B for the appointment service, the proxy sits on the boundary between staff devices and the API, so it can block a session, rate-limit bulk exports and stamp each request with an identifier. Design A has no comparable point between the clinic network and the application.

16.2 Separation and least privilege

Separation limits what a compromise can reach: separate administrative accounts from daily accounts, production from test, one service's credentials from another's. Least privilege grants each principal only what it needs. Both reduce blast radius — the set of assets affected if one component is compromised — which you can compute with the reachability method of Chapter 6.

In Design B, the API's search function uses a read-only database role, so a stolen staff credential used through search cannot alter appointments; in Design A, the single full-rights account means any route into the application can change everything. Separate administrator accounts in B add a second barrier: phishing a daily account does not hand over administration.

16.3 Logging as an architectural property

Visibility is designed, not added. Ask at each boundary: what is logged, with which identifiers, where are logs stored, who can delete them, and how long are they kept? Logs stored on the same host as the application share its fate; logs forwarded to a separate, append-only store survive host compromise. Consistent identifiers (request IDs passed from proxy to API to database) make cross-component timelines possible.

Design A keeps logs on the application's own disk, so an attacker who gains control of the host can edit them; Design B forwards them to a separate write-once store.

16.4 Resilience

Resilience is the ability to continue essential functions during disruption and recover afterwards. Architectural features include redundancy across failure domains, graceful degradation (read-only mode, paper fallback), isolated and tested backups, and the ability to cut a component off without stopping everything. NIST SP 800-184 discusses recovery planning; NIST SP 800-160 Vol. 2 addresses cyber-resiliency engineering at greater depth.

Design B's read-only mode is an example of graceful degradation: during an investigation of altered appointments, staff can still look up bookings while writes are paused. Design A offers only running or stopped. Resilience features need rehearsal, because a read-only switch that nobody has used may fail when needed.

16.5 Threat models

A threat model states who might attack, with what capabilities, against which assets. Comparing architectures is meaningless without one: a design that resists a remote attacker may be weak against a malicious administrator.

Write the threat model in one or two sentences before comparing designs. The appointment-service comparison assumes a remote attacker holding one stolen staff credential; under that model Design B's per-function roles and proxy limits matter most. Under a different model, such as a malicious database administrator, the comparison shifts, which is the point of the exercise on changing the threat model. A design is only better against someone in particular, so name who.

16.6 Worked example (synthetic): two appointment-service architectures

Fictional designs for Harbourline's appointment service. Threat model: a remote attacker steals one staff member's credentials (phishing) and tries to read or alter appointments at scale.

Design A ("flat"): staff connect from the clinic network directly to a monolithic application that uses one database account with full rights; application logs are written to local disk; administrators use their daily accounts.

Design B ("layered"): staff sign in through the IdP with MFA; requests pass through a proxy that adds a request ID; the API uses per-function database roles (read-only for search, limited write for booking); logs (proxy, API, database audit) are forwarded to a separate store with write-once retention; administrators use separate admin accounts from managed workstations; a read-only mode can be enabled.

Comparison: - Visibility: A has local logs that the attacker might alter and no request correlation; B links each request across layers and keeps logs off-host. - Blast radius: in A, any application flaw exposes full database rights; in B, the stolen staff credential reaches only that user's functions, and bulk export can be rate-limited at the proxy. - Containment options: A has essentially two (disable user, take application down); B adds blocking at the proxy, revoking IdP sessions, and switching to read-only mode while investigating. - Cost: B is more complex to operate; complexity is itself a risk if no one maintains the log pipeline.

16.7 Common errors and limits

Judging designs without a threat model.
Storing logs where the attacker can reach them.
Assuming segmentation exists because a diagram shows it; verify with configuration evidence.
Overlooking operational cost: an unmaintained control gives false assurance.
Copying a design from another organization without checking that its threat model matches yours.
Treating a read-only mode or proxy block as available during an incident when nobody has ever tested it.
Measuring blast radius from documented permissions only, missing the indirect paths that reachability analysis reveals.

Exercises — chapter 16

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.

EX046 — Mark the boundaries. Steps: draw Design B with its trust boundaries and name one control and one log at each. Rubric: 3 = at least four boundaries with appropriate controls and logs; 2 = three; 1 = vague; 0 = none.

EX047 — Change the threat model. Steps: compare A and B against a malicious database administrator. Rubric: 3 = recognizes that B's gains shrink, proposes separation of duties, audit logs the DBA cannot alter, dual control for bulk changes; 2 = partial; 1 = repeats remote-attacker analysis; 0 = none.

EX048 — Visibility gap. Inputs: Design B forwards logs every 15 minutes in batches. Steps: explain the risk and propose a mitigation. Rubric: 3 = up to 15 minutes of logs at risk on host compromise and delayed detection; propose streaming or local tamper-evident buffering, and monitor for forwarding gaps; 2 = risk only; 1 = misses it; 0 = none.

Chapter synthesis

Architecture decides what you can see, where you can act and how far a compromise spreads. Evaluate designs against an explicit threat model, keep logs beyond the attacker's reach and count the operational cost of every control.