OpenCyber AcademyLesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 Brief"]
N2["25.2 Roles"]
N3["25.3 Design decisions"]
N4["25.4 Integration"]
N5["25.5 Peer review"]
N6["25.6 Presentation"]
N7["25.7 Feedback"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 Brief"]
N2["25.2 Roles"]
N3["25.3 Design decisions"]
N4["25.4 Integration"]
N5["25.5 Peer review"]
N6["25.6 Presentation"]
N7["25.7 Feedback"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 Brief]
|
v
[25.2 Roles]
|
v
[25.3 Design decisions]
|
v
[25.4 Integration]
|
v
[25.5 Peer review]
|
v
[25.6 Presentation]
|
v
[25.7 Feedback]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) work in a team to design a forensic triage kit; (2) divide work and integrate it; (3) review each other's work; (4) present a design to stakeholders.
25.1 Brief
Jonah's student team of four is asked by Alder Falls to design "Triage Kit 2": a documented, validated set of tools, scripts and procedures for first responders, building on lessons from the incident.
The brief comes from a real need: during the incident, nobody but Renata knew where the memory tool was or how to use it, and collection took about two hours. Triage Kit 2 is meant to let any trained first responder collect evidence correctly at any hour. The team writes the brief's success conditions at the start, such as collection completed by a non-specialist from the printed procedure alone, so the final design can be judged against them rather than against the team's own sense of progress.
25.2 Roles
Jonah: manifest and verification scripts. Priya-May: procedures and training materials. Kofi: tool validation on synthetic images. Lina: evidence store and custody records. Weekly integration meetings.
Each role has a clear output and a clear dependency on the others: the custody records need the manifest hash, the procedures need the validated tool versions, the training materials need the procedures. Weekly integration meetings exist because those dependencies break quietly when people work apart. Each member also keeps an individual log of tasks done and time spent, which supports fair assessment and shows the tutor who did which part of the work.
25.3 Design decisions
Standard library only for scripts; tools chosen from those with published validation or tested in-house; procedures printed and laminated; every output hashed and manifested.
Each decision is recorded with its reason in the decision log. Standard-library scripts avoid installing packages on machines that may hold evidence; validated tools mean the city can explain how each result was produced; laminated printed procedures work when screens are unfamiliar or a laptop is unavailable; hashing every output makes later verification possible. Recording reasons lets a future team change a decision knowingly instead of by accident, and it answers stakeholder questions without another meeting.
25.4 Integration
Lina's custody template must accept Jonah's manifest hash; Kofi's tests must cover the exact tool versions in Priya-May's procedures. Mismatches are logged and resolved.
Integration is where separate pieces of good work can fail together. A manifest hash in a format the custody template does not accept, or a procedure naming a tool version nobody tested, would break the kit in use even though each part looked correct on its own. The team logs each mismatch with the date, the people involved and the fix, so the same problem does not return in the next version of the kit.
25.5 Peer review
Each member reviews another's work against the brief and standards: ISO/IEC 27037 principles for procedures; test evidence for tools.
Reviewing against the brief and the standards keeps feedback specific: a reviewer asks whether a procedure preserves evidence and records each action, as ISO/IEC 27037 expects, or whether a tool's test covers the version listed. Comments are written down and answered, so the author can show what changed. Rotating reviewers spreads knowledge across the team and catches assumptions that one person shares with the author.
25.6 Presentation
The team presents the design to Renata and the IT manager with a live demonstration on a synthetic machine.
A live demonstration on a synthetic machine shows the stakeholders what using the kit actually looks like, including how long each step takes and where an operator might hesitate. Renata watches for evidence handling; the IT manager watches for effort and cost. The team prepares answers for likely questions, such as why the kit avoids third-party packages, from the decision log.
25.7 Feedback
The IT manager asks for a version usable by non-security staff at night; the team adds a one-page quick card.
Night-time responders are usually IT operations staff, not security specialists, and they need the essential steps on one page: who to call, what not to touch, how to capture memory and where to record times and hashes. The quick card is tested by someone outside the team before it is adopted, and its version is recorded with the rest of the kit.
Project management
The team keeps a simple board of tasks with owners and due dates, and a decision log. When Kofi falls ill for a week, the board shows exactly which validation tests remain, and Lina picks up two of them. The decision log later answers the IT manager's question about why the kit avoids third-party Python packages, saving a meeting.
Worked example
Integration testing shows Priya-May's procedure names a tool version Kofi had not validated. The team either validates that version or changes the procedure. They validate it, record results, and update both documents together.
Synthetic case. The team and project are invented.
Errors and limits
Team projects can hide uneven contributions; individual logs and peer assessments keep work visible.
Exercises
- EX073 — Roles. Name the four roles in the team.
Show marking criteria
Rubric: 3 = scripts, procedures, validation, evidence store/custody; 2 = three; 1 = one; 0 = none. - EX074 — Version mismatch. How was the tool version mismatch resolved?
Show marking criteria
Rubric: 3 = validated that version; updated both documents; 2 = partial; 1 = ignored; 0 = none. - EX075 — Quick card. Why was a quick card added?
Show marking criteria
Rubric: 3 = usable by non-security staff at night; 2 = partial; 1 = decoration; 0 = none.
Synthesis
Team design needs clear roles, integration checks, peer review and responsiveness to users.
Continue studying — chapter 25 of 30
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →