ESA alerts depending of the time in event.time

[JohnDoe1]

Hi,

I have working ESA rule depending of the time with the following syntax

@Name('BusinessHours')

create context BusinessHours start (0, 9, *, *, *) end (0, 18, *, *, *);

...

Its works fine but the check is only based on the arrival time  of the log.

How change this behavior to base the check of the time on another meta ?

Examples :

• event.time for windows events
• a custom meta (some logs could contains multiple time like start time or stop time)

[CindyCelata]

hi, article 000026973 that is published in https://knowledge.rsasecurity.com has some information to check out on that.

[JohnDoe1]

Thanks Cindy Celata​ but this KB is only about  windows ans not related on the ESA.

I have edited my question to clarify.

[LeeKirkpatrick]

Hi John,

As you have noticed, by default the ESA appliance will utilise its own time for correlation. To satisfy your use case it may be worth while extracting the hours of the day from the event_time meta data using some in-built functions of Esper such as "getHourOfDay()" like so:

SELECT * FROM Event((event_time.getHourOfDay() in (9,10,11,12,13,14,15,16,17,18)) AND user_dst IS NOT NULL and event_cat_name = 'firewall change')

This allows us to manually specify the hours of the day like you have done so with your context but against a different time variable.

Cheers,

Lee

[DavidWaugh1]

Note make sure you multiply event.time by 1000 as it needs to be milliseconds since 1970, rather than seconds since 1970.

The line above would be

SELECT * FROM Event(((event_time*1000).getHourOfDay() in (9,10,11,12,13,14,15,16,17,18)) AND user_dst IS NOT NULL and event_cat_name = 'firewall change')

There is also a bug in Esper 5.1 that may prevent this is working in some cases. 10.6 uses Esper 5.3.

EsperTech acknowledged a bug which we reported last April, and it looks like it might apply in this scenario. To quote:

The bug is specific to the presence of a having-clause in a non-fully-aggregated and grouped query, and will only show up under certain sequences of data.

From some tests we did previously, we found that the bug caused conditionals in the having-clause to behave unpredictably, especially when using “having count(*)”.

The bug has since been patched in the newer versions (after 5.2), but our version of Esper in ESA is still at 5.1. We had to work around the issue by using a fully-aggregated query instead.