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).
Jon 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 > triaged. > > 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? > > Casey > > > 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? > > > > Jon > > > > 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). > > > > Thoughts? > > > > Best, > > > > Casey > > > > -- > > > > Jon > > > -- Jon
