## Chapter 1 — Security architecture and engineering: foundations and decisions ### Learning outcomes You will (1) explain security architecture in plain terms; (2) apply five design principles to a small credit union; (3) record one decision properly. ### 1.1 What architecture means Leah Brennan coordinates operations at the fictional Saltmarsh Community Credit Union, which serves six thousand members from two branches and a website. She joins a one-month rapid course at the fictional Northgate Learning Centre, taught by Felix Ortega. Felix defines security architecture as the overall arrangement of protections across people, processes and technology, designed so they work together. It answers practical questions: who may reach which systems, where identities are checked, where member data lives and how services recover. It is a plan for the whole, not a list of products. ### 1.2 Why it matters to a small organisation Leah asks whether a small credit union needs architecture at all. Felix explains that small organisations make security decisions constantly, such as buying a new loan system or letting a supplier connect remotely. Without an overall plan, each decision is made alone and they often contradict one another. A short written architecture lets Leah check each new proposal against agreed principles. Anderson (2020) notes that many security failures come from systems that were each reasonable alone but unsafe in combination. Leah agrees to draft one for Saltmarsh. ### 1.3 Five principles Felix teaches five principles from Saltzer and Schroeder (1975), in plain terms. Least privilege: give each person only the access their job needs. Fail-safe defaults: start from no access and grant what is needed. Complete mediation: check permission on every request, not only at sign-in. Separation of privilege: require two people or two conditions for the most sensitive actions. Psychological acceptability: make controls easy enough that people use them properly. Leah notes that these principles are decades old yet still describe most of the problems she sees at work. ### 1.4 Applying them at Saltmarsh Leah applies the principles. Tellers can view member accounts but not change interest rates, which is least privilege. New staff accounts start empty and receive roles on approval, which is fail-safe defaults. Large transfers need a second staff member to approve, which is separation of privilege. She finds a gap: the shared branch email account is used by all tellers, so nobody can tell who sent what. She also finds the online banking sign-in already uses an app-based second factor, which members find easy, an example of acceptability. ### 1.5 Recording a decision Leah's first architecture decision is whether to replace the shared branch email account with individual mailboxes and a shared inbox that each person accesses with their own account. She writes a short decision record: context, options, the choice, reasons, consequences and when to revisit. The choice is individual accounts with shared inbox access. The reason is accountability, since member queries must be traceable to the person who answered. Felix stresses that writing decisions down lets others understand and challenge them later, even after the author has moved on. ### Worked example Leah defines architecture in plain terms, applies five principles to Saltmarsh, finds a shared email gap and records a decision to replace it. > **Synthetic case.** Saltmarsh, Northgate and all people are synthetic; Anderson (2020) and Saltzer and Schroeder (1975) are real. ### Errors and limits Principles can conflict, such as acceptability against separation of privilege. Short courses give foundations, not mastery. ### Exercises - **EX001 — Plain definition.** How does Felix define security architecture? *Rubric:* 3 = the overall arrangement of protections across people, process and technology;; 2 = overall plan;; 1 = product list;; 0 = none. - **EX002 — Small organisations.** Why does a small credit union need architecture? *Rubric:* 3 = decisions made alone often contradict each other;; 2 = consistency;; 1 = vague;; 0 = none. - **EX003 — Least privilege at Saltmarsh.** Give Saltmarsh's example of least privilege. *Rubric:* 3 = tellers view accounts but cannot change interest rates;; 2 = tellers;; 1 = vague;; 0 = none. - **EX004 — Fail-safe example.** Which practice shows fail-safe defaults? *Rubric:* 3 = new staff accounts start empty and get roles on approval;; 2 = empty start;; 1 = vague;; 0 = none. - **EX005 — Two-person rule.** Where does Saltmarsh use separation of privilege? *Rubric:* 3 = large transfers need a second approver;; 2 = transfers;; 1 = vague;; 0 = none. - **EX006 — Shared mailbox gap.** Why is the shared branch email account a gap? *Rubric:* 3 = nobody can tell who sent what;; 2 = accountability;; 1 = vague;; 0 = none. - **EX007 — Acceptability example.** Which control shows psychological acceptability? *Rubric:* 3 = the app-based second factor members find easy;; 2 = app factor;; 1 = vague;; 0 = none. - **EX008 — Decision record parts.** List the parts of Leah's decision record. *Rubric:* 3 = context, options, choice, reasons, consequences, revisit date;; 2 = four;; 1 = vague;; 0 = none. - **EX009 — Chosen option.** Which option did the email decision select? *Rubric:* 3 = individual accounts with shared inbox access;; 2 = individual;; 1 = keep shared;; 0 = none. - **EX010 — Reason for choice.** Why did accountability drive the email choice? *Rubric:* 3 = member queries must be traceable to who answered;; 2 = traceable;; 1 = cost;; 0 = none. - **EX011 — Combined failures.** According to Anderson, where do many failures come from? *Rubric:* 3 = systems reasonable alone but unsafe together;; 2 = combination;; 1 = single bugs;; 0 = none. - **EX012 — Principle conflict.** Name two principles that can conflict. *Rubric:* 3 = acceptability and separation of privilege;; 2 = pair;; 1 = vague;; 0 = none. - **EX013 — Value of writing.** Why write decisions down, according to Felix? *Rubric:* 3 = so others can understand and challenge them later;; 2 = challenge;; 1 = vague;; 0 = none. ### Synthesis Security architecture is a written plan grounded in a few durable principles and recorded decisions. ### Continue studying — lesson 01 (chapter 01 of 20) [← Course home](../../README.md) · [Course chapter index](../SUBJECTS.md) · [Chapter 02 →](#ch-02) Continue to the next authored lesson. ## Worked answers **EX001.** The overall arrangement of protections across people, processes and technology, designed to work together. **EX002.** Because decisions made one at a time without a plan often contradict one another. **EX003.** Tellers can view member accounts but cannot change interest rates. **EX004.** New staff accounts start with no access and receive roles only on approval. **EX005.** Large transfers need approval from a second staff member. **EX006.** Because nobody can tell which teller sent which message. **EX007.** The app-based second factor for online banking, which members find easy. **EX008.** Context, options, the choice, reasons, consequences and when to revisit. **EX009.** Individual accounts with access to a shared inbox. **EX010.** Because member queries must be traceable to the person who answered them. **EX011.** From systems that are each reasonable alone but unsafe in combination. **EX012.** Psychological acceptability and separation of privilege, since extra approvals add friction. **EX013.** So others can understand and challenge the reasoning later, even after the author leaves.