View and Manage Alert Policies

Create and Manage Custom Alert Policies

Expand the capabilities of Data Safe Alerts by creating custom alert policies.

Related Topics

Throttled Alerts

Create a Custom Alert Policy From the All Activity Audit Report

You can leverage the convenience of Audit reports to create custom alert policy. Apply the filters in the All Activity report to narrow down the conditions for alerting and create a new custom alert policy based on the filtered conditions.

To create a custom alert policy:

Under Security center, click Activity auditing.
Under Related resources, click Audit reports.
Select the All activity report from the list.
Use basic or advanced filtering to filter the all activity report as desired for the alert policy.

Tip:
Don't create filters that only apply to specific target databases or times as this will cause errors when creating the policy.

See the Alert condition supported fields table below for the list of valid fields.

See Basic Filtering in an Audit Report and Advanced Filtering in an Audit Report for more information.
Click Create as alert rule to use the currently applied filters as the conditions for a custom alert.
Select Create an alert policy.

Fill in the following required fields:

Field Name	Description
Policy name	Display name of the alert policy you're creating.
Compartment	The compartment where the alert policy will be created. Alert policies can be applied to target databases regardless of the compartment. You will associate the alert policy to the target database in a later step. See Associate and Apply Alert Policies to Target Databases for more information.
Severity	Critical, High, Medium, or Low The designated severity level will be visible if an alert is generated.
Rule name	Display name of the alert rule. A rule defines the logic that will cause the alert to trigger. An alert policy can have up to five custom rules. You can only create one rule in this workflow, but you can create more in a later step. See Add an Alert Rule to an Existing Alert Policy From Activity Auditing or Manage the Alert Rules of an Existing Alert Policy Manually for more information.
Rule expression SCIM query	This will show the System for Cross-Domain Identity Management (SCIM) syntax for the filters you applied earlier and defines the logic for your custom alert. You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy. See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information.

Click Submit.

Table 5-1 Alert condition supported fields

Field	Description
`Audit type (auditType)`	The type of auditing: `STANDARD`, `FINE_GRAINED`, `XS`, `DATABASE_VAULT`, `LABEL_SECURITY`, `RMAN`, `DATAPUMP`, `DIRECT_PATH_API`
`Client host (clientHostname)`	The host name of the client application that was the source of the event causing the alert.
`Client ID (clientId)`	The client identifier in each Oracle session.
`Client IP (clientIp)`	The IP address of the client application that was the source of the event causing the alert.
`Client program (clientProgram)`	The application from which the audit event was generated. For example SQL Plus or SQL Developer.
`DB user (dbUserName)`	The name of the database user whose actions were audited.
`Error code (errorCode)`	Oracle Error code generated by the action. Zero indicates the action was successful.
`Error message (errorMessage)`	The detailed message on why the error occurred.
`Event (eventName)`	The name of the event executed by the user on the target database. For example `ALTER SEQUENCE`, `CREATE TRIGGER`, or `CREATE INDEX`.
`External user (externalUserId)`	The user ID of the external user of the audit event.
`Location (auditLocation)`	The location of the audit. Currently the value is audit table.
`Object(objectName)`	Name of the object on the database affected by the action, for example, a table name, file name, or a directory name. Must be in upper case, for example, `ALTER_TABLE`.
`Object owner (objectOwner)`	The schema name of the object affected by the action.
`Object type (objectType)`	Type of object in the source database affected by the action. For example `PL/SQL`, `SYNONYM`, or `PACKAGE BODY`.
`Operation (operation)`	The name of the action executed by the user on the target database. For example `ALTER`, `CREATE`, or `DROP`.
`Operation status (operationStatus)`	Status of the event: `Success` or `Failure`
`OS user (osUserName)`	The name of the operating system user for the database session.
`Terminal (osTerminal)`	The operating system terminal of the user session.
`Unified audit policies (auditPolicies)`	List of audit policies that caused the current audit event.

Create a Custom Alert Policy Manually

You can use System for Cross-Domain Identity Management (SCIM) syntax to create custom alert policies. Existing alert policies can be used as the basis for a custom alert policy and further customized using SCIM.

To create a custom alert policy:

Under Security center, click Alerts.
Under Related resources, click Alert policies.
Click Create alert policy.

Fill in the following required fields:

Field Name	Description
Policy name	Display name of the alert policy you're creating.
Compartment	The compartment where the alert policy will be created. Alert policies can be applied to target databases regardless of the compartment. You will associate the alert policy to the target database in a later step. See Associate and Apply Alert Policies to Target Databases for more information.
Severity	Critical, High, Medium, or Low The designated severity level will be visible if an alert is generated.
Rule name	Display name of the alert rule. A rule defines the logic that will cause the alert to trigger. An alert policy can have up to five custom rules. You can only create one rule in this workflow, but you can create more in a later step. See Add an Alert Rule to an Existing Alert Policy From Activity Auditing or Manage the Alert Rules of an Existing Alert Policy Manually for more information.
Rule expression SCIM query	Use System for Cross-Domain Identity Management (SCIM) syntax to create the logic that will cause the alert to trigger. You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy. Tip: Don't create rules that only apply to specific target databases or times as this will cause errors. See the Alert condition supported fields table below for the list of valid fields. See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information.

Click Submit.

Table 5-2 Alert condition supported fields

Field	Description
`Audit type (auditType)`	The type of auditing: `STANDARD`, `FINE_GRAINED`, `XS`, `DATABASE_VAULT`, `LABEL_SECURITY`, `RMAN`, `DATAPUMP`, `DIRECT_PATH_API`
`Client host (clientHostname)`	The host name of the client application that was the source of the event causing the alert.
`Client ID (clientId)`	The client identifier in each Oracle session.
`Client IP (clientIp)`	The IP address of the client application that was the source of the event causing the alert.
`Client program (clientProgram)`	The application from which the audit event was generated. For example SQL Plus or SQL Developer.
`DB user (dbUserName)`	The name of the database user whose actions were audited.
`Error code (errorCode)`	Oracle Error code generated by the action. Zero indicates the action was successful.
`Error message (errorMessage)`	The detailed message on why the error occurred.
`Event (eventName)`	The name of the event executed by the user on the target database. For example `ALTER SEQUENCE`, `CREATE TRIGGER`, or `CREATE INDEX`.
`External user (externalUserId)`	The user ID of the external user of the audit event.
`Location (auditLocation)`	The location of the audit. Currently the value is audit table.
`Object(objectName)`	Name of the object on the database affected by the action, for example, a table name, file name, or a directory name. Must be in upper case, for example, `ALTER_TABLE`.
`Object owner (objectOwner)`	The schema name of the object affected by the action.
`Object type (objectType)`	Type of object in the source database affected by the action. For example `PL/SQL`, `SYNONYM`, or `PACKAGE BODY`.
`Operation (operation)`	The name of the action executed by the user on the target database. For example `ALTER`, `CREATE`, or `DROP`.
`Operation status (operationStatus)`	Status of the event: `Success` or `Failure`
`OS user (osUserName)`	The name of the operating system user for the database session.
`Terminal (osTerminal)`	The operating system terminal of the user session.
`Unified audit policies (auditPolicies)`	List of audit policies that caused the current audit event.

Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM)

Use the following information to use SCIM to create custom alert policies.

Supported SCIM Operators

Rule expression creation uses System for Cross-Domain Identity Management (SCIM) syntax and supported operators include:

co: matches resources with an attribute that contains a given string
eq: matches resources with an attribute that is equal to a given value (not case sensitive)
eq_cs: matches resources with an attribute that is equal to a given value (case sensitive)
ew: matches resources with an attribute that ends with a given string
ge: matches resources with an attribute that is greater than or equal to a given value
gt: matches resources with an attribute that is greater than a given value
in: matches resources with an attribute that is equal to any of given values in list
le: matches resources with an attribute that is less than or equal to a given value
lt: matches resources with an attribute that is less than a given value
ne: matches resources with an attribute that is not equal to a given value
not_in : matches resources with an attribute that is not equal to any of given values in list
pr: matches resources with an attribute if it has a given value
sw: matches resources with an attribute that starts with a given string

Tips for Using SCIM

Pressing the escape key while defining the rule expression will clear the whole query and close the create alert policy workflow.
Pressing the space key will display the drop down with the list of available attributes or operators.
Pressing the space key after entering a value like objectName (demo_obj) will enclose the string with quotes: ("demo_obj").
Pressing enter will close the drop down listing the operators and attribute names.
If a value like SQL Firewall policy name has spaces in it, typing space will enclose the first word within quotes, "policy name". You will have to move the cursor back to the enclosed string and continue typing the rest of the string value.

For more information about SCIM, see the protocol documentation at https://www.rfceditor.org/rfc/rfc7644.

For more information about filtering in SCIM, see the filtering section of the protocol documentation at https://www.rfc-editor.org/rfc/rfc7644#section-3.4.2.2.

Add an Alert Rule to an Existing Alert Policy From Activity Auditing

After applying filters to the All activity report in Activity Auditing, you can add a rule to an existing custom alert policy based on the filters.

Under Security center, click Activity auditing.
Under Related resources, click Audit reports.
Select the All activity report from the list.
Use basic or advanced filtering to filter the all activity report as desired for the alert policy.

Tip:
Don't create filters that only apply to specific target databases or times as this will cause errors when creating the rule.

See the Alert condition supported fields table below for the list of valid fields.

See Basic Filtering in an Audit Report and Advanced Filtering in an Audit Report for more information.
Click Create as alert rule to use the currently applied filters as the conditions for a custom alert.
Select Create as alert rule to use the currently applied filters as the conditions for an additional rule of an existing alert policy.
An alert policy can have up to five alert rules. The policy will trigger if any of the rules are met.

Fill in the following required fields:

Field Name	Description
Compartment	Select the compartment where the alert policy you're adding the rule to is stored.
Policy name	Select the name of the alert policy. The list is populated based on the compartment that is selected.
Rule name	Display name of the alert rule. A rule defines the logic that will cause the alert to trigger. An alert policy can have up to five custom rules. You can only create one rule in this workflow, but you can create more in a later step. See Add an Alert Rule to an Existing Alert Policy From Activity Auditing or Manage the Alert Rules of an Existing Alert Policy Manually for more information.
Rule expression SCIM query	This will show the System for Cross-Domain Identity Management (SCIM) syntax for the filters you applied earlier and defines the logic for your custom alert. You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy. See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information.

Click Submit.

Table 5-3 Alert condition supported fields

Field	Description
`Audit type (auditType)`	The type of auditing: `STANDARD`, `FINE_GRAINED`, `XS`, `DATABASE_VAULT`, `LABEL_SECURITY`, `RMAN`, `DATAPUMP`, `DIRECT_PATH_API`
`Client host (clientHostname)`	The host name of the client application that was the source of the event causing the alert.
`Client ID (clientId)`	The client identifier in each Oracle session.
`Client IP (clientIp)`	The IP address of the client application that was the source of the event causing the alert.
`Client program (clientProgram)`	The application from which the audit event was generated. For example SQL Plus or SQL Developer.
`DB user (dbUserName)`	The name of the database user whose actions were audited.
`Error code (errorCode)`	Oracle Error code generated by the action. Zero indicates the action was successful.
`Error message (errorMessage)`	The detailed message on why the error occurred.
`Event (eventName)`	The name of the event executed by the user on the target database. For example `ALTER SEQUENCE`, `CREATE TRIGGER`, or `CREATE INDEX`.
`External user (externalUserId)`	The user ID of the external user of the audit event.
`Location (auditLocation)`	The location of the audit. Currently the value is audit table.
`Object(objectName)`	Name of the object on the database affected by the action, for example, a table name, file name, or a directory name. Must be in upper case, for example, `ALTER_TABLE`.
`Object owner (objectOwner)`	The schema name of the object affected by the action.
`Object type (objectType)`	Type of object in the source database affected by the action. For example `PL/SQL`, `SYNONYM`, or `PACKAGE BODY`.
`Operation (operation)`	The name of the action executed by the user on the target database. For example `ALTER`, `CREATE`, or `DROP`.
`Operation status (operationStatus)`	Status of the event: `Success` or `Failure`
`OS user (osUserName)`	The name of the operating system user for the database session.
`Terminal (osTerminal)`	The operating system terminal of the user session.
`Unified audit policies (auditPolicies)`	List of audit policies that caused the current audit event.

Manage the Alert Rules of an Existing Alert Policy Manually

After creating a custom alert policy you can add up to four additional custom alert rules, up to five rules total, to an existing custom alert policy. An alert will be triggered if any of the alert rules are met.

Under Security center, click Alerts.
Under Related resources, click Alert policies.
Click the Custom alert policies tab.
Select the custom alert policy you'd like mange the alert rules for.
You can perform the following tasks:
- Click Add rule to add a new rule. Enter the required fields as described in Table 5-4.
  An alert policy can have up to five alert rules. The policy will trigger if any of the rules are met
- Select an existing rule and then Edit rule to edit it. Enter the required fields as described in Table 5-4.
- Select an existing rule and then Delete rule to delete it.

Table 5-4 Fields

Field	Description
Rule name	Display name of the alert rule. A rule defines the logic that will cause the alert to trigger.An alert policy can have up to five custom rules.
Rule expression SCIM query	Use System for Cross-Domain Identity Management (SCIM) syntax to create the logic that will cause the alert to trigger. You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy. Tip: Don't create rules that only apply to specific target databases or times as this will cause errors. See the Alert condition supported fields table below for the list of valid fields. See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information.

Field

Description

Rule name

Display name of the alert rule. A rule defines the logic that will cause the alert to trigger.An alert policy can have up to five custom rules.

Rule expression SCIM query

Use System for Cross-Domain Identity Management (SCIM) syntax to create the logic that will cause the alert to trigger.

You can use Copy rule from an existing alert policy to copy the SCIM syntax from a single existing policy.

Tip:

Don't create rules that only apply to specific target databases or times as this will cause errors.

See the Alert condition supported fields table below for the list of valid fields.

See Supported Operators and Tips for Using System for Cross-Domain Identity Management (SCIM) for more information.

Table 5-5 Alert condition supported fields

Field	Description
`Audit type (auditType)`	The type of auditing: `STANDARD`, `FINE_GRAINED`, `XS`, `DATABASE_VAULT`, `LABEL_SECURITY`, `RMAN`, `DATAPUMP`, `DIRECT_PATH_API`
`Client host (clientHostname)`	The host name of the client application that was the source of the event causing the alert.
`Client ID (clientId)`	The client identifier in each Oracle session.
`Client IP (clientIp)`	The IP address of the client application that was the source of the event causing the alert.
`Client program (clientProgram)`	The application from which the audit event was generated. For example SQL Plus or SQL Developer.
`DB user (dbUserName)`	The name of the database user whose actions were audited.
`Error code (errorCode)`	Oracle Error code generated by the action. Zero indicates the action was successful.
`Error message (errorMessage)`	The detailed message on why the error occurred.
`Event (eventName)`	The name of the event executed by the user on the target database. For example `ALTER SEQUENCE`, `CREATE TRIGGER`, or `CREATE INDEX`.
`External user (externalUserId)`	The user ID of the external user of the audit event.
`Location (auditLocation)`	The location of the audit. Currently the value is audit table.
`Object(objectName)`	Name of the object on the database affected by the action, for example, a table name, file name, or a directory name. Must be in upper case, for example, `ALTER_TABLE`.
`Object owner (objectOwner)`	The schema name of the object affected by the action.
`Object type (objectType)`	Type of object in the source database affected by the action. For example `PL/SQL`, `SYNONYM`, or `PACKAGE BODY`.
`Operation (operation)`	The name of the action executed by the user on the target database. For example `ALTER`, `CREATE`, or `DROP`.
`Operation status (operationStatus)`	Status of the event: `Success` or `Failure`
`OS user (osUserName)`	The name of the operating system user for the database session.
`Terminal (osTerminal)`	The operating system terminal of the user session.
`Unified audit policies (auditPolicies)`	List of audit policies that caused the current audit event.

Details for an Oracle Data Safe Alert Policy

Oracle Data Safe provides the following information for each Oracle predefined alert policy:

Policy name
Severity level of the alert policy; for example, CRITICAL
Type of alert policy - Currently, all policies are based on auditing.
Oracle Cloud Identifier (OCID) - You can view and copy this OCID.
Target databases on which the alert policy is applied
Rule expression - For example, the expression for the Profile Changes alert policy is ((operation eq_cs "CREATE" OR operation eq_cs "ALTER" OR operation eq_cs "DROP") AND objectType eq_cs "PROFILE")

View the List of Available Alert Policies

Under Security center, click Alerts.
Under Related resources, click Alert policies.
The list of alert policies is displayed. Currently, only Oracle predefined alert policies are listed. For each policy, you can view its severity level and description.

View Details for an Alert Policy

Under Security Center, click Alerts.
Under Related Resources, click Alert Policies.
On the right, click the name of the alert policy for which you want to view more information.
The Alert Policy Details page is displayed.
On the Alert Policy Information tab, view the details for the alert policy.

Associate and Apply Alert Policies to Target Databases

You can associate and enable alert policies on target databases from the Target-Policy Associations page (recommended) or the Alert Policy Details page. On the Target-Policy page, you can view all alert policies associated with and enabled on each target database. The Apply Policy action associates and enables alert policies in one step.

Under Security Center, click Alerts.
Under Related Resources, click Target-Policy Associations. The Target-Policy Associations page is displayed.
Click Apply Policy. The Apply And Enable Alert Policy To Target Databases panel is displayed.
Select the target databases for which you want to apply the alert policies.

Note:
Currently, you can apply alert policies to a maximum of ten target databases at one time. If you have access to more than ten target databases in your tenancy, you need to choose the Selected Targets Only option.
- To apply an alert policy (or multiple alert policies) to all your target databases (assuming you have ten or less target databases), leave All Targets selected. Keep in mind that you require the appropriate permissions in Oracle Data Safe for each target database.
- To apply an alert policy (or multiple alert policies) to select target databases (up to a maximum of ten target databases), select Selected Targets Only. If needed, click Change Compartment and select the compartment that contains your target databases. One at a time from the drop-down list, select target databases. To select target databases in a different compartment, click Add Row. In the new row, click Change Compartment and select a different compartment. One at a time from the drop-down list, select target databases.
Select the alert policies.
- To apply all alert policies, leave All Policies selected.
- To apply select alert policies, select Selected Policies Only. One at a time from the drop-down list, select alert policies.
Click Apply Policy.
The alert policies are applied while the panel is open.
Wait until the message Apply "Profile Changes" on <target database names> is displayed and has the status Done.
Click Close.
Refresh the Target-Policy Associations page to view the new associations.
The target databases have the alert policies enabled by default.

View Target Databases on Which an Alert Policy is Applied

Under Security Center, click Alerts.
Under Related Resources, click Alert Policies.
On the right, click the name of the alert policy. The Alert Policy Details page is displayed.
Next to Policy Applied On Target Databases, click View List to view the list of target databases on which the alert policy is applied.
The Target-Policy Associations page is displayed. The Policy Name filter on the left is automatically set to the alert policy name. If the alert policy isn't applied to any target databases, the message No Target-Policy Associations Available is displayed.

View Alert Policies Associated with a Target Database

You can view the alert policies associated with a target database from the Target-Policy Associations page. It's useful to apply filters on the page to quickly locate a target database.

Under Security Center, click Alerts.
Under Related Resources, click Target-Policies Associations.
From the Compartment drop-down list on the left, select the compartment that contains the target databases for which you want to view alert policies. Optionally, select Include child compartments.
From the Target Databases drop-down list, select a particular target database.
From the Policy Name drop-down list, select All to view all alert policies associated with your target database. Or, select a particular alert policy name.
On the right, view the list of target databases and the alert policies associated with them.
There is a row for each association. For example, if your target database is associated with two alert policies, there are two rows in the table.

For each association, you can view whether the alert policy is enabled, the state (Active or Deleted) , when the alert policy was associated with the target database, , and the when the association was last updated
To sort the table based on a column, position your cursor over the column header and click the small arrow.
The table is sorted by the Time Created column by default.

Enable or Disable Alert Policies on a Target Database

You can quickly disable an alert policy on a target database from the Target-Policy Associations page.

Under Security Center, click Alerts.
Under Related Resources, click Target-Policy Associations.
The Target-Policy Associations page is displayed.
On the left, set the appropriate compartment, target database, and policy name filters to quickly find the alert policy that you want to enable or disable on your target database.
The table lists alert policies only for your target database.
On the right, select the check box for the rows that pertain to the alert policies that you want to enable or disable.
From the Actions menu, select Enable Policy or Disable Policy.
An Enable Policy or Disable Policy dialog box prompts you to confirm.
Click Yes.

Move a Target-Policy Association

You can move a target-policy association resource to a different compartment.

Under Security center, click Alerts.
Under Related resources, click Target-policies associations.
On the left, filter the list by compartment, target database, and/or policy name.
In the table, locate the row that contains the target-policy association that you want to move, and then click the name of your target database.
The Target-policy associations details page is displayed.
Click Move resource.
The Move resource dialog box is displayed.
Select a compartment, and then click Move resource.
The target-policy association is immediately moved to the selected compartment.

Delete a Target-Policy Association

Under Security Center, click Alerts.
Under Related Resources, click Target-Policy Associations.
The Target-Policy Associations page is displayed.
On the left, set the appropriate compartment, target database, and policy name filters to quickly find the alert policy that you want to enable or disable on your target database.
On the right in the row that pertains to your alert policy and target database, click the target database name.
The Target-Policy Associations Details page is displayed.
Click Delete.
The target-policy association is deleted.