Separating False Positives from Legitimate Violations

Imagine you make yourself a cup of tea and now want to extract the tannins and caffeine from the homogeneous mixture. How do you do it? Similarly, when building and protecting applications, you brew a blend of legitimate violations and false positives (distinct substances with similar properties) that match the rules you have defined in your web application firewall (WAF). How do you separate the false positives from legitimate violations?

Before you decaffeinate your tea, let’s review some context around false positives and the challenges they pose in application security. False positives occur when legitimate requests are identified as attacks or violations. Due to the complex nature of web applications, false positives are a normal aspect of application security. It is preferable for a WAF to trigger false positives than to allow false negatives (attacks perceived as legitimate traffic). However, reducing the rate of false positives without compromising application security remains a significant challenge for security professionals.

A high false positive rate has the following disadvantages:

· Obstructs legitimate traffic

· Increases maintenance

· Burdens computer resources

One way to extract the caffeine from your tea, chemically, is to introduce a solvent to neutralize the caffeine. Similarly, separating false positives from legitimate violations require the introduction of a solvent, of sorts, to neutralize the false positives among all the legitimate violations found in our WAF log.

The challenge is designing the so-called solvent. Applications are unique and require a deep understanding of architecture, business flow and also your configured WAF rules in order to define the necessary properties for each so-called solvent.

For example, using ‘square brackets in parameter name’ as a so-called solvent, is a common practice in the Drupal application development, yet many default WAF rules will flag it as a violation and trigger the false positive.[1] Christian Folini, https://www.christian-folini.ch

You should also consider other volumetric and statistical factors such as violation type, volume, and density when you design your so-called solvent. Generally 3 components are taken in consideration : 

• Traffic: What are the characteristics (origin, destination, frequency, payload ...) of the traffic (HTTP Request/Response) that triggered the violation ?.
• Violation: What are the characteristics (Type of attack, Rule triggered , ) of the violation triggered ?.
• Application: What are the characteristics of the application that is processing the request ?.  

Once you have subtracted false positives, you can correct your WAF configurations and monitor for new violations, then repeat the process.

The workflow looks like the following:

1. Design a solvent.

2. Sample web traffic and log all violations.

3. Apply all violations to the solvent.

4. Use analytical extraction or manual extraction to subtract false positives.

5. Correct your WAF with Rules Exclusion for the identified false positives.

6. Monitor both web traffic and application changes.

7. Repeat steps 1 through 6.

As solvent properties are specific to applications, in the next article, we'll provide additional example of solvent properties for the most popular applications.