Understand the basic data security monitoring policy rules

To see the rules included with the basic data security monitoring policy:

1. Go to Protect > Security Policies > Policy Builder for Data.
2. Select the Basic Data Security Policy [template] and click .
3. In the View Policy dialog, click the Rules section. The policy rules and criteria are listed in the table.

Rule 1: XSS

This rule uses regular expression to detect well-known XSS (cross-site scripting) attack patterns in the SQL. Such code, if stored in the database, can be used to attack the WEB-UI. The rule action generates a high severity policy violation.

Rule 2: SQL injection - tautology

This rule uses regular expression to detect a common pattern of SQL injection attack. Expressions such as 1=1 can be used by an attacker to add arbitrary SQL code at the end of improperly formed statements. The rule action generates a high severity policy violation.

Rule 3: SQL injection - denial of service (DoS)

This rule uses regular expression to detect a common pattern of SQL injection attack. Commands such as benchmark can be used by an attacker to overload the database. The rule action generates a high severity policy violation.

Rule 4: SQL injection - side channel

This rule uses regular expression to detect a common pattern of SQL injection attack. The sleep command, when embedded in SQL, can create performance and timeout issues and fail applications. The rule action generates a high severity policy violation.

Rule 5: OS command injection

This rule uses regular expression to detect OS commands and executable code in SQL. Such code, if stored in the database, can be used to attack back-end or front-end systems. The action generates a high severity policy violation.

Rules 1-5 should be tuned to meet the specific needs of a specific environment to reduce false positives. Occurrences of each of these patterns might be an indication of an attack but they can also be legitimate actions on some environments. For example, rule 1 may generate false positives if it is applied to an application where logic intentionally uses many HTML tags in SQL statements. The rule conditions can be tuned to limit the rule to applications where many HTML tags in SQL statements are not expected, therefore SQL statements with HTML tags might indicate an XSS attack. Likewise, 1=1 and similar logic expressions (even 1=0) are widely used in legitimate software. When these rules fire on legitimate operations they can be tuned by adding more criteria in the rules themselves, or in the policy, to distinguish between legitimate and illegitimate operations.

Rule 6: Monitor all database activity for admin users

This rule relies on the pre-defined Guardium group Admin Users to identify and comprehensively log all activities that are performed by those users. The rule uses the LOG FULL DETAILS action, and the group is per-populated with the default admin and certain non-admin users for most supported database types. The group does not contain any custom users with admin privileges that typically exist in production environments. To view admin users activity logged in Guardium, go to Reports > My Custom Reports > Admin Users Activity.

For more information, see Create an Admin Users Activity report.

Rule 7: Monitor all administrative commands

This rule relies on the pre-defined Guardium group Administrative Commands to identify and comprehensively log all activities that contain administrative commands that are listed in the group. The rule uses the LOG FULL DETAILS action, and the group is per-populated with the default administrative commands for most supported database types. To view administrative commands logged in Guardium, go to Reports > My Custom Reports > Administrative Commands Execution.

For more information, see Create an Administration Commands Execution report.

Rule 8: Log a policy violation for repeated failed login attempts

This rule logs a policy violation if five or more failed login attempts are made within a 1-minute time interval. The rule uses the LOG ONLY action. Attempts by a malicious user to repeatedly guess the database password by trial and error might be captured by this rule. To view policy violations logged in Guardium, go to Comply > Reports > Incident Management to view the Policy Violations / Incident Management report. The Access Rule Description field indicates which policy rule triggered the violation.

Rule 9: Log a policy violation if risk-indicative errors are generated

This rule relies on the predefined Guardium group Risk-indicative error messages. This group contains errors typically associated with malicious or unauthorized activities. The rule logs a policy violation when an error in that group occurs. The rule uses the LOG ONLY action. To view policy violations logged in Guardium, go to Comply > Reports > Incident Management to view the Policy Violations / Incident Management report. The Access Rule Description field indicates which policy rule triggered the violation.

Rule 10: Log a policy violation on potential data exfiltration attempts

This rule inspects the number of rows that are returned by the database in response to queries per database session to identify potential data exfiltration attempts. Data ex filtration refers to attempts to move large amounts of data. If the total number of rows that are returned by database for a session reaches or exceeds 1000 within a 1-minute time interval, a policy violation is logged with the LOG ONLY action. To view policy violations logged in Guardium, go to Comply > Reports > Incident Management to view the Policy Violations / Incident Management report. The Access Rule Description field indicates which policy rule triggered the violation.

Rule 11: Ignore heavy traffic load sessions (typically batch jobs)

This rule is designed to filter out traffic from potentially heavy batch jobs to avoid overwhelming the Guardium collector. This rule counts the number of SQL statements that are executed within a session. If the number reaches or exceeds 500 within a 1-minute time interval, the remainder of the session is ignored by using the IGNORE S-TAP SESSION action. The first 500 SQL statements for that session are logged for audit purposes.