Chapter 21 — Digital forensics and malware analysis: requirements | Engineering Digital forensics and malware analysis

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 21 — Digital forensics and malware analysis: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Stakeholders"]
  N2["21.2 Functional requirements"]
  N3["21.3 Non-functional requirements"]
  N4["21.4 Linking to standards"]
  N5["21.5 Prioritisation"]
  N6["21.6 Acceptance criteria"]
  N7["21.7 Change control"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 Stakeholders"]
  N2["21.2 Functional requirements"]
  N3["21.3 Non-functional requirements"]
  N4["21.4 Linking to standards"]
  N5["21.5 Prioritisation"]
  N6["21.6 Acceptance criteria"]
  N7["21.7 Change control"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 Stakeholders]
    |
    v
[21.2 Functional requirements]
    |
    v
[21.3 Non-functional requirements]
    |
    v
[21.4 Linking to standards]
    |
    v
[21.5 Prioritisation]
    |
    v
[21.6 Acceptance criteria]
    |
    v
[21.7 Change control]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) elicit requirements from forensic stakeholders; (2) write functional and non-functional requirements; (3) prioritise them; (4) link them to standards.

21.1 Stakeholders

Examiners, the lab manager, the quality manager, IT staff, and indirectly prosecutors and defence experts who will scrutinise records. Priya interviews each group and reviews Northfield's procedures.

The interviews bring out different worries. Examiners fear extra typing that slows imaging. The quality manager wants proof that verification happened, not just a checkbox. IT staff ask who will patch an offline server. Defence experts, approached through a former practitioner, say they need to reconstruct custody without asking the lab for favours. Priya writes each concern as a candidate requirement and marks who raised it.

21.2 Functional requirements

FR1: register each item with a unique ID, description, seizing officer and time. FR2: record each acquisition with tool, version, hash algorithm, digest and examiner. FR3: verify a working copy's hash against the acquisition digest before allowing examination. FR4: keep a tamper-evident custody log of every transfer. FR5: export a custody and acquisition report for disclosure.

Each functional requirement names an observable behaviour rather than a feature. FR2, for instance, can be tested by registering an acquisition and checking that all five fields are stored and none can be left blank. Priya numbers requirements permanently, so FR3 stays FR3 even if the wording changes, and tests, defects and design notes can refer to it without ambiguity.

21.3 Non-functional requirements

NFR1: run offline. NFR2: standard-library code for auditability. NFR3: every record append-only. NFR4: hash a 1 TB image within the imaging window on current hardware.

NFR4 needs a figure to be testable. Northfield's imaging window is about four hours, so hashing 1 TB in that time means sustaining roughly 70 MB per second, which a modern workstation does easily for SHA-256. Priya measures it on the lab's oldest examination machine, because the requirement must hold on the slowest hardware still in use, not on the newest.

21.4 Linking to standards

FR1, FR2 and FR4 support the documentation and preservation principles in ISO/IEC 27037; FR3 supports integrity checks; FR5 supports disclosure and review. Each link is written in the requirements table.

The table has three columns: requirement, the principle it supports and how the link would be shown to an assessor. For FR4 the third column reads 'custody log hash chain; daily verification report'. Writing the link explicitly stops the system from claiming conformance with a standard in general terms, and shows assessors exactly where to look.

21.5 Prioritisation

MoSCoW labels: Must (FR1–FR4, NFR1, NFR3), Should (FR5, NFR4), Could (barcode scanning), Won't this year (automated analysis).

Automated analysis lands in Won't because it would draw EvidenceDesk into interpreting evidence, which belongs to examiners and validated tools. Barcode scanning is a Could: useful, but intake works without it. The labels guide what gets built first if time runs short. Priya revisits them only through change control, so priorities do not drift because of whoever asked most recently. Every Must has an acceptance test before coding starts.

21.6 Acceptance criteria

Each requirement gets a test: for FR3, "examination is blocked when a working copy's digest differs, and the block is logged".

Good acceptance criteria state the setup, the action and the expected result. For FR3 the setup is a working copy whose digest differs from the acquisition record, the action is requesting examination, and the expected result is a refusal plus a log entry naming the item, both digests and the user. Criteria written this way convert directly into automated tests.

21.7 Change control

New requests after sign-off go through review, with their impact on schedule and validation noted.

A late request to record photographs of seals at intake looks small, but it touches the data model, the intake screens, storage sizing and validation tests. The change record lists each of these, the estimated effort and whether the request moves a Must off schedule. The lab manager decides with that information in hand, and the decision is recorded with its reasoning. Rejected requests stay in the log with their reasons.

Traceability to interviews

Each requirement records which interview or document it came from. When the lab manager later questions FR4, Priya can show the three examiner interviews that raised it.

Worked example

The quality manager asks for "complete audit". Priya asks what she needs to show auditors; the answer is who changed what and when, for every record. That becomes NFR3 plus FR4, both testable.

Synthetic case. Stakeholder statements are invented.

Errors and limits

Requirements capture today's process; revisit them after a pilot.

Exercises

EX061 — FR3 test. Write the acceptance test for FR3. Rubric: 3 = mismatch blocks examination and is logged; 2 = partial; 1 = vague; 0 = none.
EX062 — Vague request. How did "complete audit" become testable? Rubric: 3 = asked need; became append-only records + custody log; 2 = partial; 1 = accepted vague; 0 = none.
EX063 — Won't list. Why put automated analysis in "Won't"? Rubric: 3 = outside scope, would complicate validation; 2 = partial; 1 = not useful; 0 = none.

Synthesis

Testable, prioritised requirements linked to standards are the foundation of EvidenceDesk.

Continue studying — chapter 21 of 50

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →