Audit Active Data Guard with Data Safe in Oracle Cloud

We’re excited to announce that Oracle Data Safe can now monitor the database activity of Active Data Guard configurations for Oracle Database on Oracle Exadata Database Service on Dedicated Infrastructure (formerly known as Exadata Cloud Service) and Oracle Base Database Service (formerly known as Oracle Database Cloud Service).

Active Data Guard (ADG) is an evolution of Oracle Data Guard technology that incorporates significant innovation designed for a specific purpose - to offload work from the production database, freeing up resources for critical transactions. ADG enables read-only access to a physical standby database while redo application is active. Workloads such as reporting, analytics, backups, queries, and even occasional writes (a new ADG feature as of Oracle Database 19c) can be offloaded from the production system to a synchronized physical standby database. These workloads would otherwise consume valuable resources on the primary production site; therefore, ADG saves valuable CPU and I/O cycles and promotes efficient use of system resources in the configuration. Since ADG opens up standby databases for read/write workloads, most regulatory and compliance requirements emphasize the need to monitor the database activity on standby databases, though less rigorously compared to the primary production database.

Data Safe now provides a single pane of glass monitoring database activity for all the database peers in an ADG configuration (including the primary database and all the associated standby databases) without worrying about redundant audit record collection. A brief insight into the mechanism within Oracle Database auditing that enables the feature in Data Safe explains why this is important.

Unified audit records within the Oracle Database are written to a table in the AUDSYS schema called AUD$UNIFIED. When the database is not writable (typically occurs when the database is closed or is read-only as in ADG), the Oracle Database writes audit records to external operating system spillover .BIN files. The audit data of the spillover files is presented in the view GV$UNIFIED_AUDIT_TRAIL.

The view UNIFIED_AUDIT_TRAIL is a UNION ALL of the table AUDSYS.AUD$UNIFIED and the view GV$UNIFIED_AUDIT_TRAIL.

The capability to monitor audit records from standby databases is built into the UNIFIED_AUDIT_TRAIL since unified audit was introduced in Oracle Database 12c. However, because audit records from the primary database (written to the database table AUD$UNIFIED) are captured in redo and replicated to the standby, it was challenging to separate activity on the standby from activity on the primary. Oracle Database 19c Release Update 21 (19.21) introduced a new column, SOURCE, in UNIFIED_AUDIT_TRAIL, making it easy to differentiate the origin of audit records. That new column helps avoid redundant audit record collection from ADG.

Figure1: Unified audit trail with SOURCE column to differentiate the origin of audit records

Leveraging the SOURCE column value in the UNIFIED_AUDIT_TRAIL view enables Data Safe to monitor the entire ADG configuration with a single primary database and multiple standby databases as a single target with multiple unified audit trails. The primary database in the ADG (as identified by the system-generated failover connection string with role-based database service) has an audit trail to collect from the database table AUDSYS.AUD$UNIFIED by querying the  UNIFIED_AUDIT_TRAIL view with SOURCE set to DATABASE. Each database in the ADG will have an audit trail to collect from that database’s corresponding spillover files by querying the UNIFIED_AUDIT_TRAIL view with SOURCE set to FILE.

A sample monitoring configuration for an ADG with one primary and two standby databases is represented here.

Figure2: Database activity monitoring of ADG as a single target with multiple unified audit trails

Once you register the primary, along with any ADG peers, in Data Safe as a database target, the associated audit profile contains the details of the multiple audit trails discovered automatically from the metadata. The audit trails will have an indicator (FILE or TABLE) to identify the SOURCE of audit records, as shown here.

Figure3: Audit profile of the single ADG target with multiple unified audit trails in Data Safe

Collecting unified audit records in Data Safe commences once you start the corresponding audit trails, and audit reports show the ADG target's audit events from the primary and standby databases.

Sample login activity report of the ADG target is shown here with audit events from both primary and standby databases. The column database unique name lets you correlate activity to the specific database in the ADG target where the audit event was triggered.

Figure4: Audit report in Data Safe of the ADG target showing audit events from all the databases

In a nutshell, Data Safe provides a single pane of glass monitoring database activity for all the Oracle databases in ADG configuration as a single target with multiple unified audit trails.

Source: oracle.com

Continue reading

Customizing risk assessment in Oracle Data Safe

Oracle Data Safe Security Assessment helps you assess and monitor changes to your database security risks by identifying security misconfigurations, missing policies, users, and entitlements. After the initial risk identification, customers typically evaluate the risks by validating them and their risk levels before remediating them. Sometimes the identified risk is not applicable as there might be some other mitigating control or it might not be important for your business or auditors. Customers would like Data Safe to adjust the findings to match their organization’s specific needs and help streamline the assessment process.

We are pleased to announce that you can now “defer risk” or “change risk” level to match your specific environment and deployment. “Defer Risk” allows you to indicate that you have reviewed the finding and will work on it later (or, eventually, never) so that it doesn’t show up again as a finding in subsequent reports. “Change Risk,” allows you to raise or lower the severity of a finding to suit your requirements.

Use Cases

In the example below, the organization has decided to “defer” the risk for users with expired passwords until they can study who are these users

Figure 1. Data Safe Security Assessment - Deferring or changing a finding risk level.

Use case 1

Data Safe Security Assessment identified that the database does not have a recent backup (no records in the last 90 days) and flagged it as a High Risk. But here, the database was backed up in the last 80 days, but as a cold backup with a 3rd party technology. You have decided that there is no risk, and you can now mark it as a “Pass.” Thus, the assessment report would no longer show this as a “finding”.

Use case 2

Security Assessment identified that you have five users with the DBA role and marked it as “Evaluate.” After careful examination, you’ve noticed that all five users are approved accounts for your company’s database administrators. Despite reading the remarks on why it is better not to use the out-of-the-box DBA role, you consciously decided to mark it as “Low risk.” Database administrators are still using the default DBA role but there are plans to review their privileges with Privilege Analysis and to create a customized DBA role with only the necessary privileges. Additionally, Database Vault realms protect the application schemas to further reduce the risk of misuse or compromise.

Figure 2. Deferring risks for later reevaluation

Use case 3

Security Assessment identified that there is an application service account that allows unlimited failed logins. Investigation reveals that following the last password change several batch processes continued to use the old password, locking the application account and causing an outage. The issue is being worked on, with plans to implement gradual password rollover for all application account profiles. In the meantime, failed login attempts are being audited, and Audit Vault is configured to alert wherever a new failed login attempt is made. Setting this risk to deferred until the password rollover profiles are implemented.

Risk Modification Report

The user changing the risk level will need to provide a justification for the change. The user can also set an expiration date. Setting an expiration date will clear up the overridden level at that time and again let the assessment show the actual finding level.

Modified risk levels are tracked and available under the “Risk modification report.” In this report you will see the originally identified risk level, the modified risk level, or whether the risk was deferred, along with the justification and the expiration date. The user that made the change and the last update time are also tracked.

Figure 3. Data Safe Security Assessment – Risk modification report.

Conclusion

With this addition, Data Safe helps you streamline and adjust the assessment report to meet your corporate and regulatory needs. Now, in addition to assessing your database according to standard practices, you can also customize the risk levels, manually pass findings, and track your progress toward compliance.

Source: oracle.com

Continue reading

Expanded enterprise-class support with Oracle Audit Vault and Database Firewall Release Update 11 (20.11)

One of our design goals for Oracle Audit Vault and Database Firewall is to continue to provide an enterprise-class solution that takes much of the complexity out of database activity monitoring and database security posture management. With that goal in mind, Audit Vault and Database Firewall (AVDF) 20 Release Update 11 (20.11) continues to expand support for enterprise-class features along with significant improvements in usability and operations.

Here is what’s new in the latest AVDF Release:

• QuickCSV audit collector
• Integration with identity provider for single-sign-on
• Revamped alert UI workflow
• Fleet-wide security assessment drift chart
• Expanding support for tracking before/after values
• Finely scoped database firewall policies and reports
• Use of global sets in all activity and GDPR reports
• Audit trail migration
• AVDF certificate rotation from UI

Now, let's review some of those in detail.

QuickCSV audit collector

AVDF supports out-of-box audit log collection from multiple target types, including relational databases such as Oracle, Microsoft SQL Server, IBM DB2, MySQL, and PostgreSQL. AVDF also collects audit records from non-database targets, including operating system audit records for Windows, AIX, Sparc, and Solaris, as well as Microsoft Active Directory. However, there is a variety of systems that produce audit records, and this is where AVDF’s custom collector framework helps by collecting audit records available from database tables via RESTful API or audit data stored in JSON, CSV, and XML file formats.

We have seen that comma-separated value (CSV) is one of the most popular audit log formats used in applications, databases, and infrastructure components. With the new QuickCSV Collector in AVDF 20.11, you can easily import CSV audit files and map them to the AVDF audit schema as a one-time task. Once mapping is complete, audit data will be collected periodically from the CSV audit files like any other supported targets.

For example, you may use the QuickCSV collector to collect audit data from MariaDB, EnterpriseDB (Postgres), and other databases that create audit data in CSV. This approach helps you generate audit reports and alerts and protect and manage audit logs. 

Figure 1: QuickCSV collector

Integration with identity provider for single-sign-on

Today, many of you implement single sign-on (SSO) using an enterprise identity service for your applications to minimize account proliferation and authentication mechanisms. Now, with AVDF 20.11, you can integrate with identity providers (IdP) such as Azure, Active Directory Federation Services, and Oracle Access Manager through SAML 2.0 integration. After integrating AVDF with your IdP, AVDF console users can be authenticated by your IdP using SSO.

With this new feature, you have multiple options to choose from as your authentication method:

• Users authenticated with SSO – added in 20.11
• Users in a centralized directory like Microsoft Active Directory or OpenLDAP
• Users authenticated using local passwords in AVDF

Figure 2: AVDF authentication methods

Revamped alert UI workflow: 

We know most organizations are concerned about data breaches and ransomware, but when prevention fails, we need to help you understand what happened and detect attempts quickly. A better alert policy workflow contributes to a better detection system.

AVDF’s alert policy creation is completely revamped in AVDF 20.11, providing an intuitive and user-friendly experience.  New alert policies can be created with just a few clicks through pre-defined templates or by modifying existing policies with new conditions.

AVDF’s unique interactive reporting  capability allows customers to quickly slice and dice the data to reach that one record of interest, and now this capability is available in the alert policy as well.  You can also use the interactive report filters to define complex conditions for which alerts can be raised. In the example below, if you want to receive an alert when a privileged user updates sensitive data directly from SQLPlus, you can simply apply filters to your report and copy that to create the alert condition.

Figure 3: Alert policy condition using report filters

You can get a quick view of all the alerts generated on the alert policy page without going away from the alert definition, improving the overall user experience of alert usability. In addition, we made it much easier to notify the recipients of any alerts raised. Now, your auditor dashboard provides multiple actionable insights on the generated alerts.

Figure 4: Alert Insights

Fleet-wide security assessment drift chart

In AVDF 20.9 and 20.10, we introduced fleet-wide security assessment and drift management, respectively. AVDF 20.11 now allows you to quickly see how the security posture of all your Oracle databases is changing by introducing the security assessment drift chart. The chart on the auditor’s dashboard compares the latest assessment with the defined baseline for all databases and quickly identifies any drift requiring attention.

Figure 5: Security Assessment Drift Chart

More updates with AVDF 20.11

AVDF 20.11 introduces many other significant enhancements and features to improve your AVDF experience. Some of them are listed below.

Expanding support for tracking before/after values: AVDF currently collects before/after values from Oracle and Microsoft SQL Server databases and helps customers meet compliance requirements where they need to track the value change. AVDF 20.11 now extends the same before/after value change auditing support for MySQL, helping customers meet their compliance requirements for MySQL database also.

Finely scoped database firewall policies and reports: Until now, Database Firewall (DBFW) policies and reports were based on command groups such as DML, DDL, and DCL, and customers could not easily create policies on just a specific command.  With AVDF 20.11, the command class has been expanded to commands such as DELETE, INSERT, UPDATE, DROP TABLE, etc. This enhancement helps you define narrow alert conditions and create unified reports – irrespective of whether the event data was from the audit logs or network-based SQL.   

Use of global sets in all activity and GDPR reports: Until now, global sets of IP addresses, OS/DB users, sensitive objects, privileged users, and client programs have been used across Database Firewall policies, making it easier to apply the same rules.  Starting in AVDF 20.11, you can now apply the same global set to filter all activity reports, including the compliance reports. For example, in GDPR compliance reports, you can use sensitive object sets to view user activity on sensitive data.

Audit trail migration: Customers have requested easy ways to migrate their audit trails to different agents due to aging agent hardware or the need for improved load balancing across agents. AVDF 20.11 provides flexibility to migrate the audit trail from one agent to another or agentless configuration and vice versa without losing any audit data and restarting the agent/trail.   

AVDF certificate rotation from UI: AVDF uses certificates for internal communication among various services. The current process was lengthy and only partially automated. Now, with 20.11, you can have a clear picture of the certificate validity status from the AVDF console, and you can rotate these certificates with a single click when needed.

Source: oracle.com

Continue reading

Announcing the general availability of Oracle Globally Distributed Autonomous Database

Today, we have the pleasure of announcing the general availability of the Oracle Globally Distributed Autonomous Database. This fully managed Oracle Cloud Infrastructure (OCI) service is available in data centers around the world. Built-in, cutting-edge capabilities redefine how enterprises manage and process distributed data to achieve the highest possible levels of scalability and availability, and provide data sovereignty features. And, with Autonomous Database’s automated management and ease of use you don’t need to have an extensive staff of experts to take advantage of the power of a distributed database.

The Oracle Globally Distributed Autonomous Database simplifies the deployment and management of distributed databases. It provides transparent access for applications using these databases by automatically placing data in the appropriate location. The addition of distributed database capabilities on top of the proven SQL capabilities of Oracle Database enables customers to immediately benefit from decades of innovation in performance optimization, RAC parallel clusters, converged database architecture, and security.

Why Use Oracle’s Globally Distributed Autonomous Database

Oracle Globally Distributed Autonomous Database is designed to address global enterprises’ needs for high levels of performance and availability, and data sovereignty. It makes it easier for organizations to run critical distributed databases that use all types of data with high performance and availability. It  is ideal for a wide range of applications including payment processing, credit card fraud detection, personalized marketing, mobile messaging, internet infrastructure, and the Internet of Things (IoT).

Let's explore some of the key capabilities.

High Availability: Oracle's Globally Distributed Autonomous Database splits a single logical database into multiple physical databases (called shards) that are distributed across multiple data centers, availability domains, or regions. Faults in one shard do not affect others, enhancing overall availability. Automatic replication of shards across domains or regions provides protection from outages. The Oracle Globally Distributed Autonomous Database runs on fault-tolerant Exadata infrastructure for the highest possible availability.

Horizontal Scalability: Organizations can scale Globally Distributed Autonomous Database horizontally by adding servers and their associated database shards online and without interrupting database operations. Data and accesses are automatically redistributed to maintain a consistently balanced workload. The database infrastructure scales from multi-terabyte to multi-petabyte levels, addressing the requirements of the most demanding applications. In addition, each Globally Distributed Autonomous Database shard runs on an Exadata platform in OCI, providing high levels of vertically scaled performance that can automatically increase to meet local demand or scaled down to help reduce costs.

Data Sovereignty: Organizations can specify where data is stored using a choice of customer-defined data placement policies. Updates are automatically inserted into database shards in the correct location based on these policies.

Choice of Data Distribution Methods: Globally Distributed Autonomous Database offers extensive control over how data is distributed across shards. Unlike other databases with limited methods, we support value-based, system-managed consistent hash, user-defined, duplicated, and partitioned distribution within shards, as well as allowing flexible combinations.

Autonomous Management: This service brings the advanced, ML-driven capabilities of Autonomous Database to distributed databases with automatic database patching, security, tuning, and performance scaling within shards. The service combines vertical and horizontal scalability to achieve optimum levels on demand.

AI: Autonomous Database Select AI is also supported, letting users access their distributed databases using LLM-enabled natural language queries without having to know how data is structured or where it is located.

Simple Application Development: The Globally Distributed Autonomous Database offers a unified logical database view to applications. Its cloud-native capabilities and support for Oracle Database’ rich feature set provide the ideal platform for modern applications. Automated and transparent data distribution and access simplify the development of distributed applications.

Oracle Globally Distributed Autonomous Database

 

Oracle Globally Distributed Autonomous Database can help you:

◉ Achieve hyperscale performance for transaction processing and mixed workloads

◉ Address data sovereignty requirements for distributed data warehousing and data lakes

◉ Deploy concurrent data pipelines and machine learning analytics

◉ Provide maximum availability for mission-critical applications

◉ Build cloud-native, scalable applications

Pricing

Globally Distributed Autonomous Database is priced based on the number of shards being used and the amount of database consumption on each shard. Our pricing is simple and predictable. You can find our pricing for the service at https://www.oracle.com/autonomous-database/distributed-autonomous-database/pricing/

The Future of Distributed Data Management is Here!

Oracle’s Globally Distributed Autonomous Database is a powerful and easy-to-use service designed to help you meet your diverse data needs. Whether it's enabling data residency, achieving extreme availability, managing massive scale, or delivering high performance with low local-access latency for global users, this service has you covered. If you're seeking a fully managed distributed database service, we invite you to experience the capabilities of Globally Distributed Autonomous Database. Explore the next era of data management and elevate your data operations.

Source: oracle.com

Continue reading

Oracle Fusion Analytics - Refresh Materialized Views via Custom Function After Pipeline Completion

Introduction

Oracle Fusion Data Intelligence Platform (FDIP, formerly Fusion Analytics Warehouse ) is an Oracle Cloud Infrastructure (OCI) native service that leverages the power of Oracle Autonomous Data Warehouse (ADW) and Oracle Analytics Cloud (OAC). It provides a comprehensive analytics solution that includes a data pipeline, data warehouse, semantic model, and pre-built content such as dashboards and reports.

As businesses expand and develop, the importance of automation in managing data and analytics applications also grows. Based on user input, Oracle has delivered in Preview the Fusion Analytics Event Producer service, giving you more control over tracking customized events and notifications. This service is an effective automated solution for creating consolidated events and notification workflows that can streamline your Fusion Analytics business operations.

Continue reading

Best Practices For Implementing Row-Level Security In Oracle Analytics

It’s intended for Model Administrators who are using row-level security filters and covers row-level security which has “or logic” and uses empty values when a part of the filter is not applicable. Many businesses have security constraints involving different dimensions for different groups of users and for combinations of them. The simplest implementation will apply filters for all possibilities and use an empty value for dimensions that do not apply to the specific user. The correct results are obtained, but the SQL contains extra tables that are not used, which can negatively impact performance. This post explains how to get Oracle Analytics to dynamically exclude these tables.

Row-Level Security Example

There are a couple of parts to setting up table elimination for row-level security. Set up a series of session variables that determine first, when to apply a security filter and second, which security filters to apply.

First, set up a series of control session variables that determine whether security should be applied. The session variables are binary and are set to either 1 or 0. 1 means the data is restricted and to use the security session variables; 0 means the data is unrestricted and ignores the security session variables.

This example describes setting up security on 4 entities: business hierarchy, country, department, and legal organization.

There are 5 control session variables set up, one for turning on security in general, and one to turn on security for each of the entities.

Control variables:

1. NQ_SESSION.Data_Security_Restricted – turns security on or off.
2. NQ_SESSION.Data_Sec_Control_BH – turns security on or off for the business hierarchy entity.
3. NQ_SESSION.Data_Sec_Control_Country – turns security on or off for the country entity.
4. NQ_SESSION.Data_Sec_Control_Department – turns security on or off for the department entity.
5. NQ_SESSION.Data_Sec_Control_Legal_Org – turns security on or off for the legal organization entity.

After that, set up security session variables for each entity that contains restricted data. These variables contain the values of the security filters to be passed to report filters.

Security filter variables:

1. NQ_SESSION.Data_Security_BH – sets the security filter for the business hierarchy entity.
2. NQ_SESSION.Data_Security_Country – sets the security filter for the country entity.
3. NQ_SESSION.Data_Security_Department – sets the security filter for the department entity.
4. NQ_SESSION.Data_Security_Legal_Org – sets the security filter for the legal organization entity.

You will want to pay attention to the underlying datatypes, as they determine the format of the value of the session variable. In this case, business hierarchy and legal organization are integers, while country and department are character strings. The value of the session variable is the actual value of the entity to be passed to the filter.

To help understand how the control variables and the indexcol function work, let's review an example in which security is set only for department, and the control variables and indexcol function are not used. The row-level filter is shown below:

"Core"."Dim - Business Hierarchy"."Business Hierarchy Identifier" = VALUEOF(NQ_SESSION."Data_Security_BH")

OR "Core"."Dim - Country"."Country Name" = VALUEOF(NQ_SESSION."Data_Security_Country")

OR "Core"."Dim - Legal Org"."Legal Org Identifier" = VALUEOF(NQ_SESSION."Data_Security_Legal_Org")

OR "Core"."Dim - Department"."Department Name" = VALUEOF(NQ_SESSION."Data_Security_Department")

The session variables are populated with the list of values the user can access and, if there is no restriction, then the “empty” placeholder value is used.

