My thoughts here essentially devolve into a selfish interest in alerts
separate from a SOC analyst style alert in order to facilitate
notifications such as larger issues with a topology, extremely high latency
for an enrichment, a drop off in certain types of sensor traffic, etc. I
feel like there is a similar use case which is more relevant to this
discussion. Effectively what I'm thinking as an option 3 is we split the
alert into option 2 and an is_alert_investigator (or other role).
On Mon, Oct 17, 2016, 13:54 Casey Stella <ceste...@gmail.com> wrote:
> 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>
> > Can I vote for neither? I believe that is_alert is primarily intended
> > use by a SOC Analyst (assumed level 1) before it gets passed to a SOC
> > Investigator, Forensic Investigator, etc., and that a message which
> > a threat triage rule should instead come to the attention the SOC
> > Investigator role directly (although I could see an argument for address
> > 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
> > 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?
> > Jon
> > On Mon, Oct 17, 2016 at 12:21 PM Casey Stella <ceste...@gmail.com>
> > 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).
> > Thoughts?
> > Best,
> > Casey
> > --
> > Jon