Proposal: modifiers for time comparisons

[Res260]

Proposal for a set of modifiers to allow for conditions on datetime fields.

I suggest adding the following modifiers:

|minutes: Get the number of minutes in the hour of the datetime field. Between 0 and 59
|hour: Get the number of hours in the day of the datetime field. Between 0 and 23
|day: Get the number of days in the month of the datetime field. Between 1 and 31
|dayofweek: Get the day of week as a number of the datetime field. Between 1 and 7 where 1 is monday and 7 is sunday.
|week: Get the week of year as a number of the datetime field. Between 1 and 52.
|month: Get the number of months in the year of the datetime field. Between 1 and 12.
|year: Get the year number of the datetime field.

Example use case

Let's say I want to create a use case to detect when a user gets added to a specific group off-hours. This is currently impossible. The proposal would allow such use cases. It would look something like this:

detection:
  selection:
    Operation: User Added to Group
    Group: Special Group
  time_selection_1:
    Timestamp|hour|gt: 17
  time_selection_2:
    Timestamp|hours|lt: 8
  condition: selection and (time_selection_1 or time_selection_2)

Most SIEM support these operations

Splunk: With strftime()
Sentinel: With functions such as hourofday()
QRadar: With DATEFORMAT()
Elastic: With DATE_FORMAT()
Logscale: With formatTime()

Thoughts?

[thomaspatzke]

There's an use case, there are solutions for various SIEMs. Why not 😁

[frack113]

How write before 08h30 and after 17h00 (Monday to Friday except vacations 😄 ) ?

selection_coffee:
    Timestamp|hour|lt: 08
    Timestamp|minute|lt: 30

I think SIEM will only check 00h00/00h29 -> 07h00-07h29
somethink like that ?

selection_coffee:
    Timestamp|timecheck|lt: 08h30
    Timestamp|cron|lt: '30 8 * * * ' 

Why not add to Meta Rule event_time ?
I think it will be more easier

correlation:
type: event_time
  rules:
    - add_special_group
  ???
  condition:
   ???

[Res260]

I'm definitely open to other opinions and whatever what is chosen I'll still be happy, I just have preferences :D

[frack113]

So we have the use cases
I want the field with a date :

• is in a time slot
• is less X from now
• is less X from another field date

[Res260]

Yes, and these use cases should work with all the time units (minutes hour day week month etc)

[thomaspatzke]

@thomaspatzke thoughts?

It escalated quickly 😂

The cron version is more my sadistic side than a real solution.

Indeed, I can feel the pain 😁

My preference would be the balance between simplicity and expressiveness. It's not a feature that I believe will be used too often and therefore I think it's acceptable that the rules are not the most beautiful ones. It's also the question if a detection must really express 08:30 or if it's just sufficient to say 8:00. Usually, when I work with timeframes in detections I try to restrict to full hours or days for the sake of simplicity. As conclusion my opinion is that |hour, |day etc are sufficient.

[Res260]

Good, if it's okay I'll do a PR to add this to the spec!

[JuxhinDB]

Wondering if there has been traction related to this lately?

[thomaspatzke]

If it was merged in the main branch then it will be included in 1.0. release-0.11 is currently the branch that gets released in the last 0.11 releases, mostly for bug fixes.

[Res260]

Okok, is there an ETA for 1.0?

[juxhin-brigjaj-imi]

Roger that, thank you both!

[thomaspatzke]

I've started to cherry pick the addition of the modifiers and it seems to work so far. Will do an 0.11 release with these if finally everything works.

[thomaspatzke]

Backported successfully, release 0.11.20 contains the time modifiers!