Hey everyone,

I've been playing around with Sigma for our QRadar instllation.
And I've noticed that some queries just don't work (or at least I think that's how it is)
For example: if Value is Greater than X
or: if property is in reference set
and so on.
Now I am aware that QRadar is a bit of a special child so I don't think it would make sense to implement everything that QRadar does.

But might it be of interest to have the possibility to input statements directly in the language needed?

Example:

detection:
  selection:
    username: X
  timeframe: 1d
  condition: selection and confidence > 80

Right now I just put inline comments because we use sigma primarily for documentation
so I do this:

detection:
  selection:
    username: X
    #confidence > 80
  timeframe: 1d
  condition: selection

I hope someone understands what I mean 😄

Regards,

Linus

Hi,
Current Sigma specifications for Windows taxonomy do not include the support for Channel: 'Microsoft-Windows-BitLocker/BitLocker Management'. I would suggest to add it so community can take some benefits in terms of detections.

Suggestion:

EVTX sample: https://github.com/mdecrevoisier/EVTX-to-MITRE-Attack/tree/master/TA0040-Impact/T1486-Data%20Encrypted%20for%20Impact
SIGMA rule: https://github.com/mdecrevoisier/SIGMA-detection-rules/blob/main/windows-bitlocker/win-os-BitLocker%20massive%20feature%20activation%20(native).yaml

Best regards
mdecrevoisier

Is there a way to compare column values with specific values such as EventId > 10?
I saw there is an aggregation with the comparison (count(UserName) by SourceWorkstation > 3) but I don't need aggregation.

Add the newly added event log in SigmaHQ/sigma#4234 to the taxonomy specification

I was reading through the wiki and noticed this line, "Aggregations in the condition are deprecated and will be replaced with Sigma correlations.", but can't seem to find any additional information on how to use Sigma correlations. Is there any additional info on Sigma correlations?

Is it possible to write a rule that checks if a value lies in a specified range? Example:

detection:
  selection:
    PORT|range:
      - 1
      - 1024

Also, is it possible to check if a field is less/greater than a number? Example:

detection:
  selection:
    PORT|less_than_equal_to: 32767

Move the Rx schema from https://github.com/SigmaHQ/sigma/blob/master/sigma-schema.rx.yml to this specification repository

Hello

https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/diagnosis/scripted/win_diagnosis_scripted_load_remote_diagcab.yml

from this rule:
service: diagnosis-scripted

and diagnosis-scripted is not mentioned in the taxonomy, could you please add it?

native sigma supports datetime values. It would be nice if we could extend that support to Sigma.

currently the v2 spec supports number values, such as:

detection:
    exp1:
        field|gt: 1
        field|lt: 10
    exp2:
        field2:
        - blah
        - foobar
    condition: exp1 and exp2

I propose it also can do similarly, but with datetime values, such as:

detection:
    exp1:
        field|gt: 2023-01-01T09:00:00Z
        field|lt: 2023-01-01T10:00:00Z
    exp2:
        field2:
        - blah
        - foobar
    condition: exp1 and exp2

running this through pySigma (at the moment) gives a type error: 'datetime.datetime' object is not iterable on line 196 of rule.py

Zeek and Suricata generate overlapping datasets, specifically around protocol analysis. I would recommend that we look at creating some generic log sources focused on the overlapping protocol analysis fields. A good place to start would be smb.

I'm coming from a Graylog background where the correlation engine supports the following methods:

1. Rule A triggers at least X times
2. (optional) AND Rule B doesn't trigger AND followed by Rule C
3. (optional) AND Rule D doesn't trigger in the next Y timespan
4. (optional) AND Rule E triggers at least Z times
5. etc.

Using the latest V2 specs the optional scenarios are not possible (at least from my understanding) without creating separate Sigma sub-rules, especially when the counting should differ from rule to rule.

Is it intention that such correlations are not possible in one single rule, probably for compatibility for other SIEM systems?

Hello,
from the rule:
service: diagnosis-scripted

and diagnosis-scripted is not mentioned in the taxonomy, could you please add it?

Hi

How does sigma expect regex to be applied to fields? Does the regex need to apply to the whole field? I couldn't find a definition in the spec.

Take for example rules/windows/process_creation/win_regini.yml

        CommandLine|re: ':[^ \\]' # to avoid intersection with ADS rule

If I translate that with sigmac I'll get a query string that requries a full match on the field.

$ tools/sigmac  rules/windows/process_creation/win_regini_ads.yml -c winlogbeat-modules-enabled -t es-qs
(process.executable.keyword:*\\regini.exe AND process.command_line.keyword:/:[^ \\]/)

I propose to define that behavior in the sigma specification and thought of these two possibilities:

Solution A: Sigma Spec defines partial match

If only a partial match is required I can try to make a pull request that would translate it to (process.executable.keyword:*\\regini.exe AND process.command_line.keyword:/.*:[^ \\].*/)

Solution B: Sigma Spec defines full match

If a full field match is required I could make a pull request to rewrite the rule to

        CommandLine|re: '.*:[^ \\].*' # to avoid intersection with ADS rule

Best Regards,
maederm

The specification describes the pipe operator (search_expression | aggregation_expression) as deprecated. However, there is no alternative to it, and it is still used in lots of sigma rules. Deprecated features usually have an alternative that they can be replaced with, and so I think it is misleading to say that it is deprecated. I think it would be more clear to say something like "we are planning to replace this with something else, but it's not ready yet". I've written a sigma integration recently and was confused by this. For me, different language would have communicated more clearly that implementers need to support the pipe operator.

Search-identifier's spec defined value types allowed in lists and maps, but it may need to be expanded.

Sigma_specification.md

By current definition, 1. a search-identifier can hold (1) a list of strings, (2) a list of maps, or (3) a map.
2. The map, in turn, hold key-value pairs, where each key is a field and each value is (1) a string, (2) an integer, or (3) a null (special field value).

sigma-specification/Sigma_specification.md

Lines 421 to 424 in 066938f

	#### Search-Identifier
	A definition that can consist of two different data structures - lists and maps.

sigma-specification/Sigma_specification.md

Lines 463 to 469 in 066938f

	#### Lists
	Lists can contain:
	* strings that are applied to the full log message and are linked with a logical 'OR'.
	* maps (see below). All map items of a list are logically linked with 'OR'.

sigma-specification/Sigma_specification.md

Lines 490 to 493 in 066938f

	#### Maps
	Maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value is a string or integer value. All elements of a map are joined with a logical 'AND'.

sigma-specification/Sigma_specification.md

Lines 555 to 560 in 066938f

	#### Special Field Values
	There are special field values that can be used.
	* An empty value is defined with `''`
	* A null value is defined with `null`

In addition, although not mentioned directly, there are examples showing that a map's value list also can store integers. Thus, I'd guess a map's value could also be 2.-(4) a list of strings, integers, or nulls.

sigma-specification/Sigma_specification.md

Lines 500 to 505 in 066938f

	selection:
	EventLog: Security
	EventID:
	- 517
	- 1102
	condition: selection

Real-World Usages

The aforementioned summarization/guessing is extracted from specification alone.
I checked some Sigma rules in SigmaHQ/sigma repo as well, and found another usage.

In rules/web/webserver_generic/web_cve_2021_26858_iis_rce.yml#L23-L30 a search-id holds a list which has an integer in it, making an usage of 1.-(4) a list of strings and integers.

    keywords:
        - 'POST'
        - 200
        - '/ecp/DDI/DDIService.svc/SetObject'

Are There More?

Will there be other types, say, booleans/floats/...?
For example, is usage of a map like

detection:
    sample-search-id:
        some-field: false

considered valid?

Summary

In conclusion, the spec's type definition seems to be incomplete/inaccurate and may need some update.

Maybe we can consider defining types as follows

1. A scalar: string/null/boolean/integer/floating point (as defined in YAML spec).
2. A search-identifier can hold (1) a list of scalars, (2) a list of maps, or (3) a map
3. A map is a key-value pair where the value can be (1) a scalar or (2) a list of scalars.

This link does not work:

https://sigmahq.github.io/sigma-specification/

Although many backends might not be able to support it, there is a need to check if two fields are equal or not.
Ref: https://github.com/SigmaHQ/sigma/discussions/3902
What about adding a |equalsfield: modifier?

That is how we implemented it in hayabusa:
https://github.com/Yamato-Security/hayabusa-rules/blob/main/hayabusa/builtin/Security/LogonLogoff/Logon/Sec_4624_Med_Logon-Type9-NewInteractive_PossibleTokenImpersonation.yml

As you can see I've got plenty of space for that frame to expand, but it is still shrinking the frame to not include the final 'n' that should be there.

If it matters, I am using Edge.

It is not specified (AFAIK) which flavor of regular expressions sigma rules use. PCRE2? PCRE?, etc...?

Regex parsing will change depending on the programming language, etc... so this should probably be defined in the specification so that it is clear what to use.

Hi,
I was looking for the product and service mapping that I should use in regards of the Windows Event Channel 'OpenSSH/Operational', but I couldn't find anything except in the Linux part. Could you clarify which mapping we should use for this channel ? Please not that this is not related to the WSL topic. This is a native Channel that can be found in Windows 10.

Maybe a suggestion:

• product: windows
• service: sshd

SIGMA log sources: https://github.com/SigmaHQ/sigma/wiki/Log-Sources
My Windows OpenSSH rule: https://github.com/mdecrevoisier/SIGMA-detection-rules/blob/main/windows-openssh/win-os-OpenSSH%20server%20listening.yaml

Many thanks
Michel de Crevoisier

Is there a mechanism to update the TLP tags to include the current First.org listings? Specifically, I use TLP:AMBER+STRICT often and would like to use it in my sigma rules.

I am comfortable updating it myself but haven't found where the tag references are located. (Truth in lending, I am using VSCode for my rule development so this may not be the right place).

Thanks in advance.

The RX YAML spec in this repository is outdated, and sigma-specification repository's spec schemata are invalid (RX validator rejects the schema).

When trying to validate rules with the RX YAML spec -- currently master@{2023-03-03}:sigma-schema.rx.yml, we found it being outdated. And thus, we tried checking the other repository sigma-specification instead.

However, that does not work either. RX validators prompt that the schemata are invalid. Neither main@{2023-03-03} nor version_2@{2023-03-03} there provide valid schema.

For example, with shaggy8871/php-rx

$ php vendor/bin/rx data.yml v2.yml
  ❌  An error occurred loading the schema.
      Unknown key `of` in `detection` //arr.

with rjbs/Rx's python implementation

$ python -c "import yaml; import Rx; Rx.Factory({ 'register_core_types': True }).make_schema(yaml.safe_load(open('main.yml')))"
Rx.SchemaError: unknown parameter for //arr

Hey, I'm trying to open the Sigma_Correlations.md page on the Wiki page to get some information about the usage of "Sigma correlations", but page displays as follows:

404 - page not found
The 
main

 branch of 
sigma-specification

 does not contain the path 
wip/Sigma_Correlations.md.

Hello,
from the rule:

https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/shell_core/win_shell_core_susp_packages_installed.yml

service: shell-core

and shell-core is not mentioned in the taxonomy, could you please add it?

I checked now the specification (thank you very much for it), several times, but I don't see a possibility to compare two different attributes of a log file. E.g. you want to check if the sourceIp is equal to destinationIp (not discussing here if this example makes any sense).
If this feature is not yet available I would suggest to allow a new modifier 'field'. In case it is present the value of a search identifier is treated as fieldname. E.g.

selection:
     sourceIp|field: destinationIp    # select flows where sourceIp eqauls destinaitionIp 

Also having the option to compare values with comparison modifiers of the new version like:

selection:
    bytesOut|field|g:  bytesIn   # select flows where more bytes went out than in

And in addition I would also vote for a specifc "not equal" comparison e.g. 'ne' to avoid to have a complicated comparision with two different selections and not-statement for this.

The sigma specification states it supports two wildcards (* and ?), but does not explicitly set out how they should behave. My assumptions, based on what I have read so far and prior experience with tools like splunk, are that ? should behave as a single mandatory(?) character wildcard (effectively a . in a regular expression), whilst the * represents a (optional?) unbounded length wildcard (again using regular expressions, akin to a .*) - but these are never explicitly defined (as highlighted by my comments in italics).

Although this is certainly a minor detail, being clear about the desired semantics for these characters would help assist in ensuring consistent behaviour across implementations.

Discussed in #6

Idea: add a correlation type that allows to inject/include detections from one rule to another and use them from there. This would be quite useful for false positive handling, generic rule parts and possibly other use cases typically encountered in integration of Sigma into an existing detection environment.