Thanks Ali, Storm without ackers would be a good example as well. From the attached network diagram where a hub sits below a switch with sensors on the span port at A and the hub at B. Traffic from B going to the router would be duplicated.
Kibana tables could take care of things as is. The workflow to raise tickets from here needs a ctrl + tab, paste in id, raise ticket. I’m not sure how a signature/hash approach for every event could filter the Analyst View for all events globally. I imagine the nifi dedupe processor adding a flag to the first event seen might be an option, and using profilers would be ok with a global limit of 1 min. Is there a better way currently? On Thursday, February 22, 2018, Ali Nazemian <[email protected]> wrote: > Hi Jack, > > Good to see you here. Would it help if you can introduce a signature > for every event and then try to filter based on the signature? a duplicate > message might be related to the source or at least once guarantee of Storm. > > Cheers, > Ali > > On Fri, Feb 23, 2018 at 3:14 PM, Jack Burgess <[email protected]> > wrote: > >> Long time listener, first time caller. >> >> There is a case where a packet reaches multiple sensors through normal >> configuration and is logged multiple times. >> >> Understanding which sensors are operating and which network routes are up >> is useful from a data science / threat hunting perspective. From an analyst >> perspective these duplicate alerts are mostly clutter. >> >> Is there simple way to toggle out these duplicate alerts in the Alert UI? >> >> -Jack >> > > > > -- > A.Nazemian >
