DO SIFT

Dynamic orchastrator for SIFT forensic tool workflow

Comment

About the Project

Inspiration

Forensic tooling is extremely powerful, but it is also difficult to use safely.

In real incident response, an analyst may need to move between hashing, file type analysis, strings extraction, IOC extraction, timeline tools, memory tools, registry tools, event log parsers, and many other SIFT-aligned utilities. The problem is not only running a tool. The harder problem is knowing which tool to run, when to run it, how to run it safely, how to parse the output, and what conclusions the evidence actually supports.

We wanted to build something that makes SIFT-style forensic workflows easier to consume without turning them into unsafe raw shell access.

That inspired DO SIFT: a Dynamic Orchestrator for SIFT.

The core idea is simple:

The user should not need to know SIFT command syntax.
They should provide an artifact and an investigation goal.
DO SIFT should safely orchestrate approved forensic adapters and return evidence-backed results.

We also built BreachLens, a separate SOC analyst portal, to show how a real end-user product can consume DO SIFT through APIs. BreachLens is not the forensic engine. It is the analyst-facing experience powered by DO SIFT.

What We Built

We built two connected but separate products:

1. DO SIFT

DO SIFT is the main product. It is a forensic orchestration and evidence-verification engine for SIFT-aligned workflows.

DO SIFT handles:

  • artifact upload or registration
  • SHA-256 hashing
  • workflow selection
  • approved adapter selection
  • guarded runner execution
  • parser output normalization
  • evidence ledger creation
  • claim validation
  • reasoning diff
  • traceable report generation
  • REST API access
  • MCP server access for agent integrations

The most important design principle is:

The planner never gets raw shell access.
It only selects approved adapter IDs.

That makes DO SIFT safer than a generic chatbot wrapped around forensic tools.

2. BreachLens

BreachLens is a separate end-user SOC portal built on top of DO SIFT.

It lets an analyst:

  • upload a suspicious artifact
  • select an investigation workflow
  • start a triage run
  • view investigation progress
  • inspect evidence cards
  • review claims
  • see unsupported or not-confirmed areas
  • open the technical trace
  • read the final DO SIFT report

BreachLens does not run forensic commands directly. It calls DO SIFT through server-side REST API proxy routes and displays DO SIFT’s output.

The relationship is:

DO SIFT is the engine.
BreachLens is one real SOC product built on top of that engine.

How It Works

The full investigation flow looks like this:

SOC analyst
  -> BreachLens UI
  -> BreachLens server-side REST proxy
  -> DO SIFT API
  -> DO SIFT planner
  -> guardrails
  -> approved adapter registry
  -> local/container runner
  -> parser
  -> evidence ledger
  -> claim validation
  -> traceable report
  -> BreachLens UI

In the current production proof pack, DO SIFT supports five verified portable adapters:

Adapter Purpose
tool_portable_sha256 Calculates artifact SHA-256 hash
tool_portable_file_type Classifies the file type
tool_portable_strings Extracts printable strings and suspicious command fragments
tool_portable_ioc_extract Extracts URLs, domains, IPs, hashes, and Windows paths
tool_portable_metadata Extracts artifact metadata such as size and entropy hint

These adapters execute through the guarded runner path and produce structured observations.

DO SIFT currently includes Production Workflow Pack v1:

  • Suspicious File Triage
  • IOC Extraction & Evidence Review
  • Malware Triage Lite
  • Evidence Integrity / Chain of Custody
  • Lightweight Incident Triage

The workflow packs are planner hints, not raw scripts. They do not grant access to unverified tools. The planner still has to operate through production guardrails and approved adapter IDs.

Evidence-Backed Claims

A major goal of DO SIFT is to avoid overclaiming.

A URL in a file does not automatically prove compromise. A suspicious command fragment does not automatically prove malware execution. A path does not automatically prove persistence. An IOC does not automatically prove attribution or exfiltration.

So DO SIFT separates:

  • evidence-backed confirmed findings
  • weak indicators
  • unsupported conclusions
  • unknown areas
  • evidence boundaries

