Chapter 15 — Security architecture and engineering: integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Dependencies"]
N2["15.2 Supplier access"]
N3["15.3 Supplier failure"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Dependencies"]
N2["15.2 Supplier access"]
N3["15.3 Supplier failure"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 Dependencies]
|
v
[15.2 Supplier access]
|
v
[15.3 Supplier failure]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) list Linden's external dependencies; (2) assess supplier access; (3) plan for supplier failure.
15.1 Dependencies
Nadia lists the external services Linden depends on: the cloud practice management vendor, the email provider, the payment provider, the X-ray software vendor with remote support, the internet providers for each practice and the text message reminder service. For each she records what data it holds, who manages the contract and what happens if it fails. The practice management vendor is the deepest dependency, since every appointment and record lives there. Dependencies are part of the architecture even though Linden does not run them.
15.2 Supplier access
The X-ray vendor connects remotely to imaging servers for support using a remote access tool that is always on. Nadia recommends that sessions be enabled only on request and approved by Grace, with the vendor using named accounts and multi-factor sign-in. She also asks the text reminder service what patient data it receives and finds it gets full names and treatment types, though only first names and times are needed. Grace asks the vendor to reduce the data sent. Both requests are recorded in the supplier file.
15.3 Supplier failure
Nadia asks each critical supplier for its recovery commitments and checks what Linden can do alone. If the practice management system fails, practices can print next-day lists each evening as a fallback. If the X-ray vendor disappears, the imaging software still runs locally but cannot be updated. She adds these to the response cards from chapter 8. Planning for supplier failure is part of resilience, because the most likely long outage at a small organisation is often someone else's problem. Each fallback is practised once a year.
Worked example
Nadia lists six dependencies, restricts always-on vendor access, reduces data sent to a text service and adds supplier failure fallbacks.
Synthetic case. Suppliers and data are synthetic.
Errors and limits
Supplier commitments may not be honoured. Fallbacks need regular practice.
Exercises
- EX057 — Deepest dependency. Which dependency is deepest and why? Rubric: 3 = the practice management vendor; all appointments and records live there;; 2 = practice system;; 1 = email;; 0 = none.
- EX058 — Vendor access change. How should X-ray vendor access change? Rubric: 3 = enabled on request, approved, named accounts with multi-factor;; 2 = on request;; 1 = always on;; 0 = none.
- EX059 — Text service data. What data does the text service actually need? Rubric: 3 = first names and appointment times;; 2 = minimal;; 1 = full records;; 0 = none.
- EX060 — Records fallback. What is the fallback if the practice system fails? Rubric: 3 = printing next-day lists each evening;; 2 = print;; 1 = vague;; 0 = none.
Synthesis
Dependencies belong in the architecture, with limited supplier access, minimal shared data and practised fallbacks.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →