Support Analysis Suggestions in Approaches

[lo-chr]

Expected Behavior

The project should support the description of "analysis suggestions" in the approach definition file. I would propose a new subsection suggestion under the view section.

There are cases, where typical (malicious) activity has similarities from one threat actor to another. It would be helpful to integrate such hints, so that analysts can get an idea what to look for.

Actual Behavior

Feature not included.

Steps to Reproduce the Problem

not applicable

Specifications

• Version: 1.0.0
• Platform: not applicable

[obsidianforensics]

Hi there, thanks for the suggestion. I've published the Markdown version of the DFIQ specification: https://dfiq.org/contributing/specification/

I see a few places where an analysis suggestion could fit:

• the Analysis Steps section
• the Facet description field

Could you take a look and let me know if either fits what you intended with suggestion?

I've put some similar "suggestion"-type bits in some Facets (like the example in the Spec) that inform the analyst what to look for. This was my attempt at an informal "modifier" for the Questions - rather than have different questions for looking for a lot of file downloads at once, or look for only one file download, or even for periodic file downloads, to just have one "file downloaded" question, and then the analyst modify their analysis to fit the Facet.

[lo-chr]

Hey, thanks for the effort and the updated documentation! Unfortunately, I'm not sure, if one of the suggested fields really solves the issue:

• The description field in the Facet (in the example) now contains two information in one field:
  • The description of Facet: "Staging" refers to the collection of data of interest onto a local system,
    as a precursor step for future exfiltration of that data.)
  • The approach how to analyze the underlying data: When reviewing data from Questions in this Facet, look for unusual volumes of results (number or size of files downloaded or sent, for example).
• Integrating the information in every steps of an approach file, leads to redundancy: I can think of examples, where the "analysis hints/suggestions" are not limited to one or two analysis platforms.
  Example: I would always consider a RunKey that starts a programs from User/[...]/AppData/ as suspicious. I would not want to duplicate this information for every analysis platform but document it in a dedicated field.

Hope this makes sense. :-)