[FR] Make keeping up with commits easier for already modified rules

[stryngs]

Repository Feature

None

Problem Description

Keeping the detection rules from a point in time git clone which then get customized by toml or ndjson for the given environment can be fraught with the knowledge that a rule relied upon may soon change when better detection techniques are applied to a given rule name.

A given rule's filename never matches the string when you're searching for the name. grep -RHn can very much be your friend here. An example would be the Unusual Parent-Child Relationship. To find the file using grep in your cloned repository may yield something like this:

grep -RHn "Unusual Parent-Child Relationship"
privilege_escalation_unusual_parentchild_relationship.toml:55:name = "Unusual Parent-Child Relationship"
privilege_escalation_unusual_parentchild_relationship.toml:58:### Investigating Unusual Parent-Child Relationship

Depending on how you use the local copy of your repository for importing and keeping track of the newest change to a rule by exporting it locally as an ndjson can be very taxing from a time consumption perspective.

I think there should be a reverse ndjson to toml parser for the simple purposes of making diffs easier. This is blocked to my knowledge by the fact that the ndjson contains objects within the stack that the toml has no idea about, mainly being Exceptions.

Now, that isn't to say this may not already exist. I was searching around and there are over 800 repositories to browse. The detection-rules repo makes the most sense in this regard and so I think it does not, exist.

I propose that the folder layout structure is changed and the directory concept is removed. As underscores are already in place it should be a minimal effort to move the windows files in an ordered manner from windows/ to windows_ at the filename level.

From there the discussion of spaces ought be had. It is trivial too to give the old Hello\ World approach. Everybody has every different opinion and so I am sure of only one thing, if the idea catches on it will make diff much easier for a git clone from 6 months ago to catch up based on an environment matured in ELK for years.

Suppose windows_ was approved in the repo and the shift is made, now what?

Currently we can export as an ndjson.

It is interesting to export multiples and singulars and to combine them with rules that share similarities. json is fun like that and ordering can be hard. As I don't know the back-end for the export concept I will assume it is unordered and random and relies on the encapsulation that json provides to bring the sanity to what is an object.

As a stock rule from a fresh git clone has no concept of Exceptions this should be a thing that can be managed and merged. The question is of time.

Does something like this exist in the wild or is it worth making a PR?

Thanks for reading!!

Desired Solution

A thing based on the description unless it already exists. If it exists then go from there. If it does not exist then share the POC theory.

Considered Alternatives

No response

Additional Context

No response