Chapter 3 — Security architecture and engineering: systems, data and dependencies
Lesson map
Lesson 03 published. Map, example, EX027.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Mapping systems"]
N2["3.2 Drawing data flows"]
N3["3.3 Suppliers and dependencies"]
N4["Lab — Counting services that depend on each supplier"]
N5["3.4 Single points of failure"]
N6["3.5 Using the map"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX027"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Mapping systems"]
N2["3.2 Drawing data flows"]
N3["3.3 Suppliers and dependencies"]
N4["Lab — Counting services that depend on each supplier"]
N5["3.4 Single points of failure"]
N6["3.5 Using the map"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX027"]
[Learning outcomes]
|
v
[3.1 Mapping systems]
|
v
[3.2 Drawing data flows]
|
v
[3.3 Suppliers and dependencies]
|
v
[Lab — Counting services that depend on each supplier]
|
v
[3.4 Single points of failure]
|
v
[3.5 Using the map]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX027]
Learning outcomes
You will (1) map Saltmarsh's systems and data flows; (2) identify suppliers and dependencies; (3) find where one failure would stop many services.
3.1 Mapping systems
Leah lists Saltmarsh's main systems with their owners: the core banking system at the service bureau, online banking, the new loan system, email and office tools in the cloud, branch PCs, the card processor and the phone system. For each she records what data it holds and who uses it. Member account balances and transactions sit in core banking; loan documents sit in the loan system; member correspondence sits in email. Knowing where data lives tells her which systems need the strongest protection.
3.2 Drawing data flows
Leah draws how a loan application moves: a member uploads documents through the website; the loan system stores them; a loan officer reviews them on a branch PC; approval triggers a payment through core banking; the member receives an email. She labels each flow with the data it carries and marks where it crosses to a supplier. Shostack (2014) recommends close attention to these crossings, because each one relies on someone else's controls and assumptions about what the other side has checked.
3.3 Suppliers and dependencies
Saltmarsh depends heavily on suppliers: the service bureau, the loan system vendor, the cloud email provider, the card processor, the identity provider used for staff sign-in and two internet providers. Leah records each supplier's role, the data it holds, the contract owner and what happens if it fails. She notes that the identity provider is used by almost every system, so its failure or compromise would affect nearly everything. Dependencies are part of the architecture even though Saltmarsh does not operate them.
Lab — Counting services that depend on each supplier
# Count services depending on each supplier (synthetic map).
services = {"online banking": ["identity", "bureau", "internet"], "loan system": ["identity", "loan vendor", "bureau"],
"email": ["identity", "cloud email"], "branch PCs": ["identity", "internet"],
"card services": ["card processor", "bureau"], "staff intranet": ["identity", "cloud email"],
"member payments": ["identity", "bureau"]}
count = {}
for s, deps in services.items():
for d in deps: count[d] = count.get(d, 0) + 1
for d, n in sorted(count.items(), key=lambda x: (-x[1], x[0])): print(f"{d:14} {n} service(s)")
Run with python3 lab_deps.py. Verified output:
identity 6 service(s)
bureau 4 service(s)
cloud email 2 service(s)
internet 2 service(s)
card processor 1 service(s)
loan vendor 1 service(s)
3.4 Single points of failure
The lab counts how many services depend on each supplier. The identity provider supports six services and the service bureau four; most others support one or two. Leah discusses the results with her manager. For the identity provider they agree a break-glass administrator account stored securely offline and a tested procedure for signing in if the provider fails. For the service bureau they rely on its contractual recovery commitments and keep a manual procedure for urgent member withdrawals at branches.
3.5 Using the map
Leah stores the system list, data flow diagram and dependency table together as Saltmarsh's first architecture overview. When the board later considers a new budgeting app for members, the overview shows that it would add a new supplier holding transaction data and another dependency on the identity provider. The board asks the vendor security questions before signing. Felix notes that a simple map pays for itself the first time it shapes a decision before money is spent. Leah sets a yearly date to update the overview.
Worked example
Leah maps systems and loan data flows, lists six suppliers, counts dependencies to find the identity provider as the main single point of failure and uses the map for a board decision.
Synthetic case. Systems, suppliers and counts are synthetic; Shostack (2014) is real.
Errors and limits
Maps go stale without updates. Supplier failures can cascade through fourth parties.
Exercises
- EX027 — Where balances live. Which system holds account balances and transactions? Rubric: 3 = core banking at the service bureau;; 2 = core banking;; 1 = loan system;; 0 = none.
- EX028 — Loan flow steps. Describe the loan application flow. Rubric: 3 = upload, loan system, officer review, core banking payment, email;; 2 = most steps;; 1 = vague;; 0 = none.
- EX029 — Crossing attention. Why do supplier crossings need attention? Rubric: 3 = each relies on someone else's controls and assumptions;; 2 = assumptions;; 1 = vague;; 0 = none.
- EX030 — Supplier record. What does Leah record for each supplier? Rubric: 3 = role, data held, contract owner and failure impact;; 2 = three;; 1 = vague;; 0 = none.
- EX031 — Identity count. How many services depend on the identity provider in the lab? Rubric: 3 = six;; 2 = 6;; 1 = one;; 0 = none.
- EX032 — Bureau count. How many services depend on the service bureau? Rubric: 3 = four;; 2 = 4;; 1 = vague;; 0 = none.
- EX033 — Break-glass. What fallback was agreed for the identity provider? Rubric: 3 = an offline break-glass account and tested sign-in procedure;; 2 = break-glass;; 1 = vague;; 0 = none.
- EX034 — Bureau fallback. What fallback exists for the service bureau? Rubric: 3 = contractual recovery and a manual branch withdrawal procedure;; 2 = manual;; 1 = vague;; 0 = none.
- EX035 — Budgeting app. What did the map reveal about the budgeting app? Rubric: 3 = a new supplier with transaction data and more identity dependency;; 2 = new supplier;; 1 = vague;; 0 = none.
- EX036 — Board action. How did the board respond to the budgeting app? Rubric: 3 = asked the vendor security questions before signing;; 2 = questions;; 1 = signed;; 0 = none.
- EX037 — Map payoff. When does a simple map pay for itself? Rubric: 3 = the first time it shapes a decision before money is spent;; 2 = first decision;; 1 = never;; 0 = none.
- EX038 — Stale maps. What limits the usefulness of the map over time? Rubric: 3 = it goes stale without updates;; 2 = staleness;; 1 = vague;; 0 = none.
Synthesis
Mapping systems, data flows and dependencies shows where protection and fallback plans matter most.
Continue studying — chapter 03 of 04
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →