Web Application Firewalls (WAF) often produce millions of detected SQL Injection events each day. As security professionals we are obviously concerned about the success of such attacks, but struggle to sift through such high volumes of activity (see Image 1) that have a high prevalence of false positives. Here are a few ways you can successfully derive value from your SQL Injection events.
(Image 1: OWASP Events Detected in a 24-hour period)
Most WAFs use the ModSecurity Core Ruleset to generate events. These rules are identified by a six-digit number to make identification simpler. There are many rules that identify various behaviors indicating a SQL injection attack, including any rule that starts with the numbers “942” and “981”. Thus, the simplest – though not necessarily the smartest – action you can take is to simply block all SQL injections attacks as identified by those numbers. However, there is risk in this approach as many of the rules generate huge amounts of false positives and you risk blocking legitimate web traffic, thus potentially losing sales and revenue.
What many organizations do is set a rule to monitor and alert on these events, rather than blocking. The logic behind this is clearly to avoid the false positive impact as well as the fact that most SQL injection attacks fail as it is. The challenge is to identify the ones that either are successful or have the highest likelihood for success.
One strategy that you can employ to do this is to only alert on those rules that have a low propensity for false positives. This can be difficult to determine, but there are a few online resources by WAF experts and researchers who have attempted to make this differentiation, located here and here. (Note: We cannot verify the validity of these assessments). Any rule that is identified as a frequent false positive or very frequent false positive should be left out of your alert.
An alternative strategy is to continue to generate alerts on all SQL injection rules, but score them as low on your criticality rating scale. Thus, they would only get looked at and analyzed if they correlate with other alerts in your system. One simple example would be a circumstance where an IP address that is listed on a high-value blacklist or threat intelligence feed conducts a SQL injection attack on your website. This would bring together both a reputation alert and the SQL injection alert, thus increasing the criticality of the overall correlated alert.
Even with these above strategies there is the potential for either too many alerts for your SOC to triage or too many false positives. We recommend that you evaluate your logs and events and find additional ways to cut down the noise. It may be simply applying the above strategies and staying diligent in refining your alert rules until they are tuned properly. Regardless, you can make your SQL injection events useful to your security monitoring and understanding what is happening to your web applications.
About Security On-Demand
Security On-Demand (SOD) provides full-spectrum threat management and advanced cyber threat detection services for hundreds of businesses and government agencies globally. SOD’s patented, behavioral-analytics ThreatWatch technology enables the detection of advanced threats to protect brand value and reduce the risk and mitigate the impact of a data breach. SOD is headquartered in San Diego, CA with international R&D offices and a Security Operation Center in Warsaw, Poland.
