Chapter 28 — Field practice | Technologist 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 28 — Field practice

Lesson map

Lesson 28 published. Map, example, EX082.

flowchart TD
  N0["Learning outcomes"]
  N1["28.1 Placement"]
  N2["28.2 Real alerts"]
  N3["28.3 Boundaries"]
  N4["28.4 Confidentiality"]
  N5["28.5 A real-looking case"]
  N6["28.6 Lessons"]
  N7["28.7 Reflection"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX082"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["28.1 Placement"]
  N2["28.2 Real alerts"]
  N3["28.3 Boundaries"]
  N4["28.4 Confidentiality"]
  N5["28.5 A real-looking case"]
  N6["28.6 Lessons"]
  N7["28.7 Reflection"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX082"]

[Learning outcomes]
    |
    v
[28.1 Placement]
    |
    v
[28.2 Real alerts]
    |
    v
[28.3 Boundaries]
    |
    v
[28.4 Confidentiality]
    |
    v
[28.5 A real-looking case]
    |
    v
[28.6 Lessons]
    |
    v
[28.7 Reflection]
    |
    v
[Worked example] --> [Exercise EX082]

Learning outcomes

You will (1) apply skills during a supervised field placement; (2) respond to real alerts under supervision; (3) keep professional boundaries; (4) reflect on practice.

28.1 Placement

Jonah spends twelve weeks with Alder Falls IT, half in operations, half shadowing Renata.

Splitting the placement lets Jonah see both sides of the work he has studied: in operations he handles the tickets, changes and routine maintenance where evidence is often lost, and with Renata he sees how that evidence is used in analysis. Each week ends with a short meeting where his supervisor reviews his log and sets goals for the next week. The placement agreement names his supervisor, his permitted tasks and the systems he may touch.

28.2 Real alerts

He helps triage alerts under supervision, using the kit and runbooks. Most alerts are benign; each is closed with a reason.

Triage under supervision means Jonah proposes and Renata or an operations colleague approves before any action on a live system. Closing each alert with a reason builds a record that helps tune the rules: if many alerts close as the same benign cause, the rule needs adjusting. Jonah learns that a well-recorded benign closure is as valuable to the team as an escalation, because it saves the next analyst from repeating the same checks.

28.3 Boundaries

Jonah handles city systems only under the city's authority; he does not access personal devices or residents' data beyond what a task requires, and never alone.

Authority comes from the city, not from Jonah's skills or curiosity. He works only on tasks assigned within his placement agreement, and when a task would touch personal data, such as checking an export's contents, a city employee is present and the access is recorded. If he is unsure whether something is within scope, he asks first and notes the answer in his placement log.

28.4 Confidentiality

Placement details stay within the city; his course reports use only synthetic or anonymised examples approved by Renata.

The city's systems, staff and incidents are not material for coursework without permission. Jonah writes his course reports using the synthetic Alder Falls case or examples Renata has approved and stripped of identifying details. This protects residents and staff, and it also protects Jonah: he cannot be accused of disclosing information he was trusted with during the placement. Drafts are shown to Renata before submission.

28.5 A real-looking case

A server alert flags a new service on the GIS server. Jonah follows the runbook: notify Renata, capture memory, collect triage, compare with baseline. The service belongs to a mapping software update installed by the vendor overnight; the change record had been filed late.

Following the runbook even when the cause turned out to be benign was correct: at the moment of the alert, nobody knew it was a vendor update. The baseline comparison and the late change record together explained the new service. Jonah records the case fully, including the time spent, because it shows the cost of change records that arrive after the work rather than before.

28.6 Lessons

The false alarm reveals a process gap: vendor changes must be recorded before work, so analysts can check quickly.

The gap is a process one, not a technical one. If vendor changes are recorded before work starts, an analyst can match a new service against the change calendar in minutes instead of capturing memory and collecting triage data. Jonah proposes that vendor remote sessions be allowed only against an approved change record, and the IT manager adds it to the vendor contracts review.

28.7 Reflection

Jonah's weekly log notes skills gained and mistakes made, such as forgetting to record the USB serial on one collection.

Recording mistakes honestly is part of the learning, and it builds trust with the supervisor. The forgotten serial was minor and recoverable from the kit register, but noting it led to a lasting change in practice: reading the checklist aloud. Jonah's log also records what went well, so the reflection shows growth over the twelve weeks rather than only errors.

Working with vendors

Vendors support several city systems remotely. Jonah learns to check vendor access logs and change records during triage, and to ask vendors factual questions through the IT manager rather than directly, keeping communication consistent and recorded. When a vendor engineer offers to "just look" at an alert, Renata declines politely and shares only the facts needed.

Worked example

His reflection: "I forgot to record the kit drive serial during the GIS collection. Renata caught it in review; we added it from the kit register and noted the late entry. I now read the checklist aloud during collection."

Synthetic case. The placement is invented.

Errors and limits

A placement shows one organisation's practice; others will differ.

Exercises

EX082 — GIS alert. What was the GIS alert's cause? Rubric: 3 = vendor update, late change record; 2 = partial; 1 = malware; 0 = none.
EX083 — Process gap. What process gap did it reveal? Rubric: 3 = vendor changes must be recorded before work; 2 = partial; 1 = vague; 0 = none.
EX084 — Serial mistake. How was the missing serial handled? Rubric: 3 = caught in review; added from register with late-entry note; checklist read aloud; 2 = partial; 1 = ignored; 0 = none.

Synthesis

Supervised field practice builds judgement, exposes process gaps and teaches honest correction of mistakes.

Continue studying — chapter 28 of 30

← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →