New Procedure Field

[nasbench]

Hi,

I would like to propose a new field called procedure to the SIGMA taxonomy. The purpose of this field is to give details on how to replicate the events that are expected to be caught by the detection itself. So for example a full command line to be executed or a set of steps to do to be able to generate the events.

This will help us in 2 main ways at least:

• Offers more readability and can be shown in SIEM or playbooks as metadata to help the analysts instead of drilling down the reference all the time.
• It'll help us if we want to build a detection as a code pipeline or do some rule confirmation in the future

Let me know what you think.

[thomaspatzke]

In the dark corners of my mind I remember this was already discussed at least once but never found its way into Sigma for reasons I don't remember anymore, so why not giving it another try 😉

* Offers more readability and can be shown in SIEM or playbooks as metadata to help the analysts instead of drilling down the reference all the time.

I develop lots of playbooks supporting analysts in handling cases, but reproduction commands are not something I considered as useful for them nor was this requested. Usually, the analysts see the commands triggered a detection or the investigation focuses on other aspects.

* It'll help us if we want to build a detection as a code pipeline or do some rule confirmation in the future

I think such CI testing is very specific to the test environment. Some considerations:

• Often reproduction requires additional context: a certain operating system version, installed software, (mis)configuration etc. This has also to be expressed somehow.
• Attacks often depend on the reference of particular objects like resources, users, hosts etc. that must exist. Therefore, there must be the possibility to reference variables that must replaced with objects existing in the given test environment. Just think about the user name translation mess in Windows...

I can imagine that a very basic list of reproduction commands only covers a relatively small fraction of rules. Specifying this further to gain more coverage will create a real beast of specification and huge efforts to keep this generic.

Check out Atomic Red Team which was build exactly for this purpose. I think it's better to use such projects that solve the problem very well instead of building another thing that is not really the focus of Sigma.

[nasbench]

While I agree with that Atomic Red Team is a solution for the testing part. It doesn't solve the point that I want to address. Which is lack of context behind the detection in a SIGMA rule on its own.

Playbooks you're talking about are response playbook on how to act after something alerted. I'm talking more about understanding the reason behind why the alert fired (Which is not necessary the role of a SOC analysts).

Currently a SIGMA rule links to other references and have a short description, but these two in my opinion are not enough to make use. I know when I used SIGMA for the not so straightforward rules, I needed to do more research to understand the reason behind the logic (This is not always the case as some rule are easy to understand).

But the point that I want to reach is that we need some sort of "field" or "descriptor file" that explain the SIGMA rule a bit more and offers more context rather than the basic "Go read the reference" section.

In this new thing we could add commands, description, details about FP and the context behind them...etc.

Basically we need to offer more information with a SIGMA rule. Perhaps a new "field" isn't the best solution but the I hope now the idea I have is now clearer at least.

[Neo23x0]

Yes, we've discussed something very similar before, with @WojciechLesicki - I mean the part about the validations.

That's why we started the repo "sigma-validation-guides". We wanted to keep that information out of the rules. But we never filled the guides with content, because it is so much work to do.

It was a PR followed by a discussion: SigmaHQ/sigma#2207

and have a short description,

The description doesn't have to be short. :D
It could be a long text that explains why the rule triggered and what could have caused it etc.

[nasbench]

Future nas here.

Atomic red team will be implemented as part of the CI as well the introduction of detection guides.