Field should be referenced as part of the possible "Value" comparison

[lcostantino]

This may have been previously asked or mentioned in #52.

It's pretty common to have rules that require comparison (with all supported operators) between fields for the same event.

Currently, we are using some extension that if the "Value" match a FieldName if will be changed appropriately.

(In this "sample" syntax any string that starts with <,<,!=,=,<=,>= will be evaluated for a subsequent field name, but nothing prevent to use the same value replacement like cs-bytes|gte: "myField" , except for types check [int, string, etc])

Use cases would include:
-> connections with more traffic sent that received
-> A low integrity process spawning a high integrity process
-> etc, etc..

Example:

            title: Test
            status: test
            logsource:
                category: network_connection
                product: windows
            detection:
                sel:
                     cs-bytes:
                       - ">sc-bytes"
                     pkt-count|gte: 3
                condition: sel

I'm just proposing the feature here, not the final syntax, but can work on that if there's agreement about this need.

[Res260]

There already exists a modifier to reference another field: fieldref.

However, it only works for "fieldA equals fieldB" comparisons AFAIK.

It does not have to be this way, though.

This should work and would not require new syntax or new modifiers:

detection:
  selection:
    requestBytes|gte|fieldref: responseBytes
  condition: selection

This reads as "the number of requestBytes is greater or equal to the number of responseBytes"

[lcostantino]

great will close this one

[lcostantino]

closing as the basic use case is supported.

[Res260]

I don't think this should be closed, as the current implementation is very basic and should/could be improved

[lcostantino]

will keep it open so we can discuss improvements for future implementations!
I thought the "gte" version was working but no, it require changes to be improved given it also would fail due to numeric checks.
i like your proposal of how this can be improved without further syntax changes.