Stay up to date on our technology, training, events, and more.


By submitting this form, you agree that Sleuth Kit Labs may process your information in accordance with our Privacy Policy. We’ll use your information to send educational and marketing communications.

You can unsubscribe at any time using the link in our emails.

Not now >

SANS vs SKL DFIR AI Frameworks: When to Use Each

Heather Barnhart has done great work helping develop the SANS DFIR AI Framework. If you haven’t seen it, I recommend reading it.

That said, it differs from how we’ve been talking about AI.

This post dives into if the two views are actually in conflict or just looking at the problem from different angles.

TLDR: They’re complementary. The SANS framework is more helpful for an investigator to map AI to their process. Ours is more useful for thinking about what to validate.

The SANS / SWGDE AI Framework

Developed by Heather Barnhart and others, the SANS framework organizes AI guidance around SWGDE investigation phases:

  • Identification
  • Collection/Preservation
  • Triage
  • Examination/Analysis
  • Validation
  • Reporting

For each phase, it assigns a risk level: AI recommended, AI optional, or AI never. 

These phases map cleanly to how investigators were taught to do investigations and, presumably, how they approach them. This is a clean mental model to help investigators map AI to where it fits into their current workflow.

This is the right model when training investigators about where to expect AI.

The “SKL AI Framework”

We haven’t formally documented “our framework”, but we show it in our webinars and refer to it in blog posts. We’ll get a blog post out soon that maps it out in more detail.

We have been more focused on specific tool features that can benefit from AI, and what happens to data during an investigation. Forensic tools are fundamentally data processing pipelines, so we’ve organized our thinking around data operations (rather than investigation phases):

  • Collect: Copy data from a device to a file or database.
  • Parse: Convert collected data to a more useful format.
  • Normalize: Map data and events to their semantic meaning (i.e. Prefetch → Process).
  • Enrich: Add context through lookups, detections, threat intel, summarization.
  • Score: Determine if an artifact is relevant to the case.
  • Display/Publish: Present results in human or machine-readable form
  • Query: Find items based on criteria.
  • Co-pilot: Chat interface to answer investigator questions.
  • Validate: Double-check findings and conclusions.

For each phase, we’ve been mapping out if AI provides value for that type of operation and how much human validation is required.

This is the right model when thinking about what AI can do and what to validate

One Level Deeper

Fundamentally, the SANS framework operates at the human layer, and our approach has been at the data layer. Their recommendations seem consistent with ours, just at a higher level of abstraction.

Take their Triage phase, which they mark “AI Recommended.” We agree with that conclusion. 

But within that phase are several distinct data operations, each with a different AI validation burden:

One investigation phase with five different types of potential validations. Knowing the phase tells you AI is appropriate. Knowing the operation tells you what to check.

They’re Asking Different Questions

The SANS framework answers: “Where in my investigation is AI appropriate?”

Our phases answer: “What did AI actually do, and how do I verify it?”

Both questions matter.

  • As you start to think about AI, the investigation phases matter for mental framing.
  • As you use AI and need to validate the outputs, you need to think about the data processing.

During triage or examination, you may come across an unknown file format. If AI parses it, then you need to validate the output. If you don’t need AI to parse an unknown file format, then no special validation is required.

See the drone reversing engineering submission to the DFIR+AI challenge for an example where AI can be really powerful at parsing unknown formats, but can also have errors. That submission incorrectly parsed a drone data set, but we were able to get it to parse correctly when we gave Claude more data.

You need to know what kinds of operations that AI did in your investigation to know what to validate.

How We Are Using Our Framework

We are incrementally rolling out AI into Cyber Triage and Autopsy with a focus on enabling you to validate.

  • The first releases were read-only MCP so that your original data never changed. All AI-generated data was within your AI client.
  • Cyber Triage 3.18 added some limited ways to write data, but limited to enrichment and scoring (two of our phases). AI-generated data is clearly prefixed with “[AI]”. You should validate those findings.
  • Cyber Triage 4.0 will automatically summarize a host, provide AI-based threat intelligence, and suggest remediation steps. These will be clearly labeled as AI for you to validate.

If you want to try Cyber Triage with MCP, then you can download the latest evaluation version and setup your MCP client.