Chapter 27 — Systems, endpoints and hardware security: control design
Lesson map
Lesson 27 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes"]
N1["27.1 Restore control"]
N2["27.2 Application control"]
N3["27.3 Boot control"]
N4["27.4 Failure behaviour"]
N5["27.5 Dependencies"]
N6["Logging design"]
N7["Parameters as configuration"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["27.1 Restore control"]
N2["27.2 Application control"]
N3["27.3 Boot control"]
N4["27.4 Failure behaviour"]
N5["27.5 Dependencies"]
N6["Logging design"]
N7["Parameters as configuration"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]
[Learning outcomes]
|
v
[27.1 Restore control]
|
v
[27.2 Application control]
|
v
[27.3 Boot control]
|
v
[27.4 Failure behaviour]
|
v
[27.5 Dependencies]
|
v
[Logging design]
|
v
[Parameters as configuration]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes
You will (1) specify each control in detail; (2) define parameters and failure behaviour; (3) document dependencies.
27.1 Restore control
Runs at 22:00 after closing; restores the patron area from the protected copy; verifies digests; reports result.
Twenty-two hundred hours leaves time for staff to close sessions and for late patrons to leave. The digest check after restore confirms that the patron area matches the golden manifest, rather than assuming success because the script finished. The result goes to the management server, which builds the morning report. If the server cannot be reached, the PC keeps the result and sends it on reconnecting.
27.2 Application control
Allowlist of approved programs by publisher signature and path; audit mode first, then enforce.
Publisher signatures cover most approved programs, since updates from a trusted publisher stay allowed without new entries. Path rules cover a few programs installed in protected system folders that patrons cannot write to. Rules based on file hashes are kept for the rare program with no signature, because each update needs a new hash. Audit mode runs on the pilot branch first, and its logs show what enforcement would block before anyone is affected.
27.3 Boot control
Secure Boot on; firmware password set; boot order locked to internal disk.
Locking the boot order means the PC starts only from its own disk, so a USB stick or network boot cannot load another system. The firmware password protects these settings from change at the start-up screen. Mateo's daily check reads each setting through the management tool and reports any PC where one differs, since a firmware update can sometimes reset settings to factory defaults. Such PCs are corrected the same day.
27.4 Failure behaviour
If restore fails, the PC shows "out of service" at next start and alerts staff; it does not open a session.
Failing closed protects patrons: a PC that might still hold yesterday's files does not offer a session to the next person. The out-of-service screen tells patrons to use another PC and gives staff the number to call. Staff can rerun the restore from an administrative account, and the PC returns to service once the digest check passes. Every failure and repair is logged, so repeated failures on one PC are visible.
27.5 Dependencies
Restore depends on boot integrity; alerts depend on logging; updates depend on signing keys.
Mateo lists the dependencies so that a failure in one control can be traced to the others it affects. If boot integrity failed, the restore could not be trusted. If logging failed, alerts would stop without any sign. If the signing key were compromised, a harmful update could be accepted. Each dependency has a monitoring check, and the most serious, the signing key, is taken up again in the independent review.
Logging design
Each control logs its own actions: restore start, end, success and digest result; application control blocks; firmware setting checks; USB block events. Logs go to the central server with time synchronised, following NIST SP 800-92 guidance on consistent timestamps and protected storage. Logs exclude patron content.
Mateo specifies which events trigger alerts and which are only stored, to avoid alert fatigue.
Parameters as configuration
Times, thresholds and lists are kept in configuration files under version control, not hard-coded in scripts.
Reviewing the design
Marta and Dr Novak review each control specification before implementation, checking parameters, failure behaviour and logging.
Interfaces of controls
Restore reports to the management server; application control reports blocks; both feed the dashboard.
Review cycle
Specifications are reviewed after each verification round.
Change control
Changes to parameters need approval.
Accessibility in controls
Each control specification includes a note on accessibility impact. For example, the auto-logoff warning must be readable by screen readers.
Worked example
Mateo asks Marta what staff should see for an out-of-service PC. They agree on a simple screen with a phone number for IT.
Synthetic case. Synthetic.
Errors and limits
Controls without defined failure behaviour fail open by accident.
Exercises
- EX079 — Restore schedule. When does restore run and what follows? Rubric: 3 = 22:00; verify digests; report; 2 = partial; 1 = vague; 0 = none.
- EX080 — Failure behaviour. What happens if restore fails? Rubric: 3 = out of service, alert, no session; 2 = partial; 1 = vague; 0 = none.
- EX081 — Dependencies. What does restore depend on? Rubric: 3 = boot integrity; 2 = partial; 1 = vague; 0 = none.
Synthesis
Define each control's parameters, failure behaviour and dependencies.
Continue studying — chapter 27 of 50
← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →