2 of 2 people found this helpful
I would suggest you check the packet capture and alert details and compare them with the signature description (where available):
1) if pcap matches Sig description, then is a true positive.
2) if pcap does not match the Sig description, then is a false positive
Also think that I can generate windows attacks against a *nix server, and these will generate true positive alerts (as the traffic traversing the sensor contains the strings/conditions detailed on the Sig description) - but in this case I would say is a 'true positive with no security impact'. Or in the same way, a win 2003 CVE that matches the strings on the Sig, against a 'patched' win 2008 system would be a TP with no security impact (since the string -match - was there, but the vuln was not).
This is actually a really important point to be defined on soc processes, as too often I hear is a false positive when actually there is a string match on the pcap, so it is important to differentiate if it is a TP or a FP with or without security impact, which gives a much better understanding of the severity of the event detected.
Hope this helps.
Thanks for the explanation, as such, what is the next action that you will usually take upon identify an attack is TP with no security issue? Just put it create a ignore list or disable that attack in IPS Policy? Thanks for sharing.
1 of 1 people found this helpful
I report false positives for many alerts where the signature is "too broad" (that's how support describe it), for example a signature that triggers on traffic that could be vulnerable to an exploit but where the signature can not actually detect any exploit. These usually generate large volumes of alerts for legitimate traffic.
As per Davids response you need to look at the signature to see what it matches on, and then look at the individual alerts to see what part of the signature they matched, and determine if it is a false positive or just a poorly written signature.
As the signature is not always available you may need to contact support for more information.
We will always try to have support correct a signature rather than just disable it or create an exception for it, as this means we don't have to keep track of it and retest it ever time it's modified.
In instances where we can identify that it is a true false positive caused by our legitimate infrastructure we will normally create an Ignore rule or Firewall rule depending on if it's for a small number of devices or local to one sensor etc.
We disable signatures completely if they are for old CVE's were we do not have any relevant devices or know the vulnerabilities do not exist in our environment.
When reporting false positives to support make sure to give them all of the details listed in the below article and explain to them why you are reporting it as a false positive, it can be a slow process but it's worth having the signatures corrected.