Chapter 31 — Systems, endpoints and hardware security: implementation II
Lesson map
Lesson 31 published. Map, example, EX091.
flowchart TD
N0["Learning outcomes"]
N1["31.1 Audit data"]
N2["Lab — Lab — allowlist evaluation"]
N3["31.2 Reading the result"]
N4["31.3 Interpretation"]
N5["31.4 Fix and enforce"]
N6["Allowlist design choices"]
N7["Monitoring blocks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX091"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["31.1 Audit data"]
N2["Lab — Lab — allowlist evaluation"]
N3["31.2 Reading the result"]
N4["31.3 Interpretation"]
N5["31.4 Fix and enforce"]
N6["Allowlist design choices"]
N7["Monitoring blocks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX091"]
[Learning outcomes]
|
v
[31.1 Audit data]
|
v
[Lab — Lab — allowlist evaluation]
|
v
[31.2 Reading the result]
|
v
[31.3 Interpretation]
|
v
[31.4 Fix and enforce]
|
v
[Allowlist design choices]
|
v
[Monitoring blocks]
|
v
[Worked example] --> [Exercise EX091]
Learning outcomes
You will (1) evaluate an application allowlist against a week of executions; (2) protect accessibility; (3) decide when to enforce.
31.1 Audit data
With application control in audit mode for a week, the system logs every program that would have been blocked.
Audit mode changes nothing for patrons: every program still runs, and the log simply records which ones the allowlist would have stopped. Mateo chose the pilot branch and a full week so that weekday and weekend use would both appear. The log records the program name and a count, not who ran it, which keeps the evaluation within the project's privacy rules. The lab summarises a synthetic version of that week.
Lab — Lab — allowlist evaluation
"""Evaluate an application allowlist against a synthetic week of execution events (stdlib only)."""
allow = {"browser.exe", "office.exe", "pdfviewer.exe", "catalogue.exe", "printclient.exe"}
events = [("browser.exe", 900), ("office.exe", 310), ("pdfviewer.exe", 220), ("catalogue.exe", 150),
("printclient.exe", 400), ("game_setup.exe", 6), ("toolbar_installer.exe", 3), ("accessibility_reader.exe", 14)]
blocked = [(e, n) for e, n in events if e not in allow]
total = sum(n for _, n in events)
print(f"executions {total}, would be blocked {sum(n for _, n in blocked)}")
for e, n in blocked: print(f" {e}: {n}")
Run with python3 lab_allow.py. Verified output:
executions 2003, would be blocked 23
game_setup.exe: 6
toolbar_installer.exe: 3
accessibility_reader.exe: 14
31.2 Reading the result
Of 2,003 executions, 23 would be blocked: game_setup.exe (6), toolbar_installer.exe (3) and accessibility_reader.exe (14).
The blocked share is small, a little over one execution in a hundred, which tells Mateo that the allowlist already covers almost everything patrons use. The detail matters more than the total, though. Two of the three blocked programs are unwanted, and one is not. Reading the list item by item, rather than accepting a low overall rate as good enough, is what reveals the problem with the reader.
31.3 Interpretation
The game and toolbar installers are exactly what the control should stop. The accessibility reader is a needed tool missing from the list.
The game and toolbar installers match the scenario ranked highest in the threat analysis, so the control is doing its job. The reader is a different matter: fourteen launches in a week means patrons rely on it. Enforcing the list as it stood would have locked those patrons out of the PCs, a harm the ethics chapter warned about. Mateo treats the omission as a defect in the allowlist, not as a patron problem to work around.
31.4 Fix and enforce
The reader is added by publisher signature; another audit week shows only unwanted installers blocked; enforce mode begins.
Adding the reader by publisher signature means future updates from the same publisher will run without new entries. The second audit week is a check that the fix worked and that nothing else was missing; it shows only the unwanted installers. Mateo switches to enforce mode on the pilot branch first, watches the block log for several days and then rolls enforcement out to the other branches in stages.
Allowlist design choices
Allowlists can identify programs by file path, by file hash or by publisher signature. Paths are easy but weak, because a user might place a different program at an allowed path if permissions allow. Hashes are precise but break with every update. Publisher signatures balance both: any version signed by an approved publisher runs. Microsoft's application control documentation describes these rule types. Fernhill uses publisher rules for most software and hash rules for a few unsigned tools.
Patrons run as standard users who cannot write to program folders, which also protects path-based rules.
Monitoring blocks
After enforcement, each block is logged. A weekly review checks for new needed tools blocked by mistake.
Communicating
Librarians are told what patrons will see if a program is blocked and how to request additions.
Fairness
Protecting accessibility tools is a fairness requirement, not a convenience.
Worked example
A librarian confirms that two patrons use the reader daily. Without the audit week, enforcing would have blocked them.
Synthetic case. Synthetic.
Errors and limits
Audit periods must be long enough to see weekly patterns.
Exercises
- EX091 — Lab counts. How many executions would be blocked and which? Rubric: 3 = 23: game 6, toolbar 3, reader 14; 2 = two; 1 = one; 0 = none.
- EX092 — Reader fix. How was the reader added? Rubric: 3 = by publisher signature; 2 = partial; 1 = vague; 0 = none.
- EX093 — Audit value. What did the audit week prevent? Rubric: 3 = blocking accessibility users; 2 = partial; 1 = vague; 0 = none.
Synthesis
Audit before enforcing and protect accessibility.
Continue studying — chapter 31 of 50
← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →