One important alert management issue for security analysts to deal with was that of prioritization. From an incident response perspective, many ModSecurity/CRS users were having a difficult time figuring out which alerts they needed to fully review and follow-up on. This is especially true if running ModSecurity in DetectionOnly mode - as you may get alerts but you are not actively blocking attacks or information leakages. This blog post outlines out the OWASP ModSecurity CRS uses inbound/outbound correlation of events to prioritize events.
If you are running the OWASP ModSecurity CRS in Anomaly Scoring Mode, then you have the added advantage of correlating rule matches to achieve more intelligence about transactional issues.
Here is the following information related to standard Severity ratings->Anomaly Scoring in the main configuration file:
## -=[ Anomaly Scoring Severity Levels ]=-## These are the default scoring points for each severity level. You may# adjust these to you liking. These settings will be used in macro expansion# in the rules to increment the anomaly scores when rules match.## These are the default Severity ratings (with anomaly scores) of the individual rules -## - 2: Critical - Anomaly Score of 5.# Is the highest severity level possible without correlation. It is# normally generated by the web attack rules (40 level files).# - 3: Error - Anomaly Score of 4.# Is generated mostly from outbound leakage rules (50 level files).# - 4: Warning - Anomaly Score of 3.# Is generated by malicious client rules (35 level files).# - 5: Notice - Anomaly Score of 2.# Is generated by the Protocol policy and anomaly files.#SecAction "phase:1,t:none,nolog,pass, \setvar:tx.critical_anomaly_score=5, \setvar:tx.error_anomaly_score=4, \setvar:tx.warning_anomaly_score=3, \setvar:tx.notice_anomaly_score=2"
This means that the highest severity rating that an identified inbound attack can have is 2 (Critical). In order to have a higher Severity rating (1 or 0) you need to use correlation. At the end of both the Request and Response Phases, the CRS will save the final rule match message data.
After the transaction has completed (in phase:5 logging), the rules in the base_rules/modsecurity_crs_60_correlation.conf file will conduct further post-processing by analyzing any inbound events with any outbound events in order to provide a more intelligent/priority correlated event.
If an inbound attack was detected and either an outbound application status code error or infoleak was detected, then the overall event severity is raised:
Let's look at an example SQL Injection attack scenario. If an attacker sends inbound SQL Injection attack payloads and the application responds normally, then you would see a ModSecurity alert message similar to the following:
[Fri Mar 11 01:57:45 2011] [error] [client 204.13.200.248] ModSecurity: Warning. Operator GE matched 20 at TX:anomaly_score. [file "/etc/apache2/modsecurity/base_rules/modsecurity_crs_60_correlation.conf"] [line "85"] [msg "Transactional Anomaly Score (score 46): SQL Injection Attack"] [hostname "www.modsecurity.org"] [uri "/demo.testfire.net/bank/login.aspx"] [unique_id "-lF5UX8AAQEAAF1s0sgAAAAQ"]
While this is certainly useful information, this does only indicates that an attacker is probing the application. If, on the other hand, the target application does not properly handle this input and instead returns detailed database error information such as the following then you would want to follow up on that issue and initiate blocking:
An Error Has Occurred
Summary:
Syntax error in string in query expression 'username = ''''.
Error Message:
System.Data.OleDb.OleDbException: Syntax error in string in query expression 'username = ''''. at System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling(OleDbHResult hr) at System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS dbParams, Object& executeResult) at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult) at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior behavior, Object& executeResult) at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method) at System.Data.OleDb.OleDbCommand.ExecuteReader(CommandBehavior behavior) at System.Data.OleDb.OleDbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior) at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) at Altoro.Authentication.ValidateUser(String uName, String pWord) in d:\downloads\AltoroMutual_v6\website\bank\login.aspx.cs:line 73 at Altoro.Authentication.Page_Load(Object sender, EventArgs e) in d:\downloads\AltoroMutual_v6\website\bank\login.aspx.cs:line 33 at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) at System.Web.UI.Control.OnLoad(EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
In this situation, the CRS will correlate the inbound SQL Injection Attack with the outbound SQL Error Leakge and generate an higher level Severity alert message such as the following:
[Fri Mar 11 01:38:56 2011] [error] [client 204.13.200.248] ModSecurity: Warning. Operator GE matched 1 at TX. [file "/etc/apache2/modsecurity/base_rules/modsecurity_crs_60_correlation.conf"] [line "68"] [msg "Correlated Successful Attack Identified: Inbound Attack (9000042-Detects classic SQL injection probings 1/2) + Outbound Data Leakage (SQL Information Leakage) - (Transactional Anomaly Score: 6)"] [severity "EMERGENCY"] [hostname "www.modsecurity.org"] [uri "/demo.testfire.net/bank/login.aspx"] [unique_id "uwabqH8AAQEAAFzSougAAAAV"]
This correlated event provides much more actionable data to a security analyst and allows them to either implement more aggressive blocking mechanisms. This may include blocking all categories of SQL Injection attacks and/or blocking for this particular parameter on the page.
Correlated event analysis helps to greatly expedite the incident response process and allows security operations teams to focus their efforts on actionable situations instead of only inbound attacks.