◇ OpenCyber Academy
Engineering · Chapter 27 · English

Chapter 27 — Digital forensics and malware analysis: control design

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 27 — Digital forensics and malware analysis: control design

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Control types"]
  N2["27.2 Write protection"]
  N3["27.3 Separation of duties"]
  N4["27.4 Verification controls"]
  N5["27.5 Control evidence"]
  N6["27.6 Exceptions"]
  N7["27.7 Monitoring"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Control types"]
  N2["27.2 Write protection"]
  N3["27.3 Separation of duties"]
  N4["27.4 Verification controls"]
  N5["27.5 Control evidence"]
  N6["27.6 Exceptions"]
  N7["27.7 Monitoring"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Control types]
    |
    v
[27.2 Write protection]
    |
    v
[27.3 Separation of duties]
    |
    v
[27.4 Verification controls]
    |
    v
[27.5 Control evidence]
    |
    v
[27.6 Exceptions]
    |
    v
[27.7 Monitoring]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) design preventive, detective and corrective controls for EvidenceDesk; (2) apply separation of duties; (3) design write protection; (4) define control evidence.

27.1 Control types

Preventive controls stop errors (blocking examination of unverified copies). Detective controls reveal them (hash chain verification of the custody log). Corrective controls restore correct state (restoring from offline backup).

A sound design uses all three. Preventive controls reduce how often problems occur, detective controls catch the ones that get through, and corrective controls restore a known good state. Priya lists EvidenceDesk's controls under each heading, and the list shows that ransomware has only a corrective control so far. She adds a detective one: alerting when many records change in a short time.

27.2 Write protection

At acquisition, hardware write blockers prevent the examiner's workstation from changing the source. NIST's CFTT programme publishes test results for write-blocking devices. EvidenceDesk records the blocker model and serial with each acquisition.

Recording the blocker's model and serial number lets the lab show that a tested device was used, and trace every acquisition made with a unit if a fault is found later. Blockers are also checked periodically on a test drive, by attempting a write and confirming it fails. The check results are kept with the device record, so its history is available if it is ever questioned.

27.3 Separation of duties

The person who administers the server cannot approve their own record corrections; a second person reviews. Examiners cannot delete records at all.

Corrections are entered by one person and approved by another, and the system refuses approval by the person who entered them. Because examiners cannot delete records, a mistaken entry stays visible with its correction beside it. If the lab is too small for full separation at some point, the exception is documented and an external reviewer checks the affected period later.

27.4 Verification controls

Working copies are verified at creation and again before reporting; a final mismatch blocks report export.

Verifying again before reporting catches corruption that occurred during examination, such as a storage fault or an accidental write by a tool that should have been read-only. If the final check fails, the report cannot be exported until the cause is found and the affected findings are re-examined from a fresh, verified copy. Both checks record the digest computed, the expected digest, the time and the examiner, so the report can state that the exhibit matched its acquisition at the point of export. That statement is printed in the report's integrity appendix.

27.5 Control evidence

Each control produces evidence that it ran: verification log entries, chain checks with dates, backup restore tests. Auditors check the evidence, not just the design.

An auditor might choose three random dates and ask for the chain-check result, the list of verifications performed and the most recent backup restore before each one. If the records exist and agree, the controls are shown to work. Missing evidence is treated as a control failure, even if the control probably ran, because 'probably' cannot be defended to an outside reviewer.

27.6 Exceptions

Sometimes a control must be bypassed — an urgent court order when the server is down. The exception path requires a reason, an approver and a later reconciliation entry.

The exception form records what was done instead, for example a handwritten custody sheet used during an outage, who approved it and when normal operation resumed. Reconciliation enters the paper events into EvidenceDesk, marked as back-entered, with a scan of the original sheet. The quality manager reviews all exceptions monthly to spot patterns that suggest a control is impractical.

27.7 Monitoring

A daily job verifies the custody chain and reports results to the quality manager.

The report lists how many records were checked, whether the chain was intact, any items stuck in incomplete states and verification failures in the past day. A clean report is still sent, so silence clearly means the job did not run. Two consecutive missing reports trigger an alert to IT, because a monitor that fails without anyone noticing gives false comfort. Monthly summaries go to the lab manager as well.

Training as a control

Controls fail when staff do not understand them. Every examiner completes a short session on EvidenceDesk's blocking rules and exception path, and the quality manager records attendance as control evidence.

Worked example

During testing, an administrator corrects a typo in an item description directly in the file. The daily chain check flags a broken link from that entry onward. Priya's response: restore the file, and add the correction properly through the append-only path with review.

Synthetic case. The incident is invented.

Errors and limits

Controls that are inconvenient get bypassed; design exception paths that are recorded rather than forbidden.

Exercises

Synthesis

Layer preventive, detective and corrective controls, record their evidence, and design honest exception paths.

Continue studying — chapter 27 of 50

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →