We’ve (D)evolved from Casework to Toolwork
DFIR training is fragmented, and fragmented training produces fragmented practitioners. And on top of that, we’ve turned artifacts and tools into a fetish, confusing output with understanding and “the tool says…” with a conclusion.
DFIR has never been smarter: we mapped bytes to the nth degree, reverse-engineered artifacts vendors pretend don’t exist, pulled history out of places we used to call “inaccessible,” and turned micro-evidence into something usable just in time for someone to look at all of it and say, “Cool… so what does the tool say?”
And in the middle of all that capability, in DF investigations, we drifted from the mission: casework. Not because tools got better. But because training stayed segmented, and segmented training tends to create segmented thinking.
Tool skills produce data. Casework produces defensible conclusions.
If your “conclusion” is “the tool says…”, you don’t have a conclusion yet. You have a starting point. And if you don’t know where to start and mostly stare at devices and data hoping for inspiration to hit, I created the course for you. In one day, you’ll practice sequencing decisions under constraints and defending conclusions under hostile questioning.
Placing the Suspect Behind the Keyboard: PSBK CASEWORK
Register here
Policing already lived this mistake
Years ago, a lot of use-of-force training was only taught in mini-modules: stance, grip, strikes, takedowns, cuffing, firearm drills, “if X then do Y” blocks. Each block is teachable and measurable on paper. Then on the street, you learn quickly that the memorized modules don’t function together.
Real use of force isn’t modular. It’s messy, fast, ambiguous, and full of judgment calls: distance changes, bystanders, lighting, footing, weapons, fear of getting killed, fatigue, policy constraints, legal constraints, litigation worries, all the while your body dumps stress chemicals into your bloodstream.
Segmented training can produce people who can perform isolated moves but struggle to sequence decisions under pressure. Scenario-based training didn’t replace skill training. It connects skill training to reality, like glue.
Not my first scenario-training rodeo
In 1998, I built a scenario-based use-of-force program for my police department using padded suits and Simunitions (non-lethal marking rounds). The following year, I published a book* on implementing an integrated approach (firearms + defensive tactics + decision-making) within an agency. I’m not claiming I invented scenario training. I’m saying I watched a profession learn the hard way: Specific skills without context don’t hold up when reality punches you in the face.
DFIR is still doing what policing used to do
DFIR training is also taught in slices: this artifact, that log source, this extraction method, that parsing technique, this tool feature, that reporting option.
At best, the instructor explains how the slice might matter with a brief case example. It’s rare to find an immersive, scenario-based training that begins at the event’s inception and continues through case presentation. Slice-training rarely trains the parts that break people, or break cases, in the real world:
- what comes first vs what can wait
- what changes the plan
- what’s missing and what that implies
- alternative hypotheses and exclusion
- conclusions that survive hostile questioning
- real-world vs idealism and theory
Even courses with “investigation” in the title often mean “investigation of a thing” (an app, an artifact class, one technique), but not how to run an investigation end-to-end, ie: casework, beyond only doing ‘forensics.’
So, we create practitioners who can describe what the machine did and then freeze when it’s time to explain who did what, why it matters, how we know, and how we defend it when challenged.
Even the most experienced practitioners, unless they’re forced through a real scenario with debriefs and hard conversations about consequences, will stay that last sliver away from their best.
That’s not a tool problem. That’s a casework problem.
If DFIR were a city today…
It would be full of skyscrapers labeled Tool Training, Processing, Artifacts, and the two neglected houses out at the edge of town would be Casework and Attribution.
“But we do CTFs and tabletops”
Good. Keep doing them. They can be useful. But don’t confuse them with casework training unless they’re deliberately designed to be that.
CTFs
CTFs often reward speed against your peers, cleverness in finding unrealistic clues, pattern recognition, and “find the answer in a race.” Many also contain intentional breadcrumbs because the goal is learning and solvability. Going into a CTF usually assumes that the data in a CTF always holds the answer. This is not real life.
Tabletop exercises
Many tabletops help with roles, coordination, escalation, and communication. Useful. But most don’t force the rough parts that make or break real case outcomes, like incomplete data, misleading artifacts, tool failure modes, decision gates with consequences, or defensible reasoning under scrutiny
So yes, CTFs and tabletops are helpful for sharpening skills. They just aren’t a substitute for full-case scenario-based training. (And scenario-based learning has research support in cybersecurity education for exactly this reason: it forces applied judgment, not just recall.)
There is a difference between artifact analysis and case building
There’s a difference between artifact analysis and case building. Somewhere along the way, the “artifact” became the “case.”
We’re mistaking brick inspection for house building: every brick under a microscope, every timestamp debated like theology, and a whole industry of increasingly elaborate tools built to study individual bricks.
But the job isn’t just brick inspection. The job is to build the house using artifacts to support a coherent, defensible story. Artifacts are evidence. They are not the story.
The objective of minute inspection of artifacts is to use it to build a case, not just examine the artifacts.
Artifacts can be incomplete, spoofed, manipulated, corrupted, planted, or misunderstood. Tools can parse incorrectly. Defaults can hide what matters. Reports can look professional while being dangerously incomplete. And worse: your interpretation can be wrong.
The nightmare case scenario (this is where exposure happens)
You find the “smoking gun” artifact. You write it up. Everyone nods. Then the important questions get asked:
“Walk me through your decision-making. Why did you start where you started? What did you rule out? What else could explain this? What would change your mind?”
If you can’t explain sequencing, constraints, and exclusion in plain language, the dozen overlapping ways of how you determined USB insertion may have occurred don’t save you. Not because you’re dumb. Because you were trained in slices.
I’ve been doing casework for more than 30 years. I’ve made more mistakes than I can remember, but I remember enough of them to know exactly where cases are attacked and “good work” turns into an unforced error. That’s why PSBK CASEWORK exists. Learn from my mistakes to avoid making the same ones (but don’t worry, you’ll still make mistakes, but they will be higher level learning and beneficial since you skip the lower level mistakes).
Casework vs. Toolwork
Toolwork is necessary for casework, but casework is the mission.
Tool training teaches toolwork. It should, because that’s its lane. But don’t expect it to teach casework. Casework is the sequencing of decisions across an entire case, under constraints, while excluding other plausible explanations, using whatever and how ever many tools fit the task.
That’s exactly what segmented training doesn’t do.
In PSBK CASEWORK, this is what you’ll walk away with
- a repeatable way to run a case from intake to defensible conclusion
- an investigative and defensible structure you can use on your next case
- decision-gate thinking: what matters now vs later
- practice turning artifacts into a narrative of human action
- practice excluding plausible alternatives instead of hand-waving them away
- the ability to explain your reasoning without hiding behind tool output
- application of the FACT Attribution Framework
This isn’t about making you “better at tools.” It’s about making you better at the job the tools are supposed to support.
This is for you if:
- you’ve taken plenty of tool courses and still don’t feel more casework-competent
- you can list artifacts but struggle to tell the story defensibly
- you want to stop relying on “the tool said so” as your reasoning
- you want judgment and sequencing, not another list of things to memorize
- you want validation in how you work or want to see how other experienced practitioners think
- you want to make better, quicker, more accurate decisions (and stop staring at devices wondering what to do first)
- you want either a transformation into an effective practitioner or gain that edge that separates you from the next best person
To save you time
- If you want a certificate for clicking “Parse,” there are plenty of other options
- If you want a feature tour of a tool you already own, the developer is your best bet
- If you want to avoid scrutiny instead of learning to survive it, this prepares you to face scrutiny head on, not avoid it
If you want to be the person who can answer “How do you know?” without flinching, this is for you.
Stop collecting tool outputs. Start building defensible casework.
Move into the CASEWORK city
Tools access artifacts. Artifacts are clues to the story.
*The book title is listed wrong online. The correct title is Integrating Use of Force Training (“of”, not “in”). It’s out of print now, but it laid out a structured, repeatable way to implement an integrated program in a police agency: Firearms + defensive tactics + decision-making, trained as one system instead of three silos. That approach is still in use at my former agency (and I’ve seen comparable versions adopted elsewhere). Scenario-based, immersion training consistently beats lecture-only when the goal is judgment under pressure.
Discover more from Brett's Ramblings
Subscribe to get the latest posts sent to your email.
