Chapter 24 — Systems, endpoints and hardware security: methods I
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 Sources"]
N2["Lab — Lab — image hardening check"]
N3["24.2 Reading the result"]
N4["24.3 Closing gaps"]
N5["24.4 Recording"]
N6["Choosing among sources"]
N7["Repeatable check"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 Sources"]
N2["Lab — Lab — image hardening check"]
N3["24.2 Reading the result"]
N4["24.3 Closing gaps"]
N5["24.4 Recording"]
N6["Choosing among sources"]
N7["Repeatable check"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 Sources]
|
v
[Lab — Lab — image hardening check]
|
v
[24.2 Reading the result]
|
v
[24.3 Closing gaps]
|
v
[24.4 Recording]
|
v
[Choosing among sources]
|
v
[Repeatable check]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) verify an image against hardening requirements; (2) use benchmarks and STIGs as sources; (3) close gaps.
24.1 Sources
CIS Benchmarks and Microsoft baselines provide recommended settings; DISA STIGs offer stricter options. Mateo selects ten requirements relevant to kiosks.
Mateo compared the three sources setting by setting for the items relevant to public PCs. Where they agreed, he took the common setting; where they differed, he chose the one that suited a library and recorded why. The ten requirements in the lab are the result: each can be checked automatically against an image, and each traces to a source and an objective.
Lab — Lab — image hardening check
"""Check a synthetic kiosk image configuration against hardening requirements (stdlib only)."""
req = {"secure_boot": True, "firmware_password": True, "usb_storage": False, "user_is_admin": False, "autorun": False,
"disk_encryption": True, "app_control": "enforce", "auto_logoff_min": 15, "remote_logging": True, "smb1": False}
image = {"secure_boot": True, "firmware_password": False, "usb_storage": False, "user_is_admin": False, "autorun": False,
"disk_encryption": True, "app_control": "audit", "auto_logoff_min": 15, "remote_logging": True, "smb1": False}
gaps = [k for k in req if image[k] != req[k]]
print(f"requirements {len(req)}, met {len(req)-len(gaps)}")
for g in gaps: print(f" gap: {g} (required {req[g]}, image {image[g]})")
Run with python3 lab_harden.py. Verified output:
requirements 10, met 8
gap: firmware_password (required True, image False)
gap: app_control (required enforce, image audit)
24.2 Reading the result
Eight of ten requirements are met. Gaps: firmware password not set, and application control in audit rather than enforce mode.
Both gaps were expected. The firmware password had never been set across the fleet, as the inventory showed, and application control had been left in audit mode deliberately while the allowlist was built. The lab confirms both and, just as usefully, confirms the other eight settings are already correct in the image. Mateo files the output with the release record so the starting point is documented.
24.3 Closing gaps
Firmware passwords are set through the vendor's management tool. Application control stays in audit until chapter 31 evaluates the allowlist, avoiding blocking needed tools.
Mateo sets the passwords on lab PCs first, checks that staff can still reach the firmware menu when needed, then rolls out branch by branch. For application control, the audit logs from the pilot branch show what would be blocked. Moving to enforcement waits until those logs show no needed program missing from the allowlist, which protects patrons who rely on accessibility tools.
24.4 Recording
Each gap and decision is recorded in the image release notes.
The release notes say which requirements the image meets, which gaps remain, why each gap is accepted for now and when it will be closed. Marta reads them before approving a release. A later reviewer can see from the notes alone why the image was released with application control in audit mode, without having to ask anyone who was there at the time. Notes are kept with every image in the repository.
Choosing among sources
CIS Benchmarks offer levels: Level 1 settings are practical for most organisations, Level 2 stricter. DISA STIGs are designed for defence systems and can be too strict for a library. Mateo chooses mostly Level 1 settings plus a few kiosk-specific ones, such as USB storage blocking, and records why each was chosen.
He checks each setting against accessibility needs, since some strict settings disable features screen readers use.
Repeatable check
The hardening check runs automatically on each new image release, so gaps cannot slip in unnoticed.
Firmware password process
Setting firmware passwords on 300 PCs by hand would take days. The vendor's management tool sets them centrally, and the password is stored in Fernhill's password manager with access limited to IT. The process is documented so it can be repeated for new PCs.
Recording versions
The check records the benchmark version used, so later reviews know which recommendations were considered.
Worked example
Marta asks why not enforce immediately. Mateo explains that enforcing an untested allowlist might block accessibility tools, harming patrons; audit first collects evidence.
Synthetic case. Synthetic.
Errors and limits
Copying benchmark settings without testing can break needed functions.
Exercises
- EX070 — Lab gaps. Which two gaps were found? Rubric: 3 = firmware password, app control audit; 2 = partial; 1 = vague; 0 = none.
- EX071 — Sources. Name three sources for settings. Rubric: 3 = CIS, Microsoft baselines, STIGs; 2 = two; 1 = one; 0 = none.
- EX072 — Audit first. Why keep application control in audit? Rubric: 3 = avoid blocking needed tools; 2 = partial; 1 = vague; 0 = none.
Synthesis
Check images against requirements and close gaps deliberately.
Continue studying — chapter 24 of 50
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →