◇ OpenCyber Academy
Technical · Chapter 16 · English

Chapter 16 — Digital forensics and malware analysis: Technical documentation and safety

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 16 — Digital forensics and malware analysis: Technical documentation and safety

Lesson map

Lesson 16 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 Audiences"]
  N2["16.2 Runbook structure"]
  N3["16.3 Safety warnings"]
  N4["16.4 Protecting data"]
  N5["16.5 Plain writing"]
  N6["16.6 Document control"]
  N7["16.7 Testing documents"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 Audiences"]
  N2["16.2 Runbook structure"]
  N3["16.3 Safety warnings"]
  N4["16.4 Protecting data"]
  N5["16.5 Plain writing"]
  N6["16.6 Document control"]
  N7["16.7 Testing documents"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
    |
    v
[16.1 Audiences]
    |
    v
[16.2 Runbook structure]
    |
    v
[16.3 Safety warnings]
    |
    v
[16.4 Protecting data]
    |
    v
[16.5 Plain writing]
    |
    v
[16.6 Document control]
    |
    v
[16.7 Testing documents]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) write clear technical documentation; (2) write safe procedures; (3) protect patient and staff data in records; (4) maintain documents.

16.1 Audiences

Case notes are for investigators; runbooks for operators; summaries for managers; notices for ward staff. Each uses the language its reader needs.

For the Ward 4 incident, the case notes record times and sources, the runbook tells an operator what to do on the next pop-up, the board summary covers impact and cost, and the ward notice gives two instructions. Writing one document for all four would serve none of them well. Sana drafts each document separately from the same case facts, so the numbers in each version agree.

16.2 Runbook structure

Purpose, scope, prerequisites, numbered steps, expected results, what to do if results differ, and safety warnings. Kent et al. (2006) recommend documented procedures so collection is consistent.

The removable media runbook follows this structure, with prerequisites such as the kit drive and Owen's contact details before the steps. Expected results tell the operator what normal looks like, such as containment confirmed in the console. The part on differing results says when to stop and escalate rather than improvise. Kent et al. (2006) also stress that procedures should be reviewed and updated regularly.

16.3 Safety warnings

Warnings sit before the step they concern: "Do not open samples. Do not reimage without security sign-off. Do not connect the kit drive to non-isolated machines except the target."

A warning placed after the step it concerns is read too late. The reimage warning comes before the step that mentions reimaging, which is the risk the helpdesk nearly triggered on day two. Each warning is one short sentence in bold type, without explanation, so it is read even in a hurry.

16.4 Protecting data

Case documents may include patient names visible in screenshots. These are redacted or avoided; screenshots of the medication viewer are not taken. Staff names appear only where needed.

Screenshots of WARD4-PC2's desktop could include the medication chart viewer, so none are taken; EDR exports are used instead. Where a staff name is needed, such as the nurse who reported the pop-up, it is recorded once in the restricted case notes and not repeated in summaries. The board summary for the Ward 4 incident contains no personal names at all.

16.5 Plain writing

Short sentences, active voice, defined terms, and times with zones.

Times are written as '10:09 UTC' rather than 'just after ten', and terms such as containment are defined the first time they appear. Active voice says who did what, such as 'Sana applied containment', which matters for accountability. The ward notice follows the same style, with two instructions in short sentences that fit on a card beside a ward PC. Owen returns any draft with an unexplained term or a time without its zone.

16.6 Document control

Each runbook has a version, owner and review date; old versions are archived, not deleted.

Archiving old versions lets a reviewer see which runbook an operator was following on a given date. The owner is responsible for reviewing it by the date shown, and the version number appears on every printed copy. The removable media runbook's first version is kept even after the kit drive location was added. The review date is set for six months after each version is published.

16.7 Testing documents

A colleague who did not write the runbook follows it on a lab PC; every point of confusion becomes an edit.

The colleague works on a lab PC rather than a ward PC, so a confusing step causes no harm. Every hesitation is noted and becomes an edit, then the colleague repeats the test. The test in the worked example found the missing kit drive location, which would have delayed a real response. The re-test after the edit is recorded with the colleague's name and date.

Templates

Standard templates for case notes, collection logs, verification tables and handover forms mean every operator records the same fields. A missing field is visible at a glance, and reviewers spend time on content rather than layout. Templates are stored with the runbooks and follow the same version control.

Worked example

Sana's runbook "Removable media incident — ward PC" is tested by a colleague, who stalls at "collect triage" because the kit drive location is missing. Sana adds "Kit drive KIT-02, security office safe, sign-out sheet" and re-tests successfully.

Synthetic case. The runbook test is invented.

Errors and limits

Documents cannot cover every situation; they should say when to stop and escalate.

Exercises

Synthesis

Write for the reader, place warnings before steps, protect patient data and test documents with colleagues.

Continue studying — chapter 16 of 18

← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →