Chapter 16 — Security architecture
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 A simple architecture"]
N2["16.2 Layers"]
N3["16.3 Documenting choices"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 A simple architecture"]
N2["16.2 Layers"]
N3["16.3 Documenting choices"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 A simple architecture]
|
v
[16.2 Layers]
|
v
[16.3 Documenting choices]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) describe a simple security architecture for a small organisation; (2) apply layered defence; (3) document design choices.
16.1 A simple architecture
Sofia sketches Elmfield's target architecture. Identity is central: all staff sign in once with multi-factor authentication to reach cloud email, the housing system and files. Devices are managed and encrypted. Sensitive data live in a few well-controlled places. Backups are kept separately and tested. The office network is no longer trusted by default. She learns that small organisations can achieve strong security through a few well-chosen design decisions rather than many complex tools. Each element answers a gap she found earlier, such as the unencrypted laptops and the exposed remote desktop service.
16.2 Layers
Sofia applies layered defence to ransomware. Email filtering blocks many malicious messages. Multi-factor authentication limits stolen passwords. Device controls block unknown programs. Limited administrator rights reduce spread. Offline backups allow recovery. No single layer is perfect, but together they reduce the chance that one failure causes disaster. She notes that layers sharing a weakness, such as one administrator account controlling all of them, would weaken this protection considerably. Dr. Haddad asks which layer failed in a real ransomware case the class has read about, so students see that the offline backup was often the last one standing.
16.3 Documenting choices
Sofia writes short decision notes for each major choice: why cloud identity was chosen, why the file server will move to a cloud service and why backups remain offline. Each note records the alternatives and accepted risks. She learns that documented decisions help future staff understand the architecture and help auditors see that risk was considered. Elmfield's director appreciates the notes because they explain technical decisions in language the board can follow. The note on keeping backups offline, for example, records that a cloud-only backup was considered and rejected because ransomware could reach it.
Worked example
Sofia sketches an identity-centred architecture, layers ransomware defences and documents major decisions.
Synthetic case. The architecture is synthetic.
Errors and limits
Layers can share weaknesses. Cloud moves bring supplier risk.
Exercises
- EX046 — Central element. What is central to Elmfield's target architecture? Rubric: 3 = identity with multi-factor authentication;; 2 = identity;; 1 = network;; 0 = none.
- EX047 — Shared weakness. What could weaken layered defence? Rubric: 3 = one administrator account controlling all layers;; 2 = shared admin;; 1 = vague;; 0 = none.
- EX048 — Decision notes. What do Sofia's decision notes record? Rubric: 3 = alternatives and accepted risks;; 2 = alternatives;; 1 = vague;; 0 = none.
Synthesis
Small organisations gain strong security from a few well-documented architecture decisions.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →