Chapter 20 — Application control
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Allowlisting"]
N2["20.2 Where it fits"]
N3["20.3 Introducing safely"]
N4["20.4 Maintaining"]
N5["Explaining it to staff"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Allowlisting"]
N2["20.2 Where it fits"]
N3["20.3 Introducing safely"]
N4["20.4 Maintaining"]
N5["Explaining it to staff"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Allowlisting]
|
v
[20.2 Where it fits]
|
v
[20.3 Introducing safely]
|
v
[20.4 Maintaining]
|
v
[Explaining it to staff]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) explain allowlisting; (2) choose where it fits; (3) introduce it safely.
20.1 Allowlisting
Application control allows only approved programs to run. Instead of trying to recognise every bad program, it recognises the good ones. Microsoft App Control for Business and AppLocker provide this on Windows; on Linux, package-managed software and restricted permissions achieve a similar effect.
The difference matters for new threats: a blocklist must already know a program is bad, while an allowlist blocks anything nobody approved, including programs never seen before. The cost is that every legitimate new program needs approval, so the request process has to be quick enough that staff use it.
20.2 Where it fits
Allowlisting is easiest on devices with a stable set of software. The trust's office and reception PCs run a few known programs and are good candidates. Teachers' laptops change more often, so they start with a looser policy allowing anything installed by the management service.
The six office and reception PCs run the finance software, the management system's client, a browser and office apps, and those change only with planned updates. Starting there gives Dev experience with the policy on devices where a mistake affects a handful of staff rather than every classroom.
20.3 Introducing safely
Like attack surface rules, application control starts in audit mode. For three weeks, Dev collects what runs on the office PCs. The list shows the expected programs plus a printer utility and an old payroll helper. Both are added after checking they are needed.
Three weeks of audit covers month-end on the office PCs, when the payroll helper is used, so a shorter audit would have missed it. Each program found in audit is checked with the office manager before it is added, and anything nobody recognises is removed rather than allowed.
20.4 Maintaining
Each new approved program is added to the policy through a simple request. The policy is reviewed each term.
A request names the program, the reason and the PCs that need it, and Dev adds a publisher rule where the program is signed. The termly review removes programs no longer used, so the allowlist does not grow into a list of everything ever installed. Each change is written in the change log like any other configuration change, with the date and who asked for it.
Explaining it to staff
Office staff are told before enforcement that only approved programs will run on their PCs and how to request a new one. Dev promises to answer requests within two working days and keeps the request form to three questions: what program, what for, and how urgent. Clear expectations prevent frustration and stop people looking for workarounds when something is blocked, which would undermine the policy. On the Linux servers the equivalent idea is simpler: only packages from the distribution's signed repositories are installed, and home directories are mounted so programs cannot be run from them, so unapproved software has nowhere easy to run.
Worked example
After enforcement on six office PCs, one unexpected block occurs for a new version of the finance software; Dev adds the publisher rule so future updates run without new entries.
Synthetic case. Events are synthetic.
Errors and limits
Allowlists based on file paths are weaker than those based on publisher signatures, since anyone who can write to the path can run code there.
Exercises
- EX058 — Allow versus block. Contrast allowlisting with blocklisting. Rubric: 3 = allow known good vs block known bad, implications;; 2 = definitions;; 1 = vague;; 0 = none.
- EX059 — Candidate devices. Which trust devices suit allowlisting first, and why? Rubric: 3 = office PCs, stable software;; 2 = office;; 1 = teachers;; 0 = none.
- EX060 — Rule type. Why prefer publisher rules to path rules? Rubric: 3 = path writable risk, updates handled;; 2 = stronger;; 1 = vague;; 0 = none.
Synthesis
Application control strongly reduces risk where software is stable and the policy is maintained.
Continue studying — chapter 20 of 30
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →