Chapter 16 — Security architecture
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Campus architecture"]
N2["16.2 Trust boundaries"]
N3["16.3 Cloud-first services"]
N4["16.4 Monitoring placement"]
N5["16.5 Research network"]
N6["16.6 Defence in depth"]
N7["16.7 Mapping to frameworks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Campus architecture"]
N2["16.2 Trust boundaries"]
N3["16.3 Cloud-first services"]
N4["16.4 Monitoring placement"]
N5["16.5 Research network"]
N6["16.6 Defence in depth"]
N7["16.7 Mapping to frameworks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Campus architecture]
|
v
[16.2 Trust boundaries]
|
v
[16.3 Cloud-first services]
|
v
[16.4 Monitoring placement]
|
v
[16.5 Research network]
|
v
[16.6 Defence in depth]
|
v
[16.7 Mapping to frameworks]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) describe how a university's networks and services are arranged for security; (2) identify trust boundaries and where monitoring belongs; (3) evaluate architecture against campus threats; (4) propose improvements with reasons.
16.1 Campus architecture
Riverton runs a student Wi-Fi network, a staff network, a research network, data-centre servers and cloud services for mail and identity. Each has different users and risks.
Each zone suits different controls. Student Wi-Fi serves thousands of personal devices the university does not manage, so it is isolated from internal systems. Research networks host specialised servers run by academic groups, often outside central IT. Cloud mail and identity serve everyone and hold the most valuable logs, which is why the phishing case was investigated mainly through them.
16.2 Trust boundaries
Boundaries separate zones: student Wi-Fi should not reach administrative servers; research servers should be reachable only by their groups. Firewalls enforce boundaries and log crossings.
Firewall logs at these boundaries help the SOC see attempts to cross them. If a device on student Wi-Fi tried to connect to an administrative server, the log would show a blocked connection from that address. A successful crossing between zones that should not talk is a strong signal, since it means either a misconfiguration or an attacker who has found a way through.
16.3 Cloud-first services
Mail and identity live in the cloud, so the most important logs come from cloud providers rather than campus networks. The SOC's architecture must collect cloud logs reliably.
For the phishing campaign, almost every key event, including the sign-ins, the forward rule and the deletion rule, happened in cloud services rather than on campus. If those cloud logs had not been collected, the SOC would have seen only DNS lookups and reports. Lucas checks weekly that cloud log feeds are arriving, since a silent failure would leave the SOC blind.
16.4 Monitoring placement
The SOC monitors identity sign-ins (all users), mail events, firewall logs at zone boundaries and endpoint logs from managed devices. Student devices are visible only through services.
This placement means the SOC sees every sign-in and mailbox change wherever it happens, and crossings between campus zones, but not activity inside a student's laptop. In the phishing case, that was enough, because the attack ran entirely through cloud services. A malware infection on a student's own device would be visible only through its effects on university accounts.
16.5 Research network
Research servers are diverse and loosely managed. A boundary that limits inbound access to university addresses and requires SSH keys reduces exposure.
The physics GPU server shows the risk: it accepted SSH from the whole internet with passwords enabled for some accounts, and it forwarded no logs until recently. Applying both controls would have removed most of the automated guessing in its logs. Neither control needs new hardware. The worked example below describes how the restriction was agreed with the research group.
16.6 Defence in depth
Several layers — mail filtering, MFA, legacy protocol blocking, monitoring of mailbox rules — mean one failure does not lead to widespread compromise.
In the phishing campaign, mail filtering missed the message and only marked it with a banner, but the next layers helped: MFA would have stopped the stolen passwords had the students enrolled, and the z-score screening flagged s2047's burst of sending. Where layers were missing, compromise followed, and s3310's quieter compromise went unflagged for hours. The case decision added MFA and legacy blocking, and later chapters add an alert for suspicious mailbox rules.
16.7 Mapping to frameworks
Lucas maps controls to NIST CSF 2.0 functions to show coverage across Protect, Detect and Respond.
His table lists each control with its function: mail filtering and MFA under Protect, the z-score screening and rule alerts under Detect, password resets and rule removal under Respond. The table showed few controls under Recover, which led to a question about restoring deleted mail that appears again in the case's later chapters. A map with an empty column is useful precisely because it points to work nobody had planned.
Administrative systems
Finance, HR and student records sit in a restricted zone reachable only from staff networks through a gateway that requires MFA. Logs from the gateway show every session, giving the SOC a narrow, high-value view of access to the most sensitive data.
Worked example
Lucas's architecture review notes that research servers accept SSH from anywhere on the internet. He proposes restricting inbound SSH to the university VPN and campus networks. The physics group agrees after a trial week shows their remote collaborators can use the VPN.
Synthetic case. Networks and reviews are invented.
Errors and limits
Universities value openness; controls must fit research and teaching needs.
Exercises
- EX046 — Cloud logs. Why are cloud provider logs central to Riverton's SOC? Rubric: 3 = mail and identity are in the cloud; 2 = partial; 1 = vague; 0 = none.
- EX047 — Research boundary. What change was proposed for research servers? Rubric: 3 = restrict inbound SSH to VPN and campus; SSH keys; 2 = partial; 1 = vague; 0 = none.
- EX048 — Defence in depth. Give three layers protecting campus mail accounts. Rubric: 3 = filtering, MFA, legacy blocking, rule monitoring (three); 2 = two; 1 = one; 0 = none.
Synthesis
Architecture defines zones and boundaries; monitoring belongs where trust changes and where important services live.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →