Chapter 49 — Engineering thesis | 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 49 — Engineering thesis

Lesson map

Lesson 49 published. Map, example, EX145.

flowchart TD
  N0["Learning outcomes"]
  N1["49.1 Structure"]
  N2["49.2 Background done well"]
  N3["49.3 Contribution"]
  N4["49.4 Discussion"]
  N5["49.5 Limitations"]
  N6["49.6 Future work"]
  N7["49.7 Writing style"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX145"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["49.1 Structure"]
  N2["49.2 Background done well"]
  N3["49.3 Contribution"]
  N4["49.4 Discussion"]
  N5["49.5 Limitations"]
  N6["49.6 Future work"]
  N7["49.7 Writing style"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX145"]

[Learning outcomes]
    |
    v
[49.1 Structure]
    |
    v
[49.2 Background done well]
    |
    v
[49.3 Contribution]
    |
    v
[49.4 Discussion]
    |
    v
[49.5 Limitations]
    |
    v
[49.6 Future work]
    |
    v
[49.7 Writing style]
    |
    v
[Worked example] --> [Exercise EX145]

Learning outcomes

You will (1) write an engineering thesis on a forensic system; (2) present design, evidence and evaluation coherently; (3) discuss contribution and limits; (4) cite standards and literature correctly.

49.1 Structure

Introduction (Northfield's problem); background (forensic process standards, integrity, custody); requirements; design; implementation; verification and validation; pilot evaluation; failure trial; discussion; conclusion; appendices referencing the dossier.

The order follows the engineering life cycle, so a reader can see how each stage built on the last. Background comes before requirements because the standards and integrity concepts shape what the lab needs. Discussion is separate from results so that interpretation does not blur measured facts. Appendices point to dossier items by identifier rather than repeating them, keeping the main text readable at around sixty pages.

49.2 Background done well

Priya explains the standards briefly and accurately: ISO/IEC 27037 for identification, collection, acquisition and preservation; 27041 for method assurance; 27042 for analysis and interpretation; 27043 for investigation processes; NIST SP 800-86 for integrating forensics into incident response. She cites Carrier (2005) and Casey (2011) for foundations.

Briefly means each standard gets a paragraph on what it covers and why it matters to EvidenceDesk, not a summary of its full contents. Accurately means using the standards' own scope, for example not presenting 27037 as covering analysis. Priya resists citing everything she read; each source appears because a later design decision depends on it, and the background ends by naming the gap her project addresses.

49.3 Contribution

An offline, auditable intake and integrity system with tamper-evident custody, validated and piloted in a regional lab, with measured improvement in record completeness.

Each word in the statement does work: offline reflects the lab's security constraint, auditable reflects the standard-library code, tamper-evident reflects the chain and anchoring, validated and piloted reflect the evidence gathered. The measured improvement anchors the claim in data. Priya avoids words like 'novel' or 'first', since hash chains and custody systems exist elsewhere; the contribution lies in the combination applied and tested in a real lab.

49.4 Discussion

Why blocking verification succeeded where policy alone did not; why anchoring placement matters; what other labs would need to adapt.

Policy had required verification before examination for years, yet paper records showed it was sometimes skipped under pressure. Making the system refuse to proceed removed the choice, which explains the pilot's result better than staff attitudes alone. The anchoring finding shows how a sound design can be undone by its configuration. For other labs, Priya lists what would transfer directly and what would need local work, such as imager parsers.

49.5 Limitations

One lab, three-month pilot, observation effects, synthetic validation data, a single independent reviewer.

Each limitation is matched to what it could distort. A single lab might have unusual practices; a short pilot might miss slow problems; observation might make staff more careful than usual; synthetic data might lack the oddities of real seizures; one reviewer might miss what a second would catch. Stating these plainly lets readers judge how far to trust and apply the results to their own settings.

49.6 Future work

Integration with mobile acquisition tools under SP 800-101r1 practices; multi-lab study; formal verification of chain logic.

Mobile devices are now a large share of seized items, and their acquisition tools produce different logs and formats, so integration is a natural next step. A multi-lab study would address the single-lab limitation directly. Formal verification would use mathematical proof to show the chain logic always detects certain kinds of change, rather than relying only on the tests run. Each item is tied to a limitation or finding in the thesis.

49.7 Writing style

Results in numbers; claims linked to dossier items; no "proves" where the evidence "shows".

'Proves' implies certainty that a three-month pilot cannot give; 'shows' or 'suggests' matches the strength of the evidence. Numbers let readers judge size: '17 of 198 items' says more than 'many items'. Linking claims to dossier items lets an assessor check any sentence. Hugo's advice is that a reader should never have to trust Priya's adjectives when they could check her figures instead. Tables carry units and dates throughout the text.

49.8 Ethics statement

No casework evidence used; survey ethics approval reference; confidentiality respected.

The statement is short because the project was designed to avoid ethical problems rather than manage them afterwards. It names the approval body and reference so assessors can confirm the survey was approved. It explains that all evidence-handling tests used synthetic items and that staff took part only through anonymous survey responses and normal work records, used with the lab manager's written permission. It also confirms that no participant can be identified from the published results.

Abstract

The abstract states the problem, the system, how it was validated, the key pilot numbers and the main limitation in under 250 words. Priya writes it last, after the results are fixed, and checks every number in it against the dossier so the abstract never says more than the thesis supports. A colleague outside forensics reads it to confirm it is understandable.

Worked example

A draft conclusion said EvidenceDesk "guarantees evidence integrity". Priya revises: "EvidenceDesk detects alteration of acquired images and custody records and blocks examination of unverified copies; it cannot detect errors made before acquisition."

Synthetic case. The thesis text is invented.

Errors and limits

A thesis is judged on argument as well as results; connect each chapter to the question.

Exercises

EX145 — Standards summary. Match 27037, 27041, 27042 and 27043 to their topics. Rubric: 3 = all four correct; 2 = three; 1 = one; 0 = none.
EX146 — Conclusion rewrite. Why replace "guarantees evidence integrity"? Rubric: 3 = overclaims; system detects/blocks, cannot see pre-acquisition errors; 2 = partial; 1 = style; 0 = none.
EX147 — Future work. Name two future work items. Rubric: 3 = mobile acquisition integration, multi-lab study (or formal verification); 2 = one; 1 = vague; 0 = none.

Synthesis

A strong engineering thesis ties standards, design, evidence and evaluation into a bounded contribution.

Continue studying — chapter 49 of 50

← Chapter 48 (draft) · Course chapter index · Chapter 50 (draft) →