Chapter 17 — Case-management and evidence-storage tooling
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes and connection"]
N1["17.1 Case-management requirements"]
N2["17.2 Evidence store requirements"]
N3["17.3 Custody in practice"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["17.1 Case-management requirements"]
N2["17.2 Evidence store requirements"]
N3["17.3 Custody in practice"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[Learning outcomes and connection]
|
v
[17.1 Case-management requirements]
|
v
[17.2 Evidence store requirements]
|
v
[17.3 Custody in practice]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes and connection
You will be able to (1) select or configure a case-management tool that implements the Chapter 4 data model; (2) set up an evidence store with integrity, custody and access controls; and (3) write acceptance criteria for both. Chapters 14–16 showed how cases are run; this chapter provides the tools that hold them.
17.1 Case-management requirements
Requirements follow from the data model and the service: structured fields with enumerations; required fields by status; links between cases, events, artefacts, actions and decisions; task assignment with due times; an immutable activity history (who changed what, when); role-based access with case-level restriction for sensitive cases (HR, insider); search and export; and an API for automation (Chapter 22). Fernmoor compared an open-source incident platform, a module of its existing IT service-management tool and a spreadsheet; the spreadsheet failed on history, access control and required fields.
17.2 Evidence store requirements
The evidence store holds preserved artefacts: log exports, images, memory captures, screenshots, emails. Requirements: storage separate from production administration; write-once or versioned storage; SHA-256 hashing on ingest (FIPS 180-4) and periodic verification; a custody record for each item (who collected, when, from where, every transfer and access); restricted and logged access; retention aligned with records and legal policy; and capacity for large images. ISO/IEC 27037 and NIST SP 800-86 describe the identification, collection, acquisition and preservation steps that this store supports. Fernmoor's store passed most acceptance tests but initially logged access with a 60-minute delay.
17.3 Custody in practice
For most internal cases, a well-kept digital custody log is enough: item id, description, source, collector, time, hash, storage location, and each access with purpose. If a case may go to court or a regulator, involve counsel early; stricter procedures may apply. Fernmoor's evidence store records most of this automatically: the hash on ingest and each access appear without manual entry, leaving the analyst to add the description, source and purpose. Cases involving staff, such as FCS-214, also record that the interview was arranged with the manager. Where an item leaves the store for a case, the transfer and its new hash are logged as a new custody entry.
17.4 Worked example (synthetic): acceptance testing the tools
Fictional. Fernmoor chose the ITSM module with a security-incident record type plus an object-storage bucket in a separate cloud account for evidence. Acceptance criteria and results:
| Criterion | Test | Result |
|---|---|---|
| Severity required at triage | move test case to triage without severity | blocked — pass |
| HR cases restricted | analyst outside HR group opens HR test case | denied, attempt logged — pass |
| History immutable | admin edits a closed case field | change recorded in history — pass |
| Evidence write-once | delete test artefact with response role | denied by object lock — pass |
| Hash on ingest | upload test file, compare stored hash with local | match — pass |
| Access logged | download artefact | access log entry within 5 min — fail (60 min delay) |
The failing criterion was accepted with a documented risk and a fix date; the go-live note recorded it.
17.5 Common errors and limits
- Evidence on analysts' laptops or shared drives.
- Hashes computed but never verified again.
- Case tools whose administrators can silently edit history.
- Choosing a tool for features rather than tested acceptance criteria.
Fernmoor's acceptance tests targeted each of these. Object lock made deletion by a response role fail, the stored hash was compared with a local hash on ingest, and editing a closed case field left a history entry. The one failing criterion, the access-log delay, was accepted with a documented risk and a fix date, which is the honest way to go live with a known gap. Periodic hash verification is on the sustainment calendar.
Exercises — chapter 17
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX049 — Requirements list. Steps: list eight must-have requirements for the case tool, each traceable to a chapter. Rubric: 3 = eight traceable requirements; 2 = six; 1 = generic; 0 = none.
EX050 — Custody log. Steps: write custody entries for a memory capture from permit-app-2 from collection to analysis. Rubric: 3 = collection entry with hash, transfer to store, each access with purpose and person, verification; 2 = missing accesses; 1 = one line; 0 = none.
EX051 — Failed criterion. Steps: write the risk-acceptance note for the access-log delay. Rubric: 3 = description, impact, compensating control, owner, fix date, approver; 2 = missing compensating control; 1 = vague; 0 = none.
Chapter synthesis
Choose tools by tested acceptance criteria derived from your data model and service: structured, access-controlled, history-preserving case records and a separate, write-once, hashed and logged evidence store with custody records.
Continue studying — chapter 17 of 30
← Chapter 16 · Course chapter index · Chapter 18 →
Continue to the next authored lesson.