Introducing custom alert policies in Oracle Data Safe

Text Size 100%:

We recently added support for custom alert policies in Oracle Data Safe. This new capability allows you to monitor specific database activities of interest. Custom alert policies reduce the “noise” of unnecessary alerts and strengthen your ability to detect inappropriate or potentially malicious activity.    

Whether it’s detecting unusual access patterns, unauthorized attempts to modify critical data, or anomalous queries indicative of a potential breach, custom alert policies help you proactively identify and mitigate risks before they escalate. You can leverage this new capability to reduce your incident response times.

Custom alert policies allow you to customize what database changes you’d like to be alerted about. The feature lets you tailor a set of rules and conditions to filter out less critical alerts, helping you prioritize and focus on the most relevant and actionable alerts. This targeted approach enables you to focus on genuine threats. An essential component of a proactive security approach, it empowers organizations to prioritize security alerts effectively and enables quicker response to potential threats. 

Data Safe lets you create custom alert policies from the Alert policies page. A hidden gem in this new capability is the ability to create alerts based on actual activity. Starting with the All Activity audit report, you can add filters to the report until you only see the activity you wish would have generated an alert – then just click “Create as alert rule” to transfer those filters into your alert conditions. Refer to the screenshot below to see how you can use the convenience of the All Activity audit report to create a custom alert policy with conditions from filtered event attributes and values of the audit report.
 Custom alert policy from audit reports
Figure 1: Creating custom alert policy from audit reports in Data Safe

You can view and manage custom alert policies from the Alert Policies page within Security Center in Data Safe. Refer to the screenshot below for a sample custom alert policy created with several distinct alert rules, each tailored with unique filtering criteria and organized into logical groups corresponding to the configured security controls.

 Sample custom alert policy with distinct alert rules
Figure 2: Sample custom alert policy with distinct alert rules

Read on if you’d like to see an example of using the new custom alert feature in combination with other database security features. In this next section, we explore the potential of custom alert policies with a real-world use case in which you, as a security administrator, are tasked with protecting application data.

In this scenario, the application schema EMPLOYEESEARCH_PROD hosts sensitive information for an internal HR application. The application accesses data in the schema through a service account. In addition to the service account, various privileged users (DBAs) access the database for administrative tasks and maintenance activities. 

To protect the data, you are implementing a combination of three database security controls: Oracle Database Vault, Unified Auditing, and Data Safe, as shown in the screenshot below.
•    Database Vault will block privileged user access to data
•    Unified audit will capture a record of access to data from outside of normal application activity
•    Data Safe will retrieve the audit data for secure storage, analysis, reporting, and (most important to this use case) alerting of suspect activity

 Data Protedtion
Figure 3: Data protection strategies


Block application data access from privileged users and administrators

We will place the application schema in a Database Vault realm to protect all objects in the EMPLOYEESEARCH_PROD application. Only the EMPLOYEESEARCH_PROD schema owner is authorized to access the realm objects. 

A unified audit policy will audit any violation of realm access. 

 Block application data access from privileged users and administrators
Figure 4: Security controls to block application data access from privileged users and administrators

The table in the blog’s reference section provides the commands for creating the Database Vault realm and the unified audit policy.

With these protections in place, an application accessing the database with the application service account EMPLOYEESEARCH_PROD can access all the objects within the schema. However, privileged users like database administrators with DBA roles, though they can perform their normal administrative tasks and responsibilities, cannot view the application data in the EMPLOYEESEARCH_PROD schema. Their access attempts raise a Database Vault realm violation, which is audited, and the event is recorded in the unified audit trail.

Data Safe is configured to collect the audit records from the database. Data Safe collects the realm violation audited records, and an alert rule in the custom alert policy is configured to trigger a security alert, as shown below.

 Custom alert policy rule on DV violations
Figure 5: Custom alert policy rule to alert on Data Vault realm violations

Block application credential misuse

To prevent the misuse of EMPLOYEESEARCH_PROD application service account credentials, we use another Database Vault feature, command rules. We configure a command rule to allow the CONNECT command to be executed from only authorized entry points. A rule set to authorize JDBC Thin Client and its associated endpoint is created and added as an authorized entry point for CONNECT command execution.  A unified audit policy is also designed to track all top-level actions of anyone connecting the database server directly, and this tracks LOGIN attempts, too.

Block application credential misuse 
Figure 6: Security controls to block application credential misuse

The table in the blog’s reference section provides the commands for creating the Database Vault command rule and the unified audit policy.

With this protection in place, a rogue user or developer accessing the database directly with credentials of the EMPLOYEESEARCH_PROD application service account will not be allowed to log in. The login attempt will fail, and again, this failed login event will be audited and recorded in the audit trail with an appropriate error message indicating the command rule violation.

With Data Safe configured to read the audits from the database, It collects the LOGON audited event that failed due to a command rule violation. An alert rule in the custom alert policy is configured to trigger a security alert, as shown here.

 Custom alert policy rule to alert on misuse of application credentials
Figure 7: Custom alert policy rule to alert on misuse of application credentials


Monitor potential data exfiltration attempts

Considering you have authorized the user account DATA_PUMP_USER  to perform Oracle Data Pump operations on the EMPLOYEESEARCH_PROD application schema in the Database Vault-enabled instance, a unified audit policy tracks the export activity to detect any malicious attempt to exfiltrate sensitive application data.

Monitor potential data exfiltration attempts 
Figure 8: Security control to monitor potential data exfiltration attempts

The table in the blog’s reference section provides the commands for granting authorization and the unified audit policy.

Data Pump’s export operation is recorded in a unified audit trail with this protection. Data Safe will collect this, and an alert rule in a custom alert policy is configured to trigger a security alert to bring it to the attention of security administrators, as shown here.

 Custom alert policy rule to alert on Data Pump operation activity
Figure 9: Custom alert policy rule to alert on Data Pump operation

With the database security controls in place and Data Safe configured to collect audit events and trigger alerts based on tailored conditions in different rules within the custom alert policy, you can get visibility into activities accessing the application schema outside the normal application activity. You can also gain valuable insights into the pattern of such access attempts, as shown below.

Custom alert policy rules with insight into access pattern 
Figure 10: Custom alert policy rules with insight into access pattern

The first alert rule, Database Vault Realm violation on application schema, triggers a security alert if a realm violation occurs, indicating potential unauthorized attempts to access application schema objects.

The second alert rule, Direct database access attempts by application schema owner, triggers a security alert if realm-authorized application account credentials have potentially been misused to attempt logging into the application database directly, bypassing the authorized application trusted paths.

The third alert rule, Data pump export attempts on application schema objects, triggers a security alert if there is any Data Pump export activity on the application schema. Observing this crucial activity can deter malicious attempts to exfiltrate application data.

With the single custom alert policy to trigger a security alert for any anomalous or note-worthy events in the database, you can further integrate with contextual notifications in Data Safe to proactively notify the HR application database administrator to take appropriate measures. Consider creating fine-grained alert reports filtered with these alert rules to demonstrate compliance.

In a nutshell, we explored the transformative impact of custom alert policies capability that can help organizations adopt a proactive and data-driven approach to strengthen their security posture. 

To see the demo of the configuration and custom alert policies in action, refer to the this video.

Reference

Refer below for an insight into the Database Vault and unified audit policy configurations for the three security control use cases outlined in this blog:

Table 1; Examples of commands used in this blog
Block application data access from privileged users and administrators 

 —-To create Database Vault realm—-
DVSYS.DBMS_MACADM.CREATE_REALM(
   realm_name => ‘PROTECT_EMPLOYEESEARCH_PROD’
  ,description => ‘A mandatory realm to protect the EMPLOYEESEARCH_PROD schema.’
  ,enabled => DBMS_MACUTL.G_YES
  ,audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL
  ,realm_type => 1); 

 —-To add application objects into Database Vault realm—-
DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM(
   realm_name => ‘PROTECT_EMPLOYEESEARCH_PROD’
  ,object_owner => ‘EMPLOYEESEARCH_PROD’
  ,object_name => ‘%’
  ,object_type => ‘%’); 

—-To authorize user into Database Vault realm—-
DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM(
   realm_name => ‘PROTECT_EMPLOYEESEARCH_PROD’
  ,grantee => ‘EMPLOYEESEARCH_PROD’
  ,rule_set_name => ” 
  ,auth_options => ‘1’ ); 

—-To create audit to track Database Vault realm violation—-
CREATE AUDIT POLICY dv_realm_employeesearch
      ACTIONS COMPONENT=DV Realm Violation ON “PROTECT_EMPLOYEESEARCH_PROD”;
AUDIT POLICY dv_realm_employeesearch;

Block application credential misuse

    — To create the rule “Application Connection” —DVSYS.DBMS_MACADM.CREATE_RULE(
  rule_name => ‘Application Connection’
, rule_expr => ${RULE_EXPR});
–Make sure to set the RULE_EXPR to allowed trusted paths

—-To associate the rule set “Trusted Application Path” to the rule “Application Connection”
DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET(
  rule_set_name  => ‘Trusted Application Path’
 ,rule_name      => ‘Application Connection’
 ,rule_order     => 1
 ,enabled        => DBMS_MACUTL.G_YES);

—-To create the Command Rule on Connect for “Application Connection”—-
 DVSYS.DBMS_MACADM.CREATE_CONNECT_COMMAND_RULE(
   user_name    => ‘EMPLOYEESEARCH_PROD’
  ,rule_set_name => ‘Trusted Application Path’
  ,enabled => DBMS_MACUTL.G_YES);

—-To create audit to track direct DB server access—-
CREATE AUDIT POLICY direct_db_access ACTIONS ALL WHEN ‘(SYS_CONTEXT(”USERENV”,”IP_ADDRESS”) IS NULL)’ EVALUATE PER SESSION ONLY TOPLEVEL;
audit policy direct_db_access;

Monitor potential data exfiltration attempts 

— To authorize DATA_PUMP_USER account to perform Oracle Data Pump operations on EMPLOYEESEARCH_PROD application schema in Database Vault enabled instance—–

DBMS_MACADM.AUTHORIZE_DATAPUMP_USER(‘ DATA_PUMP_USER ‘,’EMPLOYEESEARCH_PROD’);

—To create an audit policy to track Data Pump export activity—
create audit policy audit_dp_export_pol ACTIONS COMPONENT=DATAPUMP EXPORT;
audit policy audit_dp_export_pol;

 
If you would like to try the use case, consider the following steps:

•    Configure the HR application schema and the database Vault following this Database Vault LiveLab 
•    Create audit policies as outlined in the table above
•    Discover the target and start the audit collection in Data Safe 
•    Get started with creating custom alert policies as outlined in the blog

Additional links: 
•    More information about Oracle Data Safe
•    Documentation for Oracle Data Safe

Angeline Dhanarani

Senior Principal Product Manager, Oracle Database Security

Angeline Dhanarani is the Senior Principal Product Manager in the Oracle Database Security team, responsible for core database audit and activity monitoring capabilities in Oracle Data Safe. With 20+ years of experience, Angeline is involved in many customer engagement activities for over a decade at Oracle, and is responsible for all Database Security features and products for regions -APAC and Japan. Angeline helps Oracle customers adopt comprehensive database security strategies and closely works with the engineering team to define the product roadmap for audit and activity monitoring.