When submitting a vulnerability false positive report, preemptively gathering data to attach to the case will result in a quicker turn around time.
Vulnerability false positives are handled differently than virus false positive reports; while virus false positive investigations usually involve inspection of the offending file, vulnerability false positives focus almost entirely on the data that is seen over the network when the signature fires.
It is for that reason that it is of the utmost importance that complete packet captures be obtained. Ideally, a complete packet capture would include the full TCP/UDP transaction which triggers the suspect signature.
Vulnerability signature false positive investigations are almost always troubleshot on the support side by taking a packet capture provided from a customer and replaying that packet capture through a lab firewall to reproduce the problem. The complete packet capture also provides additional 'context' when determining whether the alert is a false positive. Since this is the case, setting packet captures for a specific threat signature ID is not an ideal solution to addressing the false positive, as the packet capture will begin to capture midway through an offending session. This will result in a packet capture that lacks session creation (SYN / SYN ACK / ACK) which cannot be properly replayed without being doctored.
Collect the output of "show system info" from the CLI of your firewall, or copy the "General Information" pane from the Dashboard of your WebGUI. Put this in the case.
Identify a method of reproduction for the issue. This may involve interaction with either the host or server generating the traffic that triggers a signature, or less direct methods of identifying a common source/destination/time of day for when the signature regularly triggers. This can be accomplished by evaluating data available in your threat logs. Go to WebGUI > Monitor > Threat.
Once a reliable source and/or destination of the offending traffic has been identified, a packet capture can be created. This can be done in any number of ways a network administrator is comfortable with: - Host based packet captures on the client/server are fine, so long as they include the full session creation and traffic which generates the signature (Wireshark and TCPDUMP are two examples.) - Packet capture from the PAN-OS appliance is also a possibility! A full packet capture can be generated by creating filters for the source or destination of the traffic, setting the staging (firewall, drop, transmit, receive), enabling filtering, and then enabling the capture. For reference and assistance on the PAN-OS packet capture process, please see this link.
Please provide the threat ID number being triggered, and the threat name being triggered. Alternatively, a threat log screenshot of the trigger will suffice as well. For example, Threat ID 37001 | Microsoft Internet Explorer Memory Corruption Vulnerability.
Provide context on why it is believed that the signature trigger is a false positive. Some examples might include: - The description of the target operating system/product in the vulnerability signature does not match a product or application in use in the environment. For example, seeing a vulnerability signature trigger that specifies a vendor name, operating system, or application which it is known is not in use on the network (and has been confirmed as not being in use.) - The traffic was analyzed internally to be safe before being reported.
Once all of this data has been gathered and placed in the support case, the packet capture can be analyzed and a verdict and possible fix can be reached.