Detection Rules: Time Frame Based Exceptions

[BenB196]

Hi All, I was wondering if it's possible to added time based exceptions to detection rules?

An example would be with some of the current detection rules, they get triggered during system patching. Ideally it would be nice to add an exception for systems during a specific time frame that they will be patched, so alerts won't be detected then. I wasn't able to find anything regarding this searching around so figured I'd ask here.

Note: I'd like to add it as an exception rather than part of the filter or query, so that comments could be appended to the exception so people know why its there and how to change it.

[yctercero (Yara Tercero)]

Hi there @BenB196 !

At the moment, exceptions don't include a range option. While not quite as ideal, you could use the custom label option on filters to give some context like below:

Please do feel free to create an issue for a feature request!

Best,
Yara

[BenB196]

Thanks @yctercero for the suggestion, I will try that out.

By chance, would you know if adding time frame exceptions is on the roadmap at all? I didn't find anything in the Kibana GitHub project, but don't know if I was looking in the wrong place or not.

[Mike_Paquette]

Thanks @BenB196 regarding the roadmap for new capabilities, we have had requests for a similar enhancement, sometimes described as a "time-to-live" (TTL) attribute for exceptions.

I hope you don't mind if I pick your brain for some feedback:

1. In your experience, would you like to see the time-based exception be ad hoc, self-expiring? e.g., "make this exception active for the next 60-min from now"
2. would you like this time-based exception be based on absolute time?
3. would you see value in a time exception that was one time only, or are you looking for a recurring schedule?

Thanks again for your feedback and for being a part of our community!

[BenB196]

@Mike_Paquette I think all three options have their place.

1. Ad-hoc, self-expiring is a great use-case for out-of-band patching, such as emergency security patching.
2. Absolute times are good for planned patching that doesn't fall within a recurring schedule. I generally see this as happening during an application upgrade, where someone needs to also upgrade the system for the application.
3. Recurring schedule is great for standardized patching time frames. If every Saturday systems are patched for regular maintenance, it'd be great to not have to do any additional work to silence alerts during these times.

The use-cases I provided are just around system maintenance, but I think time based exceptions would provide a real value in most of the security suite.

One thing that I think is important though, is I don't think the time based exceptions should be globally applied, and they should be pair-able with AND clauses to filter down what is excepted.