How Should WAFs Handle Authorized Vulnerability Scanning Traffic?

How Should WAFs Handle Authorized Vulnerability Scanning Traffic?:

I have been asked this question more and more over the years as organizations are dealing with both external vulnerabilty scanning as part of requirements such as PCI and intenal scanning efforts.  The short answer to this question is: it depends on your exact circumstance.  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 Vulnerability Scanning Goal?

There seems to be two different main goals for scanning;

1. To identify vulnerabilities within a target web application, or
2. To identify 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 using dynamic application security testing (DAST) methods, you can then formulate a remediation plan to address the issue at the root cause in the source code. Remediation should include both source code fixes and custom rules within a WAF for protection in the interim.

Identifying Remotely Exploitable Vulnerabilities

If you have deployed a WAF in front of all access paths to the application (meaning both from external user and from internal users) and it is in a blocking mode, then it is reasonable to view it as part of the web application itself.  This means that if the WAF is configured to block web application attacks such as SQL Injection, Cross-site Scripting or is implementing specific virtual patches for prevoiusly identified vulnerabilities, then it should stay configured this way during web application assessments.  Why?  This is the only true way to gauge the effectiveness of the WAF used as a compensating control.  If an attacker would have to deal with bypassing a WAF, why shouldn't a web assessment tool or team?  On the flip side, if the scanner or assessment team is able to bypass the WAF, you would certainly want to know that as well so that configuration updates may be made to virtual patches.

Whitelisting vs. Blacklisting Authorized Scanners

Depending on your scanning goal mentioned previous sections, you then need to consider whether you want to allow the scanning traffic to bypass your WAF inspection entirely.  If you fall under to PCI umbrella, then your ASV has probably referenced 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, ASVs are lumping WAFs in with network IDS/IPS devices in this context. In reading this section, 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.
From a WAF perspective, you should inspect each individual request and perform blocking actions if the payloads violate a policy.  You should not block traffic based on the source.  What does this mean in practical terms?  This means that if the WAF sees an SQL injection attack, block the request.  The WAF should not, however, implement any type of automated IP address blacklisting due to request velocity violations (such as DoS, Brute Force, etc...).

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.  Also consider this - when doing standard WAF reporting metrics, you may not want to include authorized scanning traffic within your results and instead focus on real attack data.

WAF Configuration Examples

The latest version of the OWASP ModSecurity Core Rule Set (CRS) includes an authorized scanning configuration file.  Let's turn our focus to some actual example configurations.

Option #1 - Whitelist Authorized Scanning Network Range

In order to identify all of the actual vulnerabilities, you will need to allow the vulnerability scanning host to interact completely with the back-end web application by whitelisting the scanning source. The advantages of this approach are twofold:

• 
  First, you will have the best chance to identify all of vulnerabilities and information leakages within the web application, and
• 
  Second, from a ModSecurity event management perspective, this configuration will eliminate alerts generated by the scans.

The downside of this approach is that it reduces the true exploitability 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.
Note - if you implement this for PCI ASV scanning, make sure that your QSA is aware of this configuration.  This should be discussed when reviewing Requirement 6.6 WAF configurations.

Option #2 - Compare Whitelisted vs Normal Scan Results

If you coordinate your scanning schedules, you could conduct 2 different scans – one when the scanning range is whitelisted and one without.  The advantages of this approach are that it allows for the identification of vulnerabilities while simultaneously demonstrating the coverage provided by the WAF.  The only downside to this approach is that you must run multiple scans.  When conducting the second scan however it is possible to run only a "revalidation" scan where only vulnerabilities identified from the initial whitelisted scan are rechecked.

Option #3 - Block but Don't Log Configuration

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 authorized scanning source it will not generate alerts. To me, this the best approach for day to day scanning as anything that pops up in the scan reports is something that the WAF did not block and should be addressed.

If you have other WAF configurations that you use during authorized scanning, let me know.  I am intrested to see how others are handling this scenario.