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 <alinazem...@gmail.com> 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 <j.burgess.m...@gmail.com>
> 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
>

Reply via email to