Skip navigation.

Stephen Kost's E-Business Suite Security Blog

Syndicate content
Integrigy's Oracle Security Blog with information on security for the Oracle Database, Oracle E-Business Suite and other Oracle products.
Updated: 2 min ago

OBIEE Security: Catalogs, Access Control Lists and Permission Reports

Fri, 2014-04-18 05:00

The presentation catalog (Web Catalog) stores the content that users create within OBIEE. While the Catalog uses the presentation layer objects, do not confuse the presentation layer within the RPD with the presentation catalog. The presentation catalog includes objects such as folders, shortcuts, filters, KPIs and dashboards. These objects are built using the presentation layer within the RPD.

The difference between RPD and Catalog security is that Repository level restrictions give the most flexibility as they can be either course-grained or fine-grained based on the data. Catalog level restrictions are more course-grained as they are applied to entire subject areas and/or objects.

To access an object in the catalog users must have security and can use either the BI client or web user interface. The BI client for the Web Catalog is installed along with the BI Admin client.

Access Control Lists (ACL)

Access Control Lists (ACL) are defined for each object in the catalog. Within the file system the ACLs are stored in the *.ATR files which may be viewed through a HEX editor. A 16-digit binary representation is used similar to UNIX (e.g. 777). There are six different types of permissions for each object:

  • Full control
  • Modify
  • Open
  • Traverse
  • No Access
  • Custom

In 11g the catalog is located here:

$ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/catalog

  Catalog Permission Reports

From a security perspective, the permission reports that are able to be generated from the Web Catalog client tool are very valuable and can be exported to Excel for further analysis. For example, these reports can provide system generated reports for who can avoid OBIEE security and issue Direct SQL or has rights to Write-Back to the database.  The security ACL will report on who has such Administration privileges.

OBIEE Administration Privileges

BI Catalog Client

Catalog Report

 

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

 -Michael Miller, CISSP-ISSMP

References Tags: ReferenceOracle Business Intelligence (OBIEE)IT Security
Categories: APPS Blogs, Security Blogs

OBIEE Security: Usage Tracking, Logging and Auditing for SYSLOG or Splunk

Tue, 2014-04-15 05:00

Enabling OBIEE Usage Tracking and Logging is a key part of most any security strategy. More information on these topics can be found in the whitepaper references below. It is very easy to setup logging such that a centralized logging solution such as SYSLOG or Splunk can receive OBIEE activity.

Usage Tracking

Knowing who ran what report, when and with what parameters is helpful not only for performance tuning but also for security. OBIEE 11g provides a sample RPD with a Usage Tracking subject area. The subject area will report on configuration and changes to the RPD as well as configuration changes to Enterprise Manager.  To start using the functionality, one of the first steps is to copy the components from the sample RPD to the production RPD.

Usage tracking can also be redirected to log files. The STORAGE_DIRECTORY setting is in the NQSConfig.INI file. This can be set if OBIEE usage logs are being sent, for example, to a centralized SYSLOG database.

The User Tracking Sample RPD can be found here:

{OBIEE_11G_Instance}/bifoundation/OracleBIServerComponent/coreapplication_obis1/sample/usagetracking

Logging

OBIEE offers standard functionality for application level logging.  This logging should be considered as one component of the overall logging approach and strategy. The operating system and database(s) supporting OBIEE should be using a centralized logging solution (most likely syslog) and it is also possible to parse the OBIEE logs for syslog consolidation.

For further information on OBIEE logging refer to the Oracle Fusion Middleware System Administrator’s Guide for OBIEE 11g (part number E10541-02), chapter eight.

To configure OBIEE logging, the BI Admin client tool is used to set the overall default log level for the RPD as well as identify specific users to be logged. The log level can differ among users. No logging is possible for a role.

Logging Levels are set between zero and seven.

Level 0 - No logging

Level 1 - Logs the SQL statement issued from the client application.

Level 2 - All level 1 plus OBIEE infrastructure information and query statisics

Level 3 - All level 2 plus Cache information

Level 4 - All level 3 plus query plan execution

Level 5 - All level 4 plus intermediate row counts

Level 6 & 7 - not used

 

OBIEE log files

BI Component

Log File

Log File Directory

OPMN

debug.log

ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn

OPMN

opmn.log

ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn

BI Server

nqserver.log

ORACLE_INSTANCE/diagnostics/logs/
OracleBIServerComponent/coreapplication_obis1

BI Server Query

nquery<n>.log <n>=data and timestamp for example nqquery-20140109-2135.log

Oracle BI Server query Log

ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication

BI Cluster Controller

nqcluster.log

ORACLE_INSTANCE/diagnostics/logs/
OracleBIClusterControllerComponent/coreapplication_obiccs1

Oracle BI Scheduler

nqscheduler.log

ORACLE_INSTANCE/diagnostics/logs/
OracleBISchedulerComponent/coreapplication_obisch1

Useage Tracking

NQAcct.yyymmdd.hhmmss.log

STORAGE_DIRECTORY parameter in the Usage Tracking section of the NQSConfig.INI file determines the location of usage tracking logs

Presentation Services

sawlog*.log (for example, sawlog0.log)

