Spec Proposal: Authors field

[cugu]

I think it would be nice to have an authors field for artifacts, to give credit to artifact definition creators, editors and maintainers. Git blame has this information to a certain extent, but reformatting, moving or editing the yaml files might hide that information over time.

I would imagine it as an optional list of strings that every author can fill or extent to their liking, e.g. their GitHub username, a full name, an email, ...

Example:

name: WindowsEventTracingLogFiles
doc: Event Tracing for Windows (ETW) log files.
authors: 
  - joachimmetz
  - Another Author <author@example.com>
  - Last Author
sources:
- type: FILE
  attributes:
    paths:
    - '%%environ_allusersappdata%%\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\*.etl'
    separator: '\'
supported_os: [Windows]

[joachimmetz]

Sorry but this is huge hassle for maintenance for little additional value. There is a git commit history that indicates authorship.

I would recommend people to make a good contextual write up of the artifact that they can add their name to it and they can link it as an url.

I also see the definitions here more as a configuration. Why does a config need the name of an author?

[cugu]

Sorry but this is huge hassle for maintenance for little additional value.

Well it would be up to contributors to add this or not when it is optional. No need for you (or anyone) to add those.

There is a git commit history that indicates authorship.

And I explained why this does not solve this issue.

Why does a config need the name of an author?

People like to be recognized for their work. Artifacts are similar to yara or sigma rules, which both contain author fields.

[joachimmetz]

Well it would be up to contributors to add this or not when it is optional. No need for you (or anyone) to add those.

So who would be the "author"? in DFIR a lot of things are copy pasted without proper author attribution.

And I explained why this does not solve this issue.

Why do you need to retain a 1-to-1 mapping of author to the definition?

Artifacts are similar to yara or sigma rules, which both contain author fields.

Not entirely, artifact definitions do not contain logic and there I often wonder if the person that authored the rule actually did the research.

People like to be recognized for their work.

I rather see a write up of solid independent validation of observations. The definition can then point to that work. IMHO that is the work that people should be recognized for, not the fact that they can write a configuration.

[cugu]

So who would be the "author"?

Anyone that creates or edits an artifact to a certain extent. And yes I am aware that this leaves room for interpretation.

in DFIR a lot of things are copy pasted without proper author attribution.

Which is sad and does not justify to encourage doing the same.

Why do you need to retain a 1-to-1 mapping of author to the definition?

I copied some artifacts you and some others created and would like to do proper attribution. Also I suggest a 1-to-n mapping. One artifact can have multiple authors.

I rather see a write up of solid independent validation of observations.

This is rather unrelated to an author field. I don't think anyone will create a write up because there is no author field. Also an author field will not belittle a decent write up.

[joachimmetz]

I copied some artifacts you and some others created and would like to do proper attribution.

Link to a forensics wiki article, often your attribution does not stand alone and other sources would need to attributed as well. For DFIR referencing multiple independent source is even more important for the credibility of the source.

Anyone that creates or edits an artifact to a certain extent. And yes I am aware that this leaves room for interpretation.

This is already tracked by the commit history. Does not answer why a 1-to-1 mapping is needed.

Which is sad and does not justify to encourage doing the same.

I would argue that adding an author field actually encourages actual encourage shoddy attribution. This is already seen with the previous (and other) examples you mention. Also have a read of https://osdfir.blogspot.com/2020/09/testing-digital-forensic-data.html of examples of how deep this issue goes. Such as tool authors copying behavior of other tooling without attribution or validation, and only when an error surfaces they are to put the blame elsewhere.