More PCI Confusion: How Should WAFs Handle ASV Traffic?

Submitted by Ryan Barnett 8/27/2008

I have previously discussed the importance of sharing data between code reviews, vulnerability scanning and web applications firewalls. The main issue being that these three processes/tools are usually run by three different business units - development, information security and operations staff - and they don't all share their output data with each other. The issue of sharing output data, however, is putting the cart before the horse. When looking at vulnerability scanning, you need to first decide what the goal of scanning is and then you can select the appropriate WAF configuration for handling the traffic.

What is the ASV Scanning Goal?
There seems to be two different goals that ASVs may have for scanning; 1) To identify all vulnerabilities within a target web application, or 2) To identify all vulnerabilities within a target web application that are remotely exploitable by an external attacker. You may want to read that again to make sure that you understand the difference as this is the point that I will be discussing for the remainder of this post.

Identifying Underlying Vulnerabilities
This is a critical goal to have when scanning. If you can identify all of the existing vulnerabilities, or at least those which can be identified by scanning, you can then formulate a remediation plan to address the issue at the root cause. Remediation should include both source code fixes and custom rules within a WAF for protection in the interim.

WAF Event Management
From a WAF administration perspective, it is important to have proper configuration so as to allow for the vulnerability scanning goal while simultaneously not flooding the alert interfaces with thousands of events from ASV traffic. This data may impact both the overall performance of the WAF and it may skew reporting outputs that include raw attack data.

Option #1 - Whitelist the ASV Network Range
In order to identify all of the actual vulnerabilities, you will need to allow the ASV to interact completely with the back-end web application.

Pro(s)

• Identification of vulnerabilities and information leakages within the web application
• From a WAF event management perspective, this configuration will eliminate alerts generated by the scans

Con(s)

• Reduces the true accuracy of the scans as it does not simulate what a “normal” attacker would be able to access since the WAF is not blocking inbound attacks and outbound information leakages such as SQL Injection error messages which attackers use to fine tune their attacks.
• PCI QSAs may interpret these scan results in a negative way if the WAF blocking aspect is not considered as a compensating control in Requirement 6.6.

Option #2 - Treat ASV Traffic Like Any Other Client
Pro(s)

• Gives a truer picture of what an attacker would/wouldn’t be able to exploit since the WAF is providing its normal protections.

Cons(s)

• Vulnerabilities within the web application may not be identified and therefore are not being remediated through other means.
• This configuration will generate tons of alerts especially if the scan frequency is high (daily).

Option #3 - Run Before and After Scans
If you coordinate with your ASV, you could conduct 2 different scans – one when the ASV range is whitelisted and one without.

Pro(s)

• It allows for the identification of vulnerabilities.
• This is advantageous as it shows the immediate ROI of a WAF as a compensating control for PCI.

Con(s)

• It is important to note and be aware that if you take this approach that you need to make sure that your QSA knows and does NOT only look at the whitelisted scan data.

Option #4 - Use a Block but Don't Log Configuration for ASVs
One other option you might want to consider and is a “Block but don’t log” configuration which is a hybrid approach that is suitable for day to day use. With this setup, you allow the WAF to block requests/responses when it sees attacks but it will then inspect the IP address range and if it is coming from an ASV it will not generate alerts. To me, this the best approach for day to day scanning as anything that pops up in the ASV scan reports is something that the WAF did not block and should be addressed.

Some ASVs Arguing that a WAF Shouldn't Ever Block Them
I have run into an interesting webappsec scenario while presenting on PCI at conferences (such as the recent SANS What Works in Web Application Security Summit in Vegas). The attendees have started complaining that many ASVs are requiring that organizations only use the whitelist approach so that the vulnerability scans will pass directly through the WAF and interact with the back-end web application unencumbered. The ASVs are citing the following section in the PCI Security Scanning Procedures document -

13. Arrangements must be made to configure the intrusion detection system/intrusion prevention system (IDS/IPS) to accept the originating IP address of the ASV. If this is not possible, the scan should be originated in a location that prevents IDS/IPS interference

Obviously, these ASVs are lumping WAFs in with network IDS/IPS devices in this context. In reading this section, it seems to me that the real intent of this setting is that organizations should not "cheat" and configure these devices to automatically block or disrupt (with TCP Resets) connections coming from the ASV range based SOLELY on the IP address. This would not allow the scanning to inspect the site at all. Basically you can not blacklist the ASV IP range. This makes sense as this configuration would make the vulnerability scan reports come up clean but it would not be a realistic picture of what a real attacker would be able to access.

What About VA + WAF Integration?

What is frustrating with this whitelisting hard line stance is that this approach effectively negates the valuable Vulnerability Assessment + WAF Integration efforts that have recently appeared - most notably between Breach and Whitehat Security. If a WAF is not allowed to block requests coming from an ASV, then how are the ASV reports ever going to show that the issues has been remediated by a virtual patch?

Look at the following sections for PCI Requirement 11.2 –

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). Note: Quarterly external vulnerability scans must be performed by a scan vendor qualified by the payment card industry. Scans conducted after network changes may be performed by the company’s internal staff.

11.2.a Inspect output from the most recent four quarters of network, host, and application vulnerability scans to verify that periodic security testing of the devices within the cardholder environment occurs. Verify that the scan process includes rescans until “clean” results are obtained

11.2.b To verify that external scanning is occurring on a quarterly basis in accordance with the PCI Security Scanning Procedures, inspect output from the four most recent quarters of external vulnerability scans to verify that • Four quarterly scans occurred in the most recent 12-month period • The results of each scan satisfy the PCI Security Scanning Procedures (for example, no urgent, critical, or high vulnerabilities) • The scans were completed by a vendor approved to perform the PCI Security Scanning Procedures

Notice the bolded sections. The problems that the organizations are encountering is that if they do indeed whitelist the ASV IP addresses, then the resulting scan reports will show vulnerabilities that a real attacker would most likely not be able to exploit because the WAF would be in blocking mode for them or they have implemented a virtual patch. So, if a QSA looks at the ASV scans and sees a bunch of urgent/critical/high vulns (SQL Injection, XSS, etc…) then the organization may fail this section. :(

Clarifications Needed

I believe that the PCI Security Counsel needs to update the text in the ASV Scanning Procedures guide to make it more clear how WAFs should be configured in relation to PCI scanning. As the very least, they should clarify the original intent of that text (as I stated previously I believe it was to prevent sites from blacklisting the ASV address ranges).

I am interested in hearing peoples experiences with this situation. What have ASVs told you? How do you configure your WAFs to handle ASV traffic?