ORACLE_INSTANCE/diagnostics/logs/
OracleBIPresentationServicesComponent/
coreapplication_obips1

 

The configuration of this log (e.g. the writer setting to output to syslog or windows event log) is set in instanceconfig.xml

BI JavaHost

jh.log

ORACLE_INSTANCE/diagnostics/logs/
OracleBIJavaHostComponent/coreapplication_objh1

 

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

 -Michael Miller, CISSP-ISSMP

References

 

Tags: Oracle Business Intelligence (OBIEE)AuditorIT Security
Categories: APPS Blogs, Security Blogs

OpenSSL Heartbleed (CVE-2014-0160) and Oracle E-Business Suite Impact

Mon, 2014-04-14 13:46

Integrigy has completed an in-depth security analysis of the "Heartbleed" vulnerability in OpenSSL (CVE-2014-0160) and the impact on Oracle E-Business Suite 11i (11.5) and R12 (12.0, 12.1, and 12.2) environments.  The key issue is where in the environment is the SSL termination point both for internal and external communication between the client browser and application servers. 

1.  If the SSL termination point is the Oracle E-Business Suite application servers, then the environment is not vulnerable as stated in Oracle's guidance (Oracle Support Note ID 1645479.1 “OpenSSL Security Bug-Heartbleed” [support login required]).

2.  If the SSL termination point is a load balancer or reverse proxy, then the Oracle E-Business Suite environment MAY BE VULNERABLE to the Heartbleed vulnerability.  Environments using load balancers, like F5 Big-IP, or reverse proxies, such as Apache mod_proxy or BlueCoat, may be vulnerable depending on software versions.

Integrigy's detailed analysis of use of OpenSSL in Oracle E-Business Environments is available here -

OpenSSL Heartbleed (CVE-2014-0160) and the Oracle E-Business Suite Impact Analysis

Please let us know if you have any questions or need additional information at info@integrigy.com.

Tags: VulnerabilityOracle E-Business Suite
Categories: APPS Blogs, Security Blogs

Integrigy Collaborate 2014 Presentations

Mon, 2014-04-14 13:05

Integrigy had a great time at Collaborate 2014 last week in Las Vegas.  What did not stay in Las Vegas were many great sessions and a lot of good information on Oracle E-Business Suite 12.2, Oracle Security, and OBIEE.  Posted below are the links to the three papers that Integrigy presented.

If you have questions about our presentations, or any questions about OBIEE and E-Business Suite security, please contact us at info@integrigy.com

References Tags: Oracle DatabaseOracle E-Business SuiteOracle Business Intelligence (OBIEE)
Categories: APPS Blogs, Security Blogs

OBIEE Security: Repositories and Three Layers of Security

Fri, 2014-04-11 05:00

This blog series reviewing OBIEE security has to this point identified how users are defined and authenticated within WebLogic, the major security concerns with WebLogic and how application roles are defined and mapped to LDAP groups within Enterprise Manager. We will now review OBIEE authorization, how OBIEE determines what data users can see after they login. 

The OBIEE Repository is comprised of three layers. A very simplistic summary is below:

  • Physical layer: Defines all database or data source connections (user id and passwords are entered and stored here), the physical table and columns, primary and foreign key relationships.  
  • Business Model Mapping layer (BMM):  Referencing the physical layer, here is where logical structures are built and aggregation rules are defined.  The BMM is really the heart of an OBIEE application
  • Presentation layer:  Referencing the BMM, this layer presents the tables and columns to end users. For example, remove unwanted columns or rename awkwardly named columns.
Object and Data Level Security

Object (Physical layer) and Data (BMM) level security is defined within the identity manager in the Repository. Object security can be set to either allow or deny access to a physical table or column. Data security allows rules to be applied to logical tables or columns (BMM layer). These rules can use static values as well as session variables.

Navigation:  Open identity manager within the RPD -> select user or role -> click on permissions

Identity Manager

Data Filter

 

Object Filter

Presentation Layer Security Rule

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

 -Michael Miller, CISSP-ISSMP

References Tags: ReferenceOracle Business Intelligence (OBIEE)Security Resource
Categories: APPS Blogs, Security Blogs

OBIEE Security: Repositories and RPD File Security

Fri, 2014-04-04 05:00

The OBIEE repository database, known as a RPD file because of its file extension, defines the entire OBIEE application. It contains all the metadata, security rules, database connection information and SQL used by an OBIEE application. The RPD file is password protected and the whole file is encrypted. Only the Oracle BI Administration tool can create or open RPD files and BI Administration tool runs only on Windows.  To deploy an OBIEE application, the RPD file must be uploaded to Oracle Enterprise Manager. After uploading the RPD, the PRD password then must be entered into Enterprise Manager.

From a security assessment perspective, who has physical access to the RPD file and the RPD password is critical. If multiple OBIEE applications are being used, the RPD passwords should all be different. It is also recommended that the RDP password be rotated per whatever policy governs critical database accounts and that production RPD passwords be different than non-production RPD passwords. 

Once deployed through WebLogic, RPD file (version 11g) is located here: 

ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/coreapplication_obisn/

 

Figure 1 Repository (RDP) File Define OBIEE Solutions

 

Figure 2 Windows based OBIEE BI Admin Tool