Chapter 6 — Patching with clinical hours in mind
Lesson map
Lesson 06 published. Map, example, EX026.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Timing"]
N2["6.2 Rings"]
N3["6.3 Measuring latency"]
N4["6.4 Failures"]
N5["Third-party software"]
N6["Emergency updates"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX026"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Timing"]
N2["6.2 Rings"]
N3["6.3 Measuring latency"]
N4["6.4 Failures"]
N5["Third-party software"]
N6["Emergency updates"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX026"]
[Learning outcomes]
|
v
[6.1 Timing]
|
v
[6.2 Rings]
|
v
[6.3 Measuring latency]
|
v
[6.4 Failures]
|
v
[Third-party software]
|
v
[Emergency updates]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX026]
Learning outcomes
You will (1) schedule updates around surgeries; (2) track latency; (3) handle failures.
6.1 Timing
Clinics run long days and some Saturdays. Updates install overnight with restarts at 21:00, and a deadline forces a restart after five days. SP 800-40 Rev. 4 recommends planning maintenance so that patching is routine rather than an emergency. Restarting at 21:00 avoids late appointments and evening cleaning, and the five-day deadline ensures that a PC left signed in does not delay updates indefinitely. Saturday clinics are asked about their hours so that restarts do not interrupt work. The schedule is agreed with clinic managers and written into the patch plan, so changes to it are deliberate, recorded decisions.
6.2 Rings
A small first ring of office machines takes updates on release day, clinics follow after three days. If the first ring shows problems, the supplier pauses the second ring. Office machines go first because problems there are less disruptive than in a clinic: an office user can wait for a fix, while a surgery cannot. Three days gives the supplier time to spot problems reported by the first ring or published by the vendor. Pausing the second ring is the supplier's decision, but it must tell the operations manager and record why, and the pause has an end date. Updates for actively exploited flaws can skip the three-day wait, but the supplier records the shortcut and tells the operations manager.
6.3 Measuring latency
Priya measures days from release to install for each desktop, and reports the share within 14 days and the slowest tail. Machines often switched off at night show up in the tail. The share within 14 days shows typical performance, while the slowest tail shows which machines are left exposed for longest. Looking at the tail by clinic and role tells Priya where to act: a reception PC that is switched off every evening needs a different fix from a machine that fails to install. Her monthly figure uses the same definition each time, so changes can be compared fairly.
6.4 Failures
Failed updates are grouped by cause: pending restart, low disk space, offline. Each cause gets a fix, such as Wake-on-LAN for overnight installs. Grouping by cause turns a list of failures into a set of fixes the supplier can act on. Pending restarts are handled by the deadline, low disk space by clearing old files and checking disk sizes, and offline machines by waking them for installs. Each month Priya checks whether a cause has shrunk after its fix was applied, rather than assuming the fix worked. Repeated failures on one machine are passed to the supplier for investigation.
Third-party software
Operating system updates are only part of the picture. Browsers, PDF readers and the practice management client also need updates. Priya asks the supplier for a monthly report of these applications' versions across the estate. The first report shows an outdated PDF reader on eleven desktops, because it had been installed separately from the managed package. The supplier replaces it with the managed version, after which it updates automatically.
The practice management client updates are scheduled with its vendor, because database changes sometimes need all clinics updated together. Priya adds these dates to the shared calendar so staff know in advance.
Emergency updates
Most updates can follow the normal rings, but a flaw that is already being exploited changes the balance between caution and speed. NIST SP 800-40 Rev. 4 describes this as risk-based prioritisation, and the CISA Known Exploited Vulnerabilities catalogue is a practical signal that a flaw is in active use. For such updates, Kestrel's patch plan skips the normal three-day wait for clinics: the supplier checks the update on the office machines for one day and then deploys to every ring within two days. Writing this exception into the plan in advance matters, because nobody then has to argue for it during a busy clinical week when the pressure to delay is greatest.
Worked example
Within 14 days, 39 of 48 desktops were updated in month one and 46 in month three after enabling wake-up and deadlines.
Synthetic case. Figures are synthetic.
Errors and limits
Averages hide the tail; always report the slowest machines separately.
Exercises
- EX026 — Restart policy. Propose a restart policy for clinics. Rubric: 3 = evening time with deadline;; 2 = time only;; 1 = vague;; 0 = none.
- EX027 — Rings. Why use a first ring? Rubric: 3 = detect problems before clinics;; 2 = vague;; 1 = minimal attempt;; 0 = none.
- EX028 — Tail. Why report the slowest machines? Rubric: 3 = averages hide them;; 2 = generic;; 1 = vague;; 0 = none.
- EX029 — Wake-on-LAN. How does waking machines help? Rubric: 3 = allows overnight installs on switched-off PCs;; 2 = vague;; 1 = minimal attempt;; 0 = none.
- EX030 — Pause rule. Write a rule for pausing the second ring. Rubric: 3 = specific trigger and owner;; 2 = trigger only;; 1 = vague;; 0 = none.
Synthesis
Predictable schedules and a small first ring make patching dull, which is the goal.
Continue studying — chapter 06 of 12
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →