Say SO is configured to use Suricata with the Emerging Threats ruleset

One of the rules is triggered:  ET CNC Zeus Tracker Reported CnC Server 
group 12 for IP address 199.59.242.150.

Now, with RC3, I can highlight the destination IP address in Squert and 
search for it in Kibana.  While in Kibana I see that a DNS lookup was done 
and that the DNS name for that IP address is pixel.ad.mlnadvertising.com.  
When I add the source IP address to the Kibana search criteria, I'm shown 
which program is responsible for the traffic:  Google Chrome.  This tells 
me enough to know that this particular traffic is probably benign.

So knowing all of this the next step is to prevent future versions of this 
rule with these criteria from polluting Squert.

I believe that leaves me with the following choices:

1 - Suppress the "ALL ET CNC Zeus Tracker Reported CnC Server group 12" in 
threshold.conf  --  However this will leave me exposed to true positives 
for this rule.
2:- Modify that rule in modifysid.conf so that if the IP 
address 199.59.242.150 is detected as part of that rule, ignore it.  
However, this IP address may go back into circulation as evil (or it may be 
shared and is still evil), thus exposing to possible problems in the 
future.  This also won't solve future similar false positives -- there may 
be multiple IP addresses assigned to pixel.ad.mladvertising.com.  
Maintaining this modify rule can become unruly.
3 - Add a filter rule to Squert for this rule and this destination IP 
address -- But that's only as good as #2.

What I really need is that third check -- which program is responsible for 
the traffic.  If also Google Chrome and dst port 443, then don't populate 
Squert as a danger.

What I've considered doing instead is write a script that runs on a 
schedule -- it would query the squert db for these potential false 
positives, and then run a search to look for the extra criteria I searched 
for in Kibana before making a decision to update the squertDB and "hide" 
the event.  With the release version of SO, I could 
use /opt/elsa/contrib/securityonion/contrib/cli.sh to search Elsa.  What is 
recommended for Kibana?

What other ideas are there to deal with situations where the only way to 
make a decision is based on data only found in ELSA or Kibana (Or possibly 
elsewhere)?

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to