For example, DO SIFT can confirm that an artifact contains URLs, domains, IPs, suspicious strings, and metadata. But it should not claim confirmed malware execution, persistence, exfiltration, or attribution unless stronger evidence exists.

This is one of the most important parts of the project: DO SIFT is not just trying to generate a dramatic incident story. It is trying to produce a defensible investigation report.

Deterministic Planner and Optional LLM Path

For the demo, DO SIFT can run with a deterministic planner fallback. This makes the demo reproducible and reliable.

If an OPENAI_API_KEY is configured, DO SIFT can support optional LLM-backed planning. But the LLM does not get raw shell access. It must still operate inside the same safety boundary:

  • strict planner schema
  • approved adapter IDs only
  • no arbitrary commands
  • production guardrails
  • evidence-backed claim validation

The key design is:

LLM planning is optional.
Guardrails and evidence validation are mandatory.

What We Learned

We learned that the hardest part of AI-assisted forensic investigation is not simply calling an LLM or running a tool.

The hard parts are:

  1. Safe orchestration The system must decide what to run without exposing raw shell execution.

  2. Adapter boundaries Not every discovered forensic tool should become planner-allowed. A tool needs a safe template, parser, risk classification, and validation before production use.

  3. Evidence integrity Every finding should connect back to the artifact hash, adapter, parser, runner, and timestamp.

  4. Claim discipline Weak indicators should stay weak. The system should not turn IOC presence into a false compromise claim.

  5. Separation of engine and app DO SIFT is reusable infrastructure. BreachLens proves that a real SOC product can consume it without duplicating forensic logic.

Challenges We Faced

1. Avoiding Raw Shell Access

A naive version of this project would let an AI agent generate shell commands. That is dangerous. We had to design DO SIFT so the planner can only select approved adapter IDs, while the executor renders safe command templates from the registry.

2. Separating Discovery From Execution

Just because a forensic tool exists does not mean it should be production-enabled. We separated the discovery catalog from the approved adapter registry. Discovery is informational. Planner access is controlled by verification, parser coverage, production readiness, and guardrails.

3. Making the Demo Real Without Overclaiming

We wanted the demo to be fast and reliable, but still honest. The current proof pack uses safe portable adapters over real uploaded artifact bytes. It does not pretend to perform full disk, memory, registry, or EVTX analysis unless those adapters are installed, parser-mapped, and validated.

4. Evidence Boundaries

It was tempting to make the report sound more dramatic. But forensic tooling should be careful. We added unsupported areas and evidence boundaries so DO SIFT can say what it found while clearly stating what it cannot prove.

5. Building a Separate Consumer Product

Instead of making one combined dashboard, we built BreachLens separately to prove that DO SIFT can be consumed as a platform. That helped us show the real product vision: DO SIFT can power many future SOC tools, analyst portals, AI agents, and DFIR workflows.

Why This Matters

DO SIFT improves forensic workflows at the platform layer.

It gives developers and security teams a safer way to embed SIFT-aligned forensic intelligence into their own products.

The user experience becomes:

Upload artifact.
Describe goal.
Review evidence-backed report.

The user does not need to know every forensic command, parser flag, or tool-specific workflow.

DO SIFT handles the orchestration, guardrails, evidence mapping, and reporting.

Final Positioning

DO SIFT is not just a dashboard and not just a chatbot.

It is a reusable forensic orchestration engine:

safe adapter selection
  + guarded execution
  + structured evidence
  + evidence-backed claims
  + traceable reports

BreachLens proves the platform is useful immediately as a SOC-facing product, while DO SIFT remains reusable for any future application through REST or MCP.

Our final vision is that AI-assisted DFIR should not mean giving an agent unsafe command-line access. It should mean giving analysts and products a safe orchestration layer that knows the boundaries of the evidence.

That is what DO SIFT is built to do.

Built With

  • sans
  • sift
Share this project:

Updates