You certainly can vote for neither. :)
Just for clarity, is_alert is not set by the triage code. Only messages
which are alerts already are triaged. I wasn't clear in how I explained
that, so sorry about that. Option 1 would just send the data through
untriaged and 2 would skip the bad rule and otherwise triage the alert, but
in both cases is_alert would be true because otherwise it wouldn't be
There has not been any discussion that I know of around different types of
is_alert, but there is nothing preventing the user to add an additional
field as part of the threat intel enrichment phase to associate the alert
with a role and adjust the kibana dashboard to be more selective about the
alerts that it shows.
How would you envision it working? Is this a feature that we should enable
or bake in in an opinionated way, in your mind?
On Mon, Oct 17, 2016 at 1:44 PM, zeo...@gmail.com <zeo...@gmail.com> wrote:
> Can I vote for neither? I believe that is_alert is primarily intended for
> use by a SOC Analyst (assumed level 1) before it gets passed to a SOC
> Investigator, Forensic Investigator, etc., and that a message which failed
> a threat triage rule should instead come to the attention the SOC
> Investigator role directly (although I could see an argument for address by
> other roles).
> I don't have a solution here, just a presentation of the problem as I see
> it. I feel like adding is_alert would add noise to the SOC Analyst's view,
> but they don't necessarily have the skill set to resolve the issue.
> Has there been any discussion around different types of is_alert, such as
> ones only relevant to a certain role?
> On Mon, Oct 17, 2016 at 12:21 PM Casey Stella <ceste...@gmail.com> wrote:
> Similar to the other discuss thread that I just put out about field
> transformations, I wanted to get some community impressions for how to
> handle triage rule failure.
> Currently, if a threat triage rule fails with an exception or returns a
> non-boolean, an error is thrown and no triage happens. I wanted to see
> what y'all think the proper behavior should be:
> 1. Apply no threat triage rule, log error and send message through
> untriaged, but with is_alert set to true
> 2. Skip the individual threat triage rule, log error and send the
> message through triaged sans broken rule(s).