Chapter 41 — Systems, endpoints and hardware security: system optimization
Lesson map
Lesson 41 published. Map, example, EX121.
flowchart TD
N0["Learning outcomes"]
N1["41.1 Targets"]
N2["41.2 Restore"]
N3["41.3 Traffic"]
N4["41.4 Allowlist"]
N5["41.5 Guardrail"]
N6["Measuring optimisation"]
N7["Cost"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX121"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["41.1 Targets"]
N2["41.2 Restore"]
N3["41.3 Traffic"]
N4["41.4 Allowlist"]
N5["41.5 Guardrail"]
N6["Measuring optimisation"]
N7["Cost"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX121"]
[Learning outcomes]
|
v
[41.1 Targets]
|
v
[41.2 Restore]
|
v
[41.3 Traffic]
|
v
[41.4 Allowlist]
|
v
[41.5 Guardrail]
|
v
[Measuring optimisation]
|
v
[Cost]
|
v
[Worked example] --> [Exercise EX121]
Learning outcomes
You will (1) optimise restore and update processes; (2) reduce cost and effort; (3) keep security intact.
41.1 Targets
Reduce restore time at Eastgate, reduce weekly reimage traffic and reduce allowlist maintenance.
Each target comes from evidence gathered earlier. Eastgate's restore times were the slowest and most variable in the pilot. Weekly reimages created the heaviest network load. Allowlist upkeep took about an hour a week, which the studio guests had questioned. Mateo chose these three because each has a clear measure and a plausible fix, and because improving them would not loosen any security requirement. Ideas without a measure, such as making the PCs feel faster, were left off the list.
41.2 Restore
Replacing Eastgate's disks cuts its median from 9.2 to about 6 minutes.
The pilot had shown that older disks added a steady delay to every restore at Eastgate. New disks of the type used at Millbrook bring its median close to the other branches. The improvement also widens the margin against the fifteen-minute window, which had been the main concern when the slowest night reached 12.8 minutes. Mateo measures the new times for a fortnight after replacement, using the same method as the pilot so the before and after figures are comparable.
41.3 Traffic
Differential reimaging sends only changed blocks, reducing weekly traffic by about two thirds.
Instead of copying the whole image each week, the PC compares its system area with the release block by block and downloads only the parts that differ. Most weeks very little has changed, so most of the transfer disappears. The risk is that the comparison misses something, which the worked example shows happening with a boot file. Mateo tests the method on lab PCs with deliberate changes in different places before trusting it on branch PCs.
41.4 Allowlist
Publisher-based rules reduce manual updates.
Rules based on file hashes needed a new entry every time a program updated, which is where most of the weekly hour went. Converting those rules to publisher signatures, where the publisher signs its software, means updates run without any change to the list. A few unsigned programs still need hash rules. Mateo measured the number of manual updates per month before and after the change, and the drop matches the figures reported below. Marta confirmed the drop.
41.5 Guardrail
Every optimisation is re-verified against requirements before release.
Optimisation changes how the system works, so every requirement test runs again on the optimised image, along with the integration test. A faster restore that leaves files behind, or lighter traffic that skips a component, would make the system worse however good the numbers looked. The worked example shows why the rule matters: re-verification caught a boot file that differential reimaging had missed. No optimisation is released until all ten requirement tests pass.
Measuring optimisation
Each optimisation is measured before and after. Eastgate's median restore falls from 9.2 to about 6 minutes after the disk replacement; weekly reimage traffic falls by about two thirds with differential reimaging; allowlist requests needing manual hash updates fall from several a month to almost none with publisher rules. Each result is recorded with the date and method.
Mateo also checks for side effects: none of the optimisations changes any requirement's test result after the boot-file fix.
Cost
Disk replacement costs are modest compared with staff time saved.
Prioritising
Optimisations are chosen by benefit per hour of effort.
Documentation
Changes are documented in the repository.
Guardrails
No optimisation may change failure behaviour.
Review
Marta approves each optimisation.
Lessons
Optimisation must preserve every requirement.
Next
Further optimisation waits for hardware refresh.
Sharing
Results go to the studio.
Measurement
Each change is measured again after a month.
Method
Each optimisation follows the same steps: measure, change on a lab PC, verify requirements, release to one branch, measure again and release widely.
Communication
Branch staff are told when optimisations are released and what, if anything, they might notice.
Record
Results are logged.
Worked example
Differential reimaging initially misses a changed boot file; re-verification catches it, and the method is adjusted to always include boot components.
Synthetic case. Synthetic.
Errors and limits
Optimisation that skips verification can silently weaken security.
Exercises
- EX121 — Eastgate. How much did new disks improve Eastgate? Rubric: 3 = 9.2 → ~6 minutes; 2 = partial; 1 = vague; 0 = none.
- EX122 — Traffic. How much did differential reimaging cut traffic? Rubric: 3 = about two thirds; 2 = partial; 1 = vague; 0 = none.
- EX123 — Catch. What did re-verification catch? Rubric: 3 = missed boot file; 2 = partial; 1 = vague; 0 = none.
Synthesis
Optimise only with re-verification.
Continue studying — chapter 41 of 50
← Chapter 40 (draft) · Course chapter index · Chapter 42 (draft) →