When applied to the sample report below, the security filter is: (with Data_Security_Department = ‘Dept 1’, Data_Security_Country = ‘No Values’, Data_Security_Legal_Org = -1, Data_Security_Department = -1 )

SELECT

   0 s_0,

   "Jobs Analysis"."Grade"."Grade Name" s_1,

   "Jobs Analysis"."Time"."Month Name" s_2,

   "Jobs Analysis"."Time"."Year" s_3,

   DESCRIPTOR_IDOF("Jobs Analysis"."Time"."Month Name") s_4,

   SORTKEY("Jobs Analysis"."Time"."Month Name") s_5,

   "Jobs Analysis"."Facts - Job Counts"."Jobs" s_6

FROM "Jobs Analysis"

WHERE

(("Time"."Year" = 2023) AND ("Time"."Month Name" = 'July'))

ORDER BY 4 ASC NULLS LAST, 6 ASC NULLS LAST, 3 ASC NULLS LAST, 5 ASC NULLS LAST, 2 ASC NULLS LAST

FETCH FIRST 500001 ROWS ONLY

Here is the SQL generated by the report:

In the sample above, the extra SQL is highlighted. There are 3 tables, DW_BUSINESS_DF_DH, DW_LEGAL_EMPLOYER_D and DW_COUNTRY_D_TL, that are used in the security filter but are not filtering anything. Depending upon the scope of the data in each of the additional tables, the query execution time is going to be higher than if those tables were not included.

To get those tables eliminated from the query, replace the row-level filter from above with this one:

INDEXCOL( VALUEOF(NQ_SESSION."Data_Security_Restricted"), '0', '1') = '0' OR  INDEXCOL( VALUEOF(NQ_SESSION."Data_Sec_Control_BH"), '0',  VALUEOF(NQ_SESSION."Data_Security_BH")) =  INDEXCOL( VALUEOF(NQ_SESSION."Data_Sec_Control_BH"), '1', "Core"."Dim - Business Hierarchy"."Business Hierarchy Identifier") OR  INDEXCOL( VALUEOF(NQ_SESSION."Data_Sec_Control_Country"), '0',  VALUEOF(NQ_SESSION."Data_Security_Country")) =  INDEXCOL( VALUEOF(NQ_SESSION."Data_Sec_Control_Country"), '1', "Core"."Dim - Country"."Country Name") OR  INDEXCOL( VALUEOF(NQ_SESSION."Data_Sec_Control_Dept"), '0',  VALUEOF(NQ_SESSION."Data_Security_Department")) =  INDEXCOL( VALUEOF(NQ_SESSION."Data_Sec_Control_Dept"), '1', "Core"."Dim - Department"."Department Name") OR  INDEXCOL( VALUEOF(NQ_SESSION."Data_Sec_Control_Legal_Org"), '0',  VALUEOF(NQ_SESSION."Data_Security_Legal_Org")) =  INDEXCOL( VALUEOF(NQ_SESSION."Data_Sec_Control_Legal_Org"), '1', "Core"."Dim - Legal Org"."Legal Org Identifier")

The SQL now generated by the report will have only the needed tables:

The key function to use to get these dynamic security filters is the indexcol function. To set up the indexcol function, use the session variables set up in the example and populated with the entity values.

A control initialization block is set up to determine which filters to apply based on the original control variables.

Control initialization block:

select 'Data_Sec_Control_BH', case when (Instr('valueof(NQ_SESSION.Data_Security_BH)','-1')>0) then 0 else 1 end from dual

union

select 'Data_Sec_Control_Dept', case when (Instr('valueof(NQ_SESSION.Data_Security_Department)','No Values')>0) then 0 else 1 end from dual

union

select 'Data_Sec_Control_Country', case when (Instr('valueof(NQ_SESSION.Data_Security_Country)','No Values')>0) then 0 else 1 end from dual

union

select 'Data_Sec_Control_Legal_Org', case when (Instr('valueof(NQ_SESSION.Data_Security_Legal_Org)','-1')>0) then 0 else 1 end from dual

It is important to set the precedence property on the control initialization block so it is executed after the initialization blocks that populate the security filter variables. In other words, the security filter variables must be populated before they are used in the control initialization block.

Call to Action

Following these steps will help ensure your row-level security formulas have the best possible performance by eliminating unnecessary filters and tables.

Source: oracle.com

Continue reading