Chapter 2 — Computing systems
Lesson map
Lesson 02 published. Map, example, EX004.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Layers at Fernway"]
N2["2.2 Responsibility by layer"]
N3["2.3 A first inventory"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX004"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Layers at Fernway"]
N2["2.2 Responsibility by layer"]
N3["2.3 A first inventory"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX004"]
[Learning outcomes]
|
v
[2.1 Layers at Fernway]
|
v
[2.2 Responsibility by layer]
|
v
[2.3 A first inventory]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX004]
Learning outcomes
You will (1) describe the hardware, software and service layers of a retail organisation; (2) identify where security responsibilities sit in each layer; (3) build a first asset inventory.
2.1 Layers at Fernway
Lucas visits Fernway with Dr Bellini's class. Hannah shows them the layers: hardware such as tills, warehouse scanners, laptops and a small server room; software such as the shop platform, the stock database and email; and services bought from outside, including card payments, cloud hosting and a delivery partner's tracking system. Each layer depends on the one below. A secure shop platform running on an unpatched server inherits the server's weaknesses. Lucas learns that architecture starts by seeing the whole stack, not only the part a project team happens to own.
2.2 Responsibility by layer
For bought services, responsibility is shared. The cloud host secures its data centres and hypervisors; Fernway secures its virtual machines, accounts and data. The card payment provider handles card numbers; Fernway must protect its integration keys and the checkout page. Lucas draws a responsibility table with three columns: Fernway, supplier and shared. He finds that nobody at Fernway was listed as responsible for reviewing the delivery partner's access to customer addresses, which had been granted years ago. Unowned responsibilities are among the most common architecture weaknesses in small organisations.
2.3 A first inventory
Hannah asks Lucas to start an asset inventory. Each row lists the asset, its owner, its location or provider, the data it holds and its criticality. He finds more than he expected: an old laptop used for label printing still had stored customer data, and a test copy of the shop database sat on a cloud storage bucket. Inventories are the foundation of architecture work, because nobody can protect what they do not know exists. He records the two surprises as findings for Hannah and notes that the inventory must be updated whenever systems change.
Worked example
Lucas maps Fernway's hardware, software and service layers, draws a responsibility table finding an unowned delivery-partner access review, and starts an inventory that reveals two forgotten data copies.
Synthetic case. Fernway's systems and findings are synthetic.
Errors and limits
Inventories are never complete on the first pass. Shared-responsibility boundaries differ between providers and contracts.
Exercises
- EX004 — Inherited weakness. Why can a secure shop platform still be vulnerable? Rubric: 3 = it inherits weaknesses of an unpatched server below it;; 2 = lower layer;; 1 = it cannot;; 0 = none.
- EX005 — Unowned item. Which responsibility had no owner at Fernway? Rubric: 3 = reviewing the delivery partner's access to customer addresses;; 2 = named;; 1 = vague;; 0 = none.
- EX006 — Inventory surprises. What two surprises did the inventory reveal? Rubric: 3 = old label-printing laptop with customer data; test database copy in cloud bucket;; 2 = both;; 1 = one;; 0 = none.
Synthesis
Seeing all layers, assigning every responsibility and inventorying assets are the first steps of security architecture.
Continue studying — chapter 02 of 40
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →