OBIEE Security: Questions IT Security and Audit Should Ask

This blog series so far has reviewed the basics of OBIEE security, the following questions should be included in any discussion of about the security of an OBIEE implementation.

How are Security Configurations Migrated?

Creation of non-production instances is a regular occurrence for enterprise software. To migrate security configurations among non-production instances as well as from non-production to production, OBIEE requires specific steps to be taken for Identity, Policy and Credential Stores as well as for the migration of Repositories. Some migration steps are done through the WebLogic, others by WLST. Performing migrations by copying directories among different servers and/or environments should be flagged and investigated.

Ask for Permission Reports

Prior to 11g OBIEE did not have an option to report on security permissions and rules defined within the RPD. With 11g permission reports are able to be generated for presentation layer objects. These reports are able to be exported as CSV files and are of great value to understanding security within an OBIEE application.

Are WiteBacks being Used?

OBIEE has an advanced feature which allows for data to be written (created or updated) back to the database. This feature is referred to as ‘Write Back’.  The connection pool needs to be configured to allow for write back as well as the physical layer needs to flag each table to be updated as ‘uncacheable’. The granting of write back privileges is then given to users within the Presentation Layer.

An example of WriteBack could be variables to assist with “what-if” modeling. The security risks if not set properly include data integrity if for example a user were to update their own salary.

Are Time Limits being Used?

OBIEE, besides being able to set query limits for the number of rows to be returned, can also set limits for when a particular user or role can use OBIEE.  For example, it is possible to define a rule to only allow a specific user or an application role to use the RPD during first shift and/or only Monday through Friday. Such rules may help build a more secure implementation.

Navigation: => Open identity manager within the RPD => Select role or user => Click on permissions => Click on query limits => Click on restrict

Is Direct SQL Access Allowed?

OBIEE allows for Direct SQL access to the repository database (data sources). While this can be invaluable for testing it can also be a large security risk, especially if full Data Manipulation Language (DML) is allowed. Direct SQL access can be globally enabled or disabled as well as set at a role or individual level.

Any security assessment of OBIEE needs to review the usage of Direct SQL Access. The risks of allowing Direct SQL include:

• Confidentiality –  bypassing data (object) level security defined within the repository (RPD)
• Integrity – modifying or deleting data
• Availability – overloading database with inordinate requests

To restrict access to direct SQL:

• Global: => Settings => Administration => Manage Privilege
• Role or User:  => Open identity manager within the RPD => Select role or user => Click on permissions => Click on query limits => Select Allow, Disallow or Ignore for Execute direct database requests

Example of Direct SQL

Is Go URL SQL Access Allowed and Secured?

The Oracle BI Presentation Services Go URL can be used to incorporate specific Oracle Business Intelligence results into external portals or applications. It has a number of optional parameters and arguments. It can also set session variables. More importantly, it can also issue SQL and return tabular results. For these two reasons alone, how the Go URL is being used should be kept in mind during a security assessment.

For example:

http://testobiee:9704/analytics/saw.dll?Go&SQL=select+Region,Dollars+fro... where the FROM clause is the name of the Subject Area to query

Alternatively, the command IssueRawSQL can be used to bypass the Web processing and issue SQL directly against the BI Server.

Who Can Act-As and Who can Impersonate?

OBIEE allows for two options for a user to assume the identity of another user. This functionality exists for several reasons, including testing, end-user support and system integration.  Any security assessment of OBIEE needs to identify all users and systems able to act-as or impersonate another user.

• Impersonation - exists more for integration, is less secure than ‘Act-As’ and from a security perspective is a ‘backdoor’ risk. The default OBIEE user, BISystem comes out-of-the-box with Impersonation enabled. IT security should be consulted if this is enabled.
• Act-As – is the better choice to use support. It is more secure and is fully integrated into the user interface as standard functionality.

To check the Act-As and Impersonation settings, look at the system session variables PROXY and PROXYLEVEL.

An example URL for impersonation is below. Please note, too, that the URL were exercised, the security risks could be increased because the user name password will then be captured and stored in the Apache log files.

http://server_name_or_ip_address/analytics/saw.dll?Go&NQuser=xxx&NQPassword=xxx

Are Virtual Private Databases (VPD) Being Used?

If a Virtual Private Database (VPD) is being used with an OBIEE connection, two things MUST be done. First, for the database connect, set the flag for Virtual Private Database to “Yes”. Second, all variables supporting the security rules must be set to ‘Security Sensitive’. Failing to properly set up VPD with OBIEE can result in VPD policies being bypassed due to the OBIEE cache incorrectly sharing result sets already in memory.

 VPD Checkbox

What Is Used for Source Code Control?

New with OBIEE 11g is the feature to store Repositories using a XML file format instead of the single RPD file. This allows for better support of source code control. Each component of the RPD file has its own XML file such that source code control tools such as Subversion can be used to check in or out each component. Best practice for development and security is to use source code control whenever possible.

If you have questions, please contact us at info@integrigy.com

 -Michael Miller, CISSP-ISSMP

References

• OBIEE Security Examined - Webinar and Presentation:  OBIEE Security Examined Webinar
• OBIEE Security Examined - Whitepaper: OBIEE Security Examined