Chapter 5 — Hardening the ordinary desktops
Lesson map
Lesson 05 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Choosing a baseline"]
N2["5.2 Piloting"]
N3["5.3 Measuring compliance"]
N4["5.4 Least privilege"]
N5["Common recommendations"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Choosing a baseline"]
N2["5.2 Piloting"]
N3["5.3 Measuring compliance"]
N4["5.4 Least privilege"]
N5["Common recommendations"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX021"]
[Learning outcomes]
|
v
[5.1 Choosing a baseline]
|
v
[5.2 Piloting]
|
v
[5.3 Measuring compliance]
|
v
[5.4 Least privilege]
|
v
[Common recommendations]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) apply a recognised baseline; (2) pilot changes; (3) measure compliance.
5.1 Choosing a baseline
The 48 supported desktops follow the CIS Benchmark for their Windows version at level one, adjusted with Microsoft's security baseline. Priya and the supplier review each recommendation against clinic needs, such as card readers and the practice management client. Starting from a published benchmark gives Kestrel a tested, documented set of settings instead of a list written from scratch. Each recommendation that conflicts with clinic needs is either adjusted or left out, and the reason is written down, so that the baseline reflects Kestrel's work rather than a generic office. The supplier applies the agreed settings through its management console, which also reports compliance against them.
5.2 Piloting
Changes go first to one desktop per clinic for two weeks. The pilot finds that a screen-lock timeout of five minutes frustrates surgery staff wearing gloves; it is set to ten minutes with a lock shortcut, and the reason recorded. Piloting one desktop per clinic catches local needs that a single office test would miss, such as different card readers or the surgery workflow. Staff at pilot desks are told what changed and how to report problems, and Priya keeps a short log of each complaint with the decision taken. The baseline is rolled out to the remaining desktops only after the two-week pilot ends.
5.3 Measuring compliance
The supplier's console reports compliance per setting. Priya tracks the share of desktops fully compliant each week. Drift is investigated rather than overwritten blindly, since a drift often signals a real working need. When a desktop drifts, Priya asks the clinic first: a setting changed to let a new scanner work is a reason to adjust the baseline or add a documented exception, while an unexplained change is investigated as a possible problem. Weekly tracking also shows whether compliance holds after the rollout, not just on the day settings are applied. Clinic-specific gaps are listed separately so that they can be followed up.
5.4 Least privilege
Staff lose local administrator rights; the supplier uses separate admin accounts. This single change prevents much drift and accidental software installation. Before the change, staff could install software, change settings and disable protection on their own machines, often with good intentions. Removing those rights means changes go through the supplier, who records them. Priya arranges how staff request software, so the clinics are not left waiting when they need a legitimate tool, and the supplier's separate admin accounts are used only for administration, never for email or web browsing.
Common recommendations
The baseline includes items most organisations share: a host firewall on, automatic screen lock, no guest accounts, removal of unused features, PowerShell logging, and blocking macros from internet files in office documents. Priya explains each to clinic managers in one plain sentence, because staff accept a change more readily when they know what it protects against.
She also records which recommendations were skipped. Two level one items conflict with the practice management client's printing; they are noted with the reason and reviewed when the client is upgraded. A short skip list is a sign of a careful baseline, not a weak one.
Worked example
Compliance rises from 61 to 92 percent of desktops over six weeks, with the remaining gaps tied to two clinic-specific scanners being re-tested.
Synthetic case. Figures are synthetic.
Errors and limits
A baseline applied without a pilot can stop clinical work; a pilot without measurement cannot show improvement.
Exercises
- EX021 — Baseline source. Name two sources for a Windows desktop baseline. Rubric: 3 = CIS Benchmark and Microsoft security baseline;; 2 = one;; 1 = vague;; 0 = none.
- EX022 — Adjusting a setting. How should a baseline deviation be recorded? Rubric: 3 = setting, value, reason, approver;; 2 = partial;; 1 = not recorded;; 0 = none.
- EX023 — Drift handling. Why investigate drift before reverting? Rubric: 3 = it may reflect a real need;; 2 = generic;; 1 = vague;; 0 = none.
- EX024 — Admin rights. Explain one benefit of removing local admin rights. Rubric: 3 = limits installation and setting changes;; 2 = vague;; 1 = minimal attempt;; 0 = none.
- EX025 — Compliance metric. Propose a weekly compliance metric. Rubric: 3 = share fully compliant with denominator;; 2 = count only;; 1 = vague;; 0 = none.
Synthesis
Ordinary desktops are best handled with a recognised baseline, a pilot and steady measurement.
Continue studying — chapter 05 of 12
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →