I will investigate the idea of a rule mapping, but keep in mind that following -
1. One of our goals with the update is to make the rule accuracy better (less false positives). So, just because a specific rule is currently a false positive and you chose to add an exception to disable it, that does not mean that you would need to keep the exception with the new version of the rule. 2. ModSecurity v2.7 (will be released very soon) has the new "accuracy" and "maturity" actions. This will allow us (Trustwave) to give a relative score for each of these settings. This will help you to decide which rules to run default or not. 3. As for directory structure groupings, it is my belief that all rules in the "base_rules" directory should have a very high quality of accuracy (low FP rate). If a user wants to get more aggressive with detection, then they will be able to activate other rule files under the "experimental_rules" directory in which the accuracy/maturity values would be lower. -Ryan From: David Sinclair <dbsincl...@multiservice.com<mailto:dbsincl...@multiservice.com>> Date: Wed, 6 Jun 2012 10:28:01 -0500 To: Ryan Barnett <rbarn...@trustwave.com<mailto:rbarn...@trustwave.com>>, "owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>" <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>> Subject: RE: [Owasp-modsecurity-core-rule-set] [Rule Update - Discussion Thread]Updating Rule IDs I think it is a good idea to better group the rules but it will require an extensive review of rule exceptions. If there is a mapping available from the old id to the new id for those rules that are reassigned that would be very helpful and reduce the review effort. David B. Sinclair Security Manager Multi Service Corporation +1-913-663-9474-w +1-816-718-0449-m dbsincl...@multiservice.com<mailto:dbsincl...@multiservice.com> ________________________________ From:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org> [mailto:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org>] On Behalf Of Ryan Barnett Sent: Wednesday, June 06, 2012 9:24 AM To:owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org> Subject: [Owasp-modsecurity-core-rule-set] [Rule Update - Discussion Thread]Updating Rule IDs One of the items we are considering with the CRS v3.0 update is to start from scratch with all of the rule IDs. We have a defined range reserved for the OWASP CRS - https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#id 900,000–999,999: reserved for the OWASP ModSecurity Core Rule Set [12]<http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project> project The rationale for this change is to make it easier to users to do exceptions and disable groups ofrules by using SecRuleRemoveById, etc… That directive has the capability to remove ranges of rule IDs, however over the years the rule IDs were added ad-hoc and they are not properly grouped in this manner. For instance, groupings could be something similar to this - * Protocol Violation – 900000-900099 * Protocol Policies - 900100–900199 * Cross-site Scripting - 900200–900299 * … We would give each rule group approx 100 rule IDs. The initial number would be less than thatwhich would allow some growth. After some analysis of the current rules, we really shouldn't ever exceed those allotments as there ends up being rule logic duplication and you just end up with bloated rule amounts. Keep in mind that the active rule IDs were going to change a bit anyways with this update as we will be consolidating many rules into highly optimized regexes, etc.. The only concern that I have with making this move would be if users have extensively implemented exceptions based on the current rule IDs. They would need to be aware of this when they migrate to v3.0. Comments? -- Ryan Barnett Trustwave SpiderLabs ModSecurity Project Leader OWASP ModSecurity CRS Project Leader ________________________________ 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. --------------------------------------------------------------------------------------- This email is intended solely for the use of the addressee and may contain information that is confidential, proprietary, or both. If you receive this email in error please immediately notify the sender and delete the email. --------------------------------------------------------------------------------------- ________________________________ 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.
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
