Rules Priority

DataSunrise provides an intelligent way of managing Rules triggering sequence to efficiently capture targeted information within your database. Whilst maintaining this level of focus, DataSunrise eliminates redundant execution and/or generation of audit records by the same Rule module twice, so that should be kept in mind when ordering the priority of overlapping Rules (if any).

To that extent, DataSunrise will always opt for the first Rule in the priority order listing, which of course can be changed as per your requirements

DataSunrise’s engine operates in a way that would capture all parts of a complex query in sequence to enforce granular security monitoring; hence it would generate multiple Audit Trails that relate to multiple overlapping Rules of different severity levels, as this might be essential for enforcing notifications and/or alerts for certain activities in complex queries that require specific attention, not the others of higher priority or vice versa.

Audit Rules Priority Management in DataSunrise:

In the following example, we demonstrate how DataSunrise will process the priority of Audit Rules with overlapping subjects.

1. The following list of Rules contains Audit Rules for auditing ALL database activities in an Oracle database, yet as it is clear from the naming that the configuration has been done in a way that some queries might match the triggering criteria in every and each one of them:
   1. 1st_EmployeesTable: this Rule is created to audit the Employees table (of the HR schema) level activities.
   2. 2nd_auditHRschema: this Rule is created to audit the schema level activities.
   3. 3rd_audit_ORCL_db: this Rule is created to audit any activities in the entire database.
   4. QueryTypes: this Rule is created to audit ALL sorts of query types other than SELECT.
2. I’ve run two SQL Statements (one fairly simple and the other quite composite):
   • Those two SQL statements have resulted in the following Audit Trails (one trail for the 1st query and three trails for the 2nd query):
   • The first query technically qualifies to trigger all the first three Rules, being:
     1. EMPLOYEES table (Rule# 1).
     2. member of the HR schema (Rule# 2).
     3. an in the database (Rule# 3).

     Yet it only generates Audit ID# 1 as we can see from the results below and the reason for that is that one part of that query requires Audit focus which is the SELECT on the EMPLOYEES table, so give that no other parts of that query triggers any further Rules, none will be triggered.

     
   • Yet on the other hand, the reason for the second query to generate three trails is the fact that DataSunrise’s engine recognizes three components in that query associated distinctly with three different Rules of three different triggering aspects:
     1. The first Rule 1st_EmployeesTable has been triggered by the SELECT statement that involved the EMPLOYEES table from the main CTAS statement (Create Table As Select).
     2. The second Rule 2nd_auditHRschema has been triggered by the JOIN clause in the same SELECT statement from the main CTAS statement that calls another table (DEPARTMENTS) which isn’t being addressed by the first Rule.
     3. The fourth Rule QueryTypes has been triggered by the CREATE clause CTAS statement.

So to sum this all up, if DataSunrise’s engine recognizes multiple components in the query that can distinctly trigger multiple Rules it will do so, unless it was the same component in which case it would only trigger the Rule once as what happened in the first query’s audit trail for SELECT * FROM employees;.

Security Rules Priority Management in DataSunrise:

For Security Rules the same concepts above apply and another consideration in regards to the number of rows affected/fetched shall be considered:

1. The following Rules are achieving two different objectives:
   • The first Rule allows the execution of any query that fetches/affects more than 1 row.
   • The second Rule blocks the execution of any query that fetches/affects more than 10 rows.
2. In that case the first Rule has been given higher priority that the second one, which virtually means that any query that tries to fetch 1 row or more will be allowed to do so regardless of the other Rules that deals with the criteria (number of rows fetched/affected).
3. If we go one step further and enable a third Rule that would block all queries unconditionally, that would cover additional Security criterions other than the focus on the number of rows fetched/affected and in that case regardless of the priority level, DataSunrise will enable the third Rule: