[Owasp-modsecurity-core-rule-set] anomaly score range

Ryan Barnett ryan.barnett at breach.com
Tue Aug 11 13:50:12 EDT 2009

Ryan Barnett
Director of Application Security Research
Phone: (703) 794-2248
Cell: (703) 269-8998
Breach Security, Inc.
2141 Palomar Airport Road, Suite 200
Carlsbad, CA 92011

On Tuesday 11 August 2009 06:40:43 am Gil Vidals wrote:
> I just installed the latest core rules and I see this anomaly score:
>     SecRule TX:ANOMALY_SCORE "@ge 20" \
> What is the range of the anomaly scores? Does it go from 0 to 100?
> I need help in understanding the score and what to set it to. Currently I
> have it set to 10.
> The only documenation I could find so far is:
> # Uncomment the anomaly sections you wish to use.
> # You should set the score to the proper threshold you would prefer. If
> kept at "@gt 0" # it will work similarly to previous Mod CRS rules and will
> create an event in the error_log # file if there are any rules that match. 
> If you would like to lessen the number of events # generated in the
> error_log file, you should increase the anomaly score threshold to #
> something like "@gt 20".  This would only generate an event in the
> error_log file if # there are multiple lower severity rule matches or if
> any 1 higher severity item matches. #
> # You should also set the desired disruptive action (deny, redirect,
> etc...).
> --Gil

Hey Gil,
Yeah, the OWASP CRS project - Documentation section will need to be filled out 
with this type of information about how the anomaly scoring works.  Side note 
- one benefit of moving the CRS to OWASP is that the project is wiki-based now 
so anyone can help to update the documentation.  So, if anyone wants to help 
out, please jump in!

In previous versions of the CRS, each rule was self-contained.  This means 
that the rule would inspect the specified variable/targets with the operator 
data chosen (usually a regular expression) and then the action list would 
specify both the logging and blocking settings.

The idea with new CRS is that we want the rules to be more collaborative 
meaning that we have decoupled the logging/blocking actions from the rules 
that do the initial inspection.  Most of the inspection rules will issue a 
setvar to increase the TX anomaly score data for the current transaction and 
this score will be evaluated at the last possible request blocking point at 
the end of phase:2.  The scoring numbers are tied to the severity levels of 
the issue.  Take a look at the updated Severity data from the CHANGELOG file -

- Updated Severity Ratings
    The severity ratings in the rules have been updated to the following:
    - 0: Emergency - is generated from correlation where there is an inbound attack and
         an outbound leakage.
    - 1: Alert - is generated from correlation where there is an inbound attack and an
         outbound application level error.
    - 2: Critical - is the highest severity level possible without correlation.  It is
         normally generated by the web attack rules (40 level files).
    - 3: Error - is generated mostly from outbound leakage rules (50 level files).
    - 4: Warning - is generated by malicious client rules (35 level files).
    - 5: Notice - is generated by the Protocol policy and anomaly files.
    - 6: Info - is generated by the search engine clients (55 marketing file). 
The normal web attack categories (such as XSS and SQL Injection, etc...) have 
a severity of 2/Critical and will increase the score by 20 points.  3/Error = 
15 points, 4/Warning = 10 points and 5/Notice is 5 points.

So, what all of this means, in relation to the modsecurity_49_enforcement.conf 
file, is that you can set an anomaly scoring threshold that you deem 
appropriate for your site.  These thresholds can control logging and/or 
blocking.  For instance, let's say that you don't really care about clients 
that are missing 1 or 2 request headers (which is something that is flagged in 
the 21 protocol anomalies file), then you should set your anomaly score at 15.  
This means that if a client violates any 2 of the severity 5 rules, this would 
only amount to an anomaly score of 10.  If, however, they violate any 3 
severity 5 issues, then they would trigger.  In the previous CRS, the XSS/SQLi 
types of rules issued blocking actions so that is why the comment section 
above mentions setting the score to 20.  This would result in an anomaly 
scoring match if *any* severity 2 rule matches.
Another item to consider with anomaly scoring and that is that you can 
actually combine 2 issues together - 

1) Confidence level in blocking
Due to the fact that we have broken out the highly optimized regex, this means 
that we have many more individual rules that could possibly contribute to an 
anomaly score.  This means that the *higher* the anomaly score, the more 
confident you can be that something malicious is being detected.

2) Handling exceptions
If you are running into a false positive match, for say an XSS attack, against 
one particular parameter payload in your app, chances are that the anomaly 
score for it is rather low and is just barely going over it.  An exception may 
be as easy as bumping up the anomaly score by 20 points.  There are other 
exceptions mechanisms (that we will document later on the OWASP site) that are 
easy as well but this is the easiest.

Hopefully this info helps.

Ryan C. Barnett
WASC Distributed Open Proxy Honeypot Project Leader
OWASP ModSecurity Core Rule Set Project Leader
Tactical Web Application Security

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/attachments/20090811/2dc56a01/attachment.html 

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