Chapter 11 — Applied project
Lesson map
Lesson 11 published. Map, example, EX051.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Project choice"]
N2["11.2 Baseline"]
N3["11.3 Design"]
N4["11.4 Implementation"]
N5["11.5 Evaluation"]
N6["11.6 Side effects"]
N7["11.7 Reporting"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX051"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Project choice"]
N2["11.2 Baseline"]
N3["11.3 Design"]
N4["11.4 Implementation"]
N5["11.5 Evaluation"]
N6["11.6 Side effects"]
N7["11.7 Reporting"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX051"]
[Learning outcomes]
|
v
[11.1 Project choice]
|
v
[11.2 Baseline]
|
v
[11.3 Design]
|
v
[11.4 Implementation]
|
v
[11.5 Evaluation]
|
v
[11.6 Side effects]
|
v
[11.7 Reporting]
|
v
[Worked example] --> [Exercise EX051]
Learning outcomes
You will (1) run a postgraduate applied project in a forensic unit; (2) design, implement and evaluate an improvement; (3) involve stakeholders; (4) report results to leadership.
11.1 Project choice
From the CF-21 review, Marta chooses: "Reduce time from detection to forensic preservation for significant hosts from a median of 3.5 hours to under 1 hour." The target is specific and measurable, and it comes directly from the CF-21 failures: two servers rebuilt before preservation and hours lost before memory capture. The 3.5-hour median meant the evidence most needed was often gone. Reducing it to under one hour would make the forensic gate's 90-minute limit realistic. Marta writes the objective with the COO and the IT and SOC leads before design begins.
11.2 Baseline
Records from CF-21 and three smaller incidents give the baseline: median 3.5 hours, longest 7 hours, two hosts lost to rebuild. The baseline draws on four incidents rather than CF-21 alone, which gives more than one data point. It records the median and the longest time, and the two hosts lost, so improvement can be shown against all three. The same measurement method is used after rollout so the comparison is fair. The baseline records and the method used to time each preservation are kept in the project file for review.
11.3 Design
Pre-deployed memory and triage collection on servers and admin workstations; automatic VM snapshot on high-severity alert; on-call forensic rota; forensic gate in IT change process. Each element removes a delay that the CF-21 timeline showed. Pre-deployed tools avoid waiting for software installation, automatic snapshots remove the race with IT, the on-call rota ensures someone can act at night, and the gate in IT's change process stops rebuilds of significant hosts. Together they target both the median and the lost hosts.
11.4 Implementation
Changes roll out over eight weeks with IT and SOC. Each change has a test: a simulated alert should trigger snapshot within five minutes. The eight weeks allow each change to pass normal change control and be tested before the next one goes in. The five-minute snapshot test is run on each cluster, and failures go back to the owning team. Rolling out gradually also means a problem can be traced to a single change. Each test result is kept with the change ticket, so the evaluation can cite it.
11.5 Evaluation
Two technical exercises and one real minor incident after rollout: median preservation time 40 minutes; no significant hosts rebuilt before preservation. A median of 40 minutes beats the target of under one hour, and the lost-host count fell from two to none. The evidence base is small, three events, so Marta reports the result as promising rather than proven. Measurement continues through real incidents, and the figure will be updated in the next board report. The three events are listed individually in the project file, so the median can be checked.
11.6 Side effects
Snapshot storage grew 30%; a retention rule deletes non-case snapshots after 14 days. Storage growth was a real cost that the board needed to see beside the benefit. Without the 14-day rule, automatic snapshots would accumulate on every high-severity alert, including false positives. Snapshots linked to a case are kept under that case's retention instead. The 14-day rule is tested like the other changes, by checking that a non-case snapshot older than 14 days is removed and a case snapshot is kept. Marta treats storage growth as a figure to keep watching.
11.7 Reporting
A two-page report to the board: problem, change, results, costs, limits. The two pages state the 3.5-hour baseline, the changes, the 40-minute median from three events, the 30% storage growth and the cluster permissions failure. Limits include the small number of events and the absence of a large incident since rollout. Board members get enough to judge the investment without reading the full project file. The failed snapshot test is described with its cause and fix. The board can see that the team found the problem through its own testing.
Stakeholder involvement
IT operations and the SOC co-own the project. Their leads join planning and evaluation, and each change is approved through normal change control. Marta credits their staff in the report; the project worked because the people who rebuild systems helped design the gate that sometimes delays them. A short survey after rollout records their view of the new process alongside the timing data.
Worked example
During the second exercise, the automatic snapshot fails on one cluster because of a permissions change made by another team. The test catches it; the permission is restored and a monitoring check added. Marta reports the failure and fix in the board paper, not just the headline result.
Synthetic case. The project is invented.
Errors and limits
Three events after rollout are few; continue measuring through real incidents.
Exercises
- EX051 — Objective. State the project objective with baseline. Rubric: 3 = 3.5 h median to under 1 h; 2 = partial; 1 = vague; 0 = none.
- EX052 — Design elements. List three design elements. Rubric: 3 = pre-deployed collection, auto snapshot, on-call rota, forensic gate (any three); 2 = two; 1 = one; 0 = none.
- EX053 — Result. What did evaluation show? Rubric: 3 = median 40 min; no premature rebuilds; 2 = one; 1 = vague; 0 = none.
- EX054 — Side effect. What side effect occurred and how was it managed? Rubric: 3 = 30% storage growth; 14-day deletion rule; 2 = one; 1 = vague; 0 = none.
- EX055 — Reporting failure. Why include the snapshot failure in the board report? Rubric: 3 = honesty; shows testing works; risk visibility; 2 = partial; 1 = omit; 0 = none.
Synthesis
Applied projects need baselines, tested changes, honest evaluation and attention to side effects.
Continue studying — chapter 11 of 12
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →