Chapter 24 — Systems, endpoints and hardware security: controls
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 Encryption rollout"]
N2["24.2 Account changes"]
N3["24.3 Update policy"]
N4["24.4 Exceptions"]
N5["24.5 Communication"]
N6["Pilot group"]
N7["Change log"]
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 Encryption rollout"]
N2["24.2 Account changes"]
N3["24.3 Update policy"]
N4["24.4 Exceptions"]
N5["24.5 Communication"]
N6["Pilot group"]
N7["Change log"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 Encryption rollout]
|
v
[24.2 Account changes]
|
v
[24.3 Update policy]
|
v
[24.4 Exceptions]
|
v
[24.5 Communication]
|
v
[Pilot group]
|
v
[Change log]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) implement encryption, account and update controls; (2) communicate changes; (3) handle exceptions.
24.1 Encryption rollout
Encryption is enabled in groups of ten laptops, with recovery keys escrowed and verified.
With 13 laptops to encrypt, the rollout takes one group of ten laptops and a final group of three, and it runs after the five-laptop pilot. Before each group, Gareth checks that recovery keys from the previous group are in the directory. Laptops with a start-up PIN, the finance manager's and chief executive's, receive a short guide first. The two laptops without a TPM are handled separately with a start-up password, as the exceptions list records.
24.2 Account changes
Local admin is removed with a request process for software.
Local admin rights are removed from the 25 laptops in the same staged groups, with the request form ready before the first group. In the first week Gareth receives five software requests and installs each one centrally. The specialist housing software that needed admin rights to update is packaged for central deployment. The stop rule applies here too: two help requests about the same missing permission in one group pause the next group until Gareth understands the cause.
24.3 Update policy
Updates install automatically with a forced restart after seven days' notice.
Staff see a notice when an update needs a restart, and can postpone it for up to seven days. On day five a friendly reminder appears, and on day seven the laptop restarts at a time staff can choose that day. Aisha explains that installed fixes are not active until the restart, as the sample laptop in chapter 11 showed. Restarts are counted from the management server each week, so Gareth can see whether the forced restart is closing the pending-restart gap.
24.4 Exceptions
Two old laptops without TPMs use password-based encryption until replaced.
The two oldest laptops lack a TPM, so they cannot unlock their disks automatically at start-up. Their users enter a password at start-up instead, which protects the disk if the laptop is stolen. The exception is recorded with an expiry date, because both laptops are scheduled for replacement within six months. The exception appears in the decision log with its reason, its owner and the replacement date, and is reviewed at the monthly meeting.
24.5 Communication
Staff receive a short note before each change.
Each note goes out two days before a group's change and says what staff will notice, such as a new screen-lock delay or a restart prompt. It names Gareth as the contact and gives the date of the change. Help requests during the rollout fall compared with an earlier change made without notice, which Gareth records. The note for the encryption groups also tells staff that their laptop may ask for a recovery key after a firmware update, and to call Gareth if it does.
Pilot group
Before rolling out to all staff, Gareth and Aisha apply each change to a pilot group of five laptops, including one from each team. Pilot users report any problems for a week. The pilot finds one problem: a scanner driver needs admin rights to install, which Gareth then deploys centrally.
After the pilot, rollout proceeds in groups of ten each week, with a pause if more than one problem appears. This approach follows the staged deployment advice in NIST SP 800-40 Rev. 4.
Each group's completion is recorded with the date and any issues.
Change log
Every change is recorded in a log with date, devices, reason and result.
Rollback
Each change has a rollback step written before rollout, so a problem can be reversed within an hour. During rollout, one group's screen lock setting conflicts with a presentation tool; the rollback is used for that group, the setting is adjusted and the group is redone the next week.
Project log entry
Communication runs alongside each group. Staff receive a short note two days before their laptop changes, explaining what they will notice, such as a new screen-lock delay, and whom to call. Help requests during rollout fall compared with an earlier unannounced change, which Gareth notes for future projects.
Review with the tutor
Dr Grant asks what would make her stop the rollout. Aisha writes a stop rule: two help requests about the same setting in one group pauses the next group until the cause is understood.
Worked example
One staff member's specialist housing software needs admin rights to update. Gareth packages its updates centrally instead.
Synthetic case. Synthetic.
Errors and limits
Exceptions without expiry become permanent.
Exercises
- EX070 — Rollout size. How was encryption rolled out? Rubric: 3 = groups of ten, keys escrowed; 2 = partial; 1 = vague; 0 = none.
- EX071 — Restart policy. What is the restart policy? Rubric: 3 = forced after seven days' notice; 2 = partial; 1 = vague; 0 = none.
- EX072 — TPM exception. How were laptops without TPMs handled? Rubric: 3 = password-based encryption until replaced; 2 = partial; 1 = vague; 0 = none.
Synthesis
Implement controls in stages with communication and managed exceptions.
Continue studying — chapter 24 of 40
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →