Chapter 8 — Security architecture basics | Technologist Authorized offensive security and red team

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 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Trust boundaries"]
  N2["8.2 Defence in depth as layers with purposes"]
  N3["8.3 Where evidence lives"]
  N4["8.4 Architecture and scope"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Trust boundaries"]
  N2["8.2 Defence in depth as layers with purposes"]
  N3["8.3 Where evidence lives"]
  N4["8.4 Architecture and scope"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 Trust boundaries]
    |
    v
[8.2 Defence in depth as layers with purposes]
    |
    v
[8.3 Where evidence lives]
    |
    v
[8.4 Architecture and scope]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) draw a trust-boundary diagram for a small service; (2) explain defence in depth without treating it as a slogan; (3) place network, identity and application controls on that diagram; (4) identify where assessment evidence should be collected.

8.1 Trust boundaries

A trust boundary is a place where assumptions change: from internet to DMZ, from DMZ to internal network, from application to database, from staff device to VPN. Crossing a boundary should require a control — authentication, encryption, a gateway, a filter. Diagrams that omit boundaries hide the places where findings matter most.

Priya's diagram shows internet, DMZ, portal and directory as separate changes of assumption, each with its own control. Fare-payment sits behind another gateway and is a different trust domain, so it never inherits portal permissions because it appears nearby on a slide. Scope follows these boundaries rather than a flat list of addresses that happen to respond.

8.2 Defence in depth as layers with purposes

Depth means independent layers that fail differently. A VPN, an application login and a database permission are three layers. If they all depend on the same password store, they are one layer wearing three hats. An assessor looks for shared single points of failure as carefully as for missing layers.

A purple replay in ENG-712 showed the VPN and the portal failing together in the same directory outage mode. If all three layers collapse when the directory is down, the depth is only apparent. The recommendations therefore include independent session controls rather than another layer that depends on the same password store.

8.3 Where evidence lives

Network evidence lives in gateway logs and packet captures when authorized. Identity evidence lives in authentication logs. Application evidence lives in access logs and configuration exports. Knowing where to ask saves interactive access that nobody needs.

For ENG-712 the evidence plan names the gateway logs, directory authentication logs and portal access logs before the window opens, along with who will export each one. Packet captures need their own explicit line in the ROE, because they can collect far more personal data than a finding requires. Priya does not start captures on shared links on her own initiative, even when a log seems incomplete.

8.4 Architecture and scope

Scope should follow architecture. If the fare-payment segment sits behind a different gateway with different owners, it is a different trust domain and usually a different engagement. Mixing domains in one report confuses remediation.

Because fare-payment is a separate trust domain, ENG-712's exclusions name 192.0.2.64/27 and fare.trt.example. The exclusion paragraph is read aloud at kickoff and initialled by the architecture owners, and any disagreement about where the boundary lies is resolved in writing before tools run. An exclusion paragraph that nobody has initialled is treated as unread.

Worked example

Priya sketches TRT's staff portal: internet → reverse proxy → application servers → database; a parallel path for staff VPN → management jump host → same application tier. She marks the proxy and the jump host as trust-boundary controls. The fare-payment segment is drawn on a separate page with a note "out of scope". Northpoint's testers use the sketch to plan which logs they will request.

Synthetic case. The architecture sketch and its components are invented.

Errors and limits

Pretty diagrams that invent systems the organisation does not have waste time. Depth is not "more tools"; it is independent failure modes.

Exercises

EX022 — Boundary mark. On Priya's sketch, name two trust boundaries and one control at each.
Show marking criteria
Rubric: 3 = two distinct boundaries with matching controls (e.g. internet→proxy TLS/auth; VPN→jump host MFA); 2 = one complete; 1 = vague; 0 = none.
EX023 — Shared failure. The VPN, portal and database all accept the same Active Directory password with no MFA. Why is that not three layers?
Show marking criteria
Rubric: 3 = one credential store/one secret; compromise of that secret defeats all three; 2 = shared password noted; 1 = still three layers; 0 = none.
EX024 — Evidence place. Where would Priya look first for evidence that a staff VPN login occurred at 02:00?
Show marking criteria
Rubric: 3 = VPN/authentication logs (identity evidence); 2 = vague logs; 1 = database; 0 = none.

Synthesis

Draw the boundaries, check that layers fail independently, and collect evidence from the place the control actually lives.

Continue studying — chapter 08 of 30

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →