◇ OpenCyber Academy
Technologist · Chapter 27 · English

Chapter 27 — Making improvements

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 27 — Making improvements

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Order"]
  N2["27.2 Recording"]
  N3["27.3 Communication"]
  N4["27.4 Problems"]
  N5["Stale accounts in practice"]
  N6["Backup alerting"]
  N7["SSH fixes"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Order"]
  N2["27.2 Recording"]
  N3["27.3 Communication"]
  N4["27.4 Problems"]
  N5["Stale accounts in practice"]
  N6["Backup alerting"]
  N7["SSH fixes"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Order]
    |
    v
[27.2 Recording]
    |
    v
[27.3 Communication]
    |
    v
[27.4 Problems]
    |
    v
[Stale accounts in practice]
    |
    v
[Backup alerting]
    |
    v
[SSH fixes]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) carry out agreed changes; (2) record each; (3) avoid disruption.

27.1 Order

Changes go in order of risk and effort: stale accounts first, then backup alerting, SSH fixes, encryption fixes and finally the laptop baseline.

Stale accounts come first because they are a clear risk that takes an afternoon to fix. Backup alerting follows because mis01's failed job had gone unnoticed, and the SSH changes need only a Saturday morning. The laptop baseline comes last because it needs a pilot and two rollout groups, which take most of the six weeks.

27.2 Recording

Each change is logged with date, owner and result.

The log records the date, who made the change, what changed and the result, using the same four fields as the trust's change log. Tomás adds which measure each change is meant to affect, so that at the end each improvement in the numbers can be traced to a specific logged change. A change without a log entry is treated as unfinished. Dev and Tomás share one log for the project rather than keeping separate notes, so nothing is recorded twice or missed.

27.3 Communication

Staff get short notices before visible changes.

Notices go out before visible changes such as the new screen lock or blocked USB autorun, telling staff what will change, when, and who to ask. Changes staff will not notice, such as the SSH settings on servers, are not announced to everyone. Fewer surprises mean fewer calls to Dev during the busy weeks of the rollout. Each notice is short enough to read on a phone and is sent by the school office, whose emails staff already expect. Teachers who reply with a question get an answer from Dev before the change reaches their laptop.

27.4 Problems

Problems during the six weeks were few, and each change had prepared rollback steps.

Each change had a rollback written before it was made, such as the documented old settings for the laptop pilot and the open session kept during the SSH changes. The SMBv1 conflict was solved by updating the whiteboard app instead of rolling back. The SSH rollback was never needed, because the open session and confirmed keys meant nobody was locked out. Writing rollback steps first also made each change quicker to approve, because Dev and the business manager could see how it would be undone.

Stale accounts in practice

Disabling the four stale accounts takes an afternoon. Before each is disabled, Dev checks with the head teacher that the person has left and whether colleagues need any files. One former teacher's folder holds lesson plans still in use; they are moved to a shared area before the account is disabled.

The leavers form is then introduced. The school offices send it on each person's last day, and Dev confirms the account is disabled within one working day.

The leavers form is reviewed after its first month: all three leavers that month were disabled on time.

Backup alerting

The failed backup on mis01 had gone unnoticed because failure emails went to a mailbox nobody checked. That is a common pattern: the backup software worked as designed, but its warning reached no one. Alerts now go to a shared mailbox read daily by Dev and the business manager, so a single absence does not hide a failure. The weekly backup age script provides a second, independent check that does not depend on email at all. Tomás tests the alerting by asking Dev to pause a non-critical job for one night; the failure email arrives and the script flags the job the next morning.

SSH fixes

Dev applies the SSH changes on a Saturday morning, when nobody depends on the servers. Before disabling password sign-in on mis01, he asks the outside company's engineers to confirm that their keys work, and keeps an existing session open while testing a new one, so a mistake cannot lock him out. Each server is changed separately and checked with the lab script before moving to the next. The change log records the time, the setting and the result. Nobody is locked out, and the rerun of the lab shows all four servers compliant with no deviations.

Encryption and laptop baseline fixes

The seven laptops not yet fully encrypted are handled one by one: four finish encrypting on their own once left on overnight, two have protection resumed after a firmware update, and one needs its TPM enabled in firmware with the teacher's agreement. The laptop baseline follows the pilot and rollout described in chapter 13, with the interactive whiteboard app updated first so that SMBv1 can stay disabled. Handling the two areas in sequence rather than together means that any support call can be traced to one change, which keeps troubleshooting simple for a one-person IT team.

Worked example

All changes are completed in six weeks.

Synthetic case. Events are synthetic.

Errors and limits

Doing all changes at once makes problems hard to trace.

Exercises

Synthesis

Ordered, logged and communicated changes reduce surprises.

Continue studying — chapter 27 of 30

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →