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!