◇ OpenCyber Academy
Engineering · Chapter 42 · English

Chapter 42 — Digital forensics and malware analysis: applied research

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 42 — Digital forensics and malware analysis: applied research

Lesson map

Lesson 42 published. Map, example, EX124.

flowchart TD
  N0["Learning outcomes"]
  N1["42.1 The question"]
  N2["42.2 Literature"]
  N3["42.3 Design"]
  N4["42.4 Results"]
  N5["42.5 Interpretation"]
  N6["42.6 Recommendation"]
  N7["42.8 Sharing"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX124"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["42.1 The question"]
  N2["42.2 Literature"]
  N3["42.3 Design"]
  N4["42.4 Results"]
  N5["42.5 Interpretation"]
  N6["42.6 Recommendation"]
  N7["42.8 Sharing"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX124"]

[Learning outcomes]
    |
    v
[42.1 The question]
    |
    v
[42.2 Literature]
    |
    v
[42.3 Design]
    |
    v
[42.4 Results]
    |
    v
[42.5 Interpretation]
    |
    v
[42.6 Recommendation]
    |
    v
[42.8 Sharing]
    |
    v
[Worked example] --> [Exercise EX124]

Learning outcomes

You will (1) frame an applied research question from engineering work; (2) design a small study; (3) relate findings to literature; (4) report bounded conclusions.

42.1 The question

During the pilot, Priya noticed that verification failures cluster on images copied over the network rather than by direct attachment. Question: do network-copied working copies fail verification more often than locally made ones at Northfield, and why?

A good applied question is narrow enough to answer with data the lab already holds and useful enough that the answer could change practice. Priya's version names the comparison, the place and the outcome measure, and adds 'why' so the study looks for causes rather than stopping at a rate. Hugo asks her to state in advance what result would lead to no change at all.

42.2 Literature

She searches for studies of silent data corruption in storage and transfer, and forensic guidance on copy verification. NIST SP 800-86 stresses verifying the integrity of copies; she also finds engineering literature on undetected errors in storage systems.

Reading first shows whether the question has been answered elsewhere and what methods others used. Studies of large storage systems report that corruption which no component detects does occur, though rarely, which supports verifying copies even when the copy tool reports success. Priya notes where those studies differ from Northfield's setting, such as scale and hardware, so she does not overstate their relevance.

42.3 Design

Six months of pilot records: copies by method (network or local), verification outcome, cause found on investigation. No personal data; only system records.

Using existing records makes this an observational study: Priya cannot assign copies to methods at random, so other differences between network and local copies, such as image size, could affect the results. She records image size for each copy so it can be checked later. The cause column comes from the investigation notes written at the time, not from her own reinterpretation afterwards.

42.4 Results

Network copies: 6 failures in 1,200. Local copies: 1 in 1,100. Investigation attributes five of the network failures to interrupted transfers that the copy tool reported as complete, and one to a faulty switch port.

As rates, network copies failed in 0.5 percent of cases and local copies in about 0.09 percent. The investigation notes matter as much as the counts: a tool reporting success after an interrupted transfer is a specific, fixable fault, and it explains most of the gap. The local failure was traced to a disk with growing bad sectors, which was replaced.

42.5 Interpretation

The data suggest a higher failure rate for network copies at Northfield, mainly from interrupted transfers. Verification caught every case before examination — the control worked.

Priya avoids claiming that network copying is unsafe in general; the evidence points at one tool's behaviour on interruption and one piece of hardware. The more important finding is that the blocking verification did its job every time, so no examination relied on a bad copy. That turns a worrying number into a reassuring one about the overall design.

42.6 Recommendation

Use a copy tool that verifies on completion, keep blocking verification, and replace the faulty port.

Each recommendation targets a cause found in the data. The copy tool change addresses the five interrupted transfers; replacing the port addresses the sixth. Keeping blocking verification is deliberately listed too, because a manager seeing improved copying might ask whether verification is still needed. A follow-up review after six more months will check whether failures drop. Priya estimates the cost of each change, which is small for all three, so the manager can approve them together.

42.7 Limits

One lab, six months, small counts: the difference is suggestive, not precise.

With only seven failures in total, a few extra in either group would change the picture noticeably. Six months may also miss seasonal effects, such as heavier network load at year end. Priya writes the limits next to the results rather than at the end of the note, so a reader skimming the numbers meets the caveats at once. She suggests that a multi-lab study with a year of data would be needed before anyone quotes a general failure rate.

42.8 Sharing

Priya writes a two-page note for regional labs, stating counts and limits.

Other regional labs use similar copy tools and may have the same fault without knowing it. The note gives the tool name and version, how the interruption showed up, and how verification caught it, but no case details. Priya invites labs to send their own counts so a larger, combined picture can be built over time. Before release, Hugo reads the note to check that no wording could identify a case or a member of staff.

Data access approval

Even system records need permission. Priya asks the lab manager in writing to use six months of verification logs, stating purpose and that no case content will be read.

Worked example

Her first draft says "network copying is unsafe". Hugo asks what the data show. Revised: "At Northfield, network copies failed verification at 0.5% versus 0.09% for local copies over six months; all failures were caught by verification before examination."

Synthetic case. The records are invented.

Errors and limits

Observational data cannot rule out confounders, such as larger images being copied over the network more often.

Exercises

Synthesis

Engineering operations generate research questions; answer them with bounded, counted claims.

Continue studying — chapter 42 of 50

← Chapter 41 (draft) · Course chapter index · Chapter 43 (draft) →