[Owasp-modsecurity-core-rule-set] Current use of TAG data in rules and a new idea - CONFIDENCE_LEVEL

Ryan Barnett RBarnett at trustwave.com
Fri Apr 15 10:15:30 EDT 2011

Hey everyone,
I wanted give an overview of the current use of TAG data in rules (https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#tag), as well as, to get some feedback on some new ideas for tag usage.

First let's look at how TAG is currently being used today in the CRS.  Here is an example SQL Injection rule -

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bxp_cmdshell\b" \
          "phase:2,rev:'2.2.0',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,ctl:auditLogParts=+E,block,msg:'SQL Injection Attack',id:'959052',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

The TAG action is used to provide the following information:

 1.  Attack Category – example WEB_ATTACK/SQL_INJECTION
 2.  Mapping to community taxonomies – such as WASC Threat Classification, OWASP Top Ten and OWASP AppSensor Detection Points
 3.  URL links to specific reference resources – as in this converted ET sql injection rule that lists a link to a SecurityFocus vuln entry

# (2007539) SpiderLabs Research (SLR) Public Vulns: ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp model UPDATE
SecRule REQUEST_LINE "@contains /vehiclelistings.asp" "chain,phase:2,block,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:normalisePathWin,capture,nolog,auditlog,logdata:'%{TX.0}',severity:'2',id:2007539,rev:6,msg:'SLR: ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp model UPDATE',tag:'web-application-attack',tag:'url,www.securityfocus.com/bid/21154'"
SecRule &TX:'/WEB_ATTACK/SQL_INJECTION.*ARGS:model/' "@gt 0" "ctl:auditLogParts=+E,setvar:'tx.msg=%{tx.msg} - ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp model UPDATE',setvar:tx.anomaly_score=+20,setvar:'tx.%{rule.id}-WEB_ATTACK-%{rule.severity}-%{rule.msg}-%{matched_var_name}=%{matched_var}'"

One big idea we have for a new TAG is Confidence Level which would give a general indication as to the rules accuracy level perhaps on a scale of 0-5 where 0 is totally experimental without much testing at all and 5 is a very strong signature that has been rigorously tested and a low chance of false positives.  Example – tag:'CONFIDENCE_LEVEL/5'

The Confidence Level tag seems like it has the potential to have a very positive impact to users for two reasons:

 1.  Currently, there isn't much distinction for each rules as to its accuracy level.  We do have the experimental_rules directory for brand new rules however that does not mean that other rules are all of equal accuracy levels.
 2.  With the new v2.6 enhancement which added SecRuleRemoveByTag and ctl:ruleRemoveByTag (https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecRuleRemoveByTag) users will then have the ability to make local customizations to disable entire groups of rules based on TAG data :)  For instance, if you wanted to only run CONFIDENCE_LEVEL/5 rules you could do that in a local custom rules file modsecurity_crs_60_custom_rules.conf to disable all lower confidence level rules –

SecRuleRemoveByTag "CONFIDENCE_LEVEL/[0-4]"

While this is a great new capability – we will need some help from the community with identifying the right CONFIDENCE_LEVEL settings for each rule.  I will go through each rule and estimate a CONFIDENCE_LEVEL based on our intel.  This may not be enough however.  I have a feeling that most ModSecurity users silently handle false positives with local exceptions and they do not also report back to the community which rule IDs are causing problems.  Some users do go the extra mile and actually open Jira tickets for the CRS with bug reports.  That is great and it ensures that I will review/update the rules.  I do think, however, that most end users would prefer an easier method.  What do you all think about us creating a new mail-list on SourceForge strictly for sending in false positive rule issues?  We could create something like - mod–security-false-positives at lists.sourceforge.net.

What do you think?  If anyone has any better ideas for false positive reporting, please speak up.


This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

More information about the Owasp-modsecurity-core-rule-set mailing list