How to Submit a Vulnerability Signature False Positive

Vulnerability signatures are based on the network traffic, hence the focus is on the data that is seen over the network when the signature fires, and it is suspected to be a False Positive. It is of utmost importance to provide the followings:

•  A complete decrypted packet capture that includes the full TCP/UDP transaction and a decent close is included which triggers the signature.
• The current version of the applications and threats package on your firewall.
• The name of the signature and threat-ID
• The threat logs.

Why decrypted packet capture?

• We need the decrypted pcap.  A decrypted pcap can be used to replay in the lab environment to reproduce the issue, also a decrypted packet can also indicate the traffic pattern, 
• This can be done through a variety of means such as through the firewall with Decryption Port Mirroring or on the endpoint itself on Windows and MacOS.
• Please note that for spyware signature type sometimes the extended packet capture is enough, however for the vulnerability signature a full packet capture is preferable. 
• Here is a KB article that explains the custom packet capture for vulnerability signature. 

Why complete packet capture?

• Vulnerability signature false positive investigations need the packet capture provided by a customer. PaloAlto technical support reproduces the issue by replay the packet capture in the lab.
• The complete packet capture also provides additional 'context' when determining whether the alert is a false positive.
• The extended 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.

Steps

1. Current app and threat version: 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. That will indicate the current app and threat version.
2. Threat logs: 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 the data available in your threat logs. Go to WebGUI > Monitor > Threat.
3. Once a reliable source and/or destination of the offending traffic has been identified, 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! Full packet capture can be generated by filtering the specific traffic, Here is a KB article that explains the custom packet capture for vulnerability signature.  For reference and assistance on the PAN-OS packet capture process, please see this link.
4. Threat-ID: 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. 
5. 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.