Chapter 22 — Security architecture and engineering: data and dependencies

Lesson map

Lesson 22 published. Map, example, EX064.

flowchart TD
  N0["Learning outcomes"]
  N1["22.1 Classifying data"]
  N2["22.2 Mapping dependencies"]
  N3["Lab — Counting functions affected by each dependency"]
  N4["22.3 Single points of failure"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX064"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["22.1 Classifying data"]
  N2["22.2 Mapping dependencies"]
  N3["Lab — Counting functions affected by each dependency"]
  N4["22.3 Single points of failure"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]

[Learning outcomes]
    |
    v
[22.1 Classifying data]
    |
    v
[22.2 Mapping dependencies]
    |
    v
[Lab — Counting functions affected by each dependency]
    |
    v
[22.3 Single points of failure]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX064]

Learning outcomes

You will (1) classify Fernway's data; (2) map dependencies on suppliers and services; (3) identify single points of failure.

22.1 Classifying data

Lucas proposes three data classes for Fernway: public, such as product descriptions; internal, such as stock levels and rotas; and confidential, such as member details, staff records and supplier contracts. Each class has handling rules for storage, sharing and disposal. He keeps the scheme small because staff must apply it without training manuals. He labels the main data stores with their class and finds that a shared drive folder named "misc" holds confidential staff records alongside public marketing images, which means anyone with marketing access can read payroll data.

22.2 Mapping dependencies

Lucas lists every external service Fernway depends on: hosting, payment, email, delivery, identity, accounting and the supplier price feed. For each he records the data shared, the contract owner, whether the supplier has security commitments, and what happens if the service fails. The lab below models dependencies as a graph and counts how many business functions each service supports. Identity and hosting each support every online function, so their failure would stop almost everything at once, while the price feed affects only pricing updates.

Lab — Counting functions affected by each dependency

# Count business functions depending on each service (synthetic map).
deps = {"online sales": ["hosting", "identity", "payment", "email"],
        "click-and-collect": ["hosting", "identity", "email"],
        "delivery tracking": ["hosting", "identity", "delivery"],
        "member accounts": ["hosting", "identity", "email"],
        "pricing updates": ["hosting", "identity", "price feed"],
        "month-end accounts": ["accounting"]}
count = {}
for f, svcs in deps.items():
    for s in svcs: count[s] = count.get(s, 0) + 1
for s, n in sorted(count.items(), key=lambda x: (-x[1], x[0])): print(f"{s:11} supports {n} function(s)")

Run with python3 lab_deps.py. Verified output:

hosting     supports 5 function(s)
identity    supports 5 function(s)
email       supports 3 function(s)
accounting  supports 1 function(s)
delivery    supports 1 function(s)
payment     supports 1 function(s)
price feed  supports 1 function(s)

22.3 Single points of failure

The dependency count shows where resilience matters most. Lucas recommends a documented manual fallback for identity, such as a sealed break-glass account, and confirmation that the hosting provider's plan includes recovery in a second region. For the payment provider he notes a contractual commitment instead of technical redundancy, since a second payment provider would cost more than the risk justifies. He explains that not every single point of failure must be removed; some are accepted knowingly with a recovery plan and an owner who monitors the supplier.

Worked example

Lucas defines three data classes, finds confidential records in a mixed folder, maps seven dependencies and ranks them by functions affected.

Synthetic case. Data, services and counts are synthetic.

Errors and limits

Dependency maps miss fourth parties, the suppliers of suppliers. Classifications drift without periodic review.

Exercises

• EX064 — Mixed folder. What was wrong with the misc folder?
  Show marking criteria

  Rubric: 3 = confidential staff records next to public images, readable by marketing;; 2 = mixed classes;; 1 = vague;; 0 = none.
• EX065 — Widest dependency. Which services supported the most functions in the lab?
  Show marking criteria

  Rubric: 3 = identity and hosting, 5 functions each;; 2 = identity;; 1 = price feed;; 0 = none.
• EX066 — Accepting a dependency. Why keep a single payment provider?
  Show marking criteria

  Rubric: 3 = a second would cost more than the risk; covered by contract and a plan;; 2 = cost;; 1 = must remove;; 0 = none.

Synthesis

Classifying data and counting dependencies show where protection and resilience effort should go.

Continue studying — chapter 22 of 40

← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →