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: 7 hours 13 min ago

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 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







BI Server



BI Server Query

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

Oracle BI Server query Log


BI Cluster Controller



Oracle BI Scheduler



Useage Tracking


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)



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




If you have questions, please contact us at

 -Michael Miller, CISSP-ISSMP



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

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

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

 -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: 



Figure 1 Repository (RDP) File Define OBIEE Solutions


Figure 2 Windows based OBIEE BI Admin Tool


If you have questions, please contact us at

 -Michael Miller, CISSP-ISSMP

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

Come See Integrigy at Collaborate 2014

Mon, 2014-03-31 05:00

Come see Integrigy’s sessions at Collaborate 2014 in Las Vegas ( Integrigy is presenting the following papers:

IOUG - #526 Oracle Security Vulnerabilities Dissected, Wednesday, April 9, 11:00am

OAUG – #14365 New Security Features in Oracle E-Business Suite 12.2, Friday April 11, 9:45am

OAUG – #14366 OBIEE Security Examined, Friday, April 11, 12:15pm

If you are going to Collaborate 2014, we would also be more than happy to talk with you about your Oracle security projects or questions. If you would like to talk with us while at Collaborate please contact us at

Tags: ConferencePresentation
Categories: APPS Blogs, Security Blogs

OBIEE Security: User Authentication, WebLogic, OPSS, Application Roles and LDAP

Fri, 2014-03-28 05:00

Where and how are OBIEE users authenticated? A few options exists. A later blog post will review how to use the Oracle E-Business Suite to authenticate user connections and pass the E-Business Suite session cookie to OBIEE. Many if not most OBIEE users will though authenticate through WebLogic. For these users, they are defined and authenticated within WebLogic using it’s built in LDAP database or an external LDAP implementation. Once authenticated, the user’s LDAP group memberships are mapped to Applications roles that are shared by all Fusion Applications, OBIEE included.

WebLogic and Oracle Platform Security Services (OPSS)

As a Fusion Middleware 11g product, OBIEE 11g uses Oracle WebLogic for centralized common services, including a common security model. WebLogic Security Realms define the security configurations required to protect the application(s) deployed within WebLogic and consist of definitions of users, groups, security roles and polices.

If at all possible, Integrigy Corporation recommends using the default realm as a baseline to configure a new Realm for OBIEE. Integrigy Corporation highly recommends that each security realm attribute be thoroughly understood.

To implement Security Realm configurations, all Fusion Middleware applications use a security abstraction layer within WebLogic called the Oracle Platform Security Services (OPSS). OPSS is not the same as WebLogic security. WebLogic consumes OPSS services and frameworks (for example authentication). OPSS provides three key services:

  • An Identity Store, to define and authenticate users
  • A Credential Store, to hold the usernames, passwords and other credentials that system services require.
  • A Policy Store, containing details of user groups and application roles, application policies and permissions. The policy store is used to authorize users (what can they do?) after they are authenticated.

Enterprise Manager and Application Roles

Application roles are new with OBIEE 11g and replace groups within OBIEE 10g. The migration of application roles out of OBIEE allows a common set of roles to be define across all Fusion Middleware products and applications.

Application roles and Application Policies are managed in Oracle Enterprise Manager - Fusion Middleware Control.  This is where LDAP groups are mapped to application roles and detailed permissions are assigned to the application roles. The key concept is that LDAP groups can be assigned to both Fusion users and Fusion Application roles, LDAP users are never individually or directly assigned permissions and grants within OBIEE.

The out-of-the-box installation of OBIEE delivers three main application roles. These roles may be granted to individual users or to LDAP groups.  During the implementation or at any time new roles can be created and existing roles changed.

Default OBIEE Application Roles

Application Role

LDAP Group*





Base-level role that grants the user access to OBIEE analyses, dashboards and agents.  Allows user to run or schedule existing BI Publisher reports, but not create any new ones




All BIConsumer rights, grants and permissions but also allows users to create new analyses, dashboards and other BI objects




All BIAuthor rights, grants and permissions (and therefore BIConsumer) as well as allows the user to administer all parts of the system, including modifying catalog permissions and privileges

 *Note the naming convention difference of plural vs singular for Application Roles

If you have questions, please contact us at

 -Michael Miller, CISSP-ISSMP

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

OBIEE Security and WebLogic Scripting Tool (WLST)

Fri, 2014-03-21 05:00

Continuing our blog series on OBIEE security, when discussing WebLogic security, the WebLogic Scripting Tool (WLST) needs to understood. From a security risk perspective, consider WLST analogous to how DBAs use SQL to manage an Oracle database. Who is using WLST and how they are using it needs to be carefully reviewed as part of any WebLogic security assessment.

WebLogic Scripting Tool (WLST)

The WebLogic Scripting Tool (WLST) is a command-line scripting environment that is used to create, manage, and monitor WebLogic. It is based on the Java scripting interpreter, Jython, version 2.2.1. In addition to supporting standard Jython features such as local variables, conditional variables, and flow control statements, WLST provides a set of scripting functions (commands) that are specific to WebLogic Server.

From a security risk perspective, consider WLST analogous to how DBAs use SQL to manage an Oracle database. Who is using WLST and how they are using it needs to be carefully reviewed as part of any WebLogic security assessment.

WLST uses the WebLogic Security Framework to enforce the same security rules as when using the WebLogic user interface. WLST scripts, similar to SQL scripts, are created and edited using any text editor and the operating system user running a WLST script can easily be different than the user referenced in the script. WLST scripts can be run in either on or offline mode and, aside from modifying and copying configurations, (e.g. to create a test server), they can be used to add, remove, or modify users, groups, and roles.

Securing the WLST Connection

Both Integrigy Corporation and Oracle recommend that when using WLST only connect through the administration port. The administration port is a special, secure port that all WebLogic Server instances in a domain can use for administration traffic.

By default, this port is not enabled, but it is recommended that administration port be enabled in production. Separating administration traffic from application traffic ensures that critical administration operations (starting and stopping servers and changing configurations) do not compete with application traffic on the same network connection.

The administration port is required to be secured using SSL. As well, by default, the demonstration certificate is used for SSL. The demo SSL certificate should not be used for production.

Writing and Reading Encrypted Configuration Values

Some attributes of a WebLogic Server configuration are encrypted to prevent unauthorized access to sensitive data. For example, JDBC data source passwords are encrypted.  It is highly recommended to follow the WebLogic scripting tool documentation for specific instructions on working with encrypted configuration values however WLST is used - manually (ad-hoc), in scripts, offline and on line. A security assessment should include a discussion, if not a review, of WLST scripts that set or manipulate encrypted values.

Running WLST Scripts

WLST scripts permit unencrypted passwords at the command line. WebLogic security policies need to address how WLST scripts should provide passwords. Storing passwords incorrectly can easily and needlessly expose passwords in scripts, on monitor screens and in logs files. When entering WLST commands that require an unencrypted password, the following precautions should be taken:

  • Enter passwords only when prompted. If a password is omitted from the command line, it is subsequently prompted for when the command is executed
  • For scripts that start WebLogic Server instances, create a boot identity file. The boot identity file is a text file that contains user credentials. Because the credentials are encrypted, using a boot identity file is much more secure than storing unencrypted credentials in a startup or shutdown script.
  • For WLST administration scripts that require a user name and password, consider using a configuration file. This file, can be created using the WLST storeUserConfig command and contains:
    • User credentials in an encrypted form
    • A key file that WebLogic Server uses to unencrypt the credentials

If you have questions, please contact us at

 -Michael Miller, CISSP-ISSMP

References Tags: Oracle Fusion MiddlewareOracle Business Intelligence (OBIEE)
Categories: APPS Blogs, Security Blogs

OBIEE Security Examined: WebLogic Security

Fri, 2014-03-14 05:00

As the first post in Integrigy’s blog series on OBIEE security, it makes sense to first look at WebLogic. As a Fusion Middleware 11g product, OBIEE 11g uses Oracle WebLogic for centralized common services, including a common security model. WebLogic itself is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server. The WebLogic Server infrastructure is based on a Service Oriented Architecture (SOA) which allows it to be the foundation for many different types of applications.  Oracle Corporation describes the WebLogic Server security architecture as “providing a comprehensive, flexible security infrastructure designed to address the security challenges of making applications available on the Web.”

Our webinar on 19-March will review OBIEE security, please register through the link below if you are interested.

When considering WebLogic security, the following points should be kept in mind:


Before installing WebLogic, have an expert review network services to ensure that a malicious attacker cannot access the operating system or system-level commands. Use a DMZ if exposing OBIEE functionality on the Internet. Also use SSL to protect client communications and configure all Fusion Middleware Applications to use SSL.  The OHS web services commonly use 4443 (not 7777) on the firewall and 9704 internally for OBIEE reporting services.

Many OBIEE implementations take advantage of mobile access outside the firewall (e.g. iPad or tablets). The OBIEE mobile interface uses the same authentication within WebLogic. No additional authentication configurations are required.

Operating System Accounts

WebLogic should be installed and started by a single operating user purposely created to support WebLogic. If possible avoid choosing an obvious name for this user. Do not use demo or sample user accounts and passwords.

As a security best practice, WebLogic must not be run as a privileged user or as root. For UNIX installations this requires additional steps to be taken because with UNIX, only processes that run under a privileged user account (usually root) can bind to ports lower than 1024.  Because WebLogic, as an Application Server is a long running process that needs to communicate on lower ports such as 80 or 443, there are two commonly used options:

  • Start WebLogic under the privileged user account, bind to the privileged ports, and then change its user ID to a non-privileged account
  • Start WebLogic using a non-privileged account and configure the firewall to use Network Address Translation (NAT) software to map protected ports to unprotected ones
File Permissions

Only install WebLogic on a host that can prevent unauthorized access to protected resources. For example, on a Windows computer, use only NTFS. Access to the WebLogic configuration files must be carefully restricted to the WebLogic administrators, ideally on an as needed basis only. No other operating system user should have read, write, or execute access to WebLogic Server product files or domain files.

The file permissions for the following directories are critical for securing WebLogic. These directories should be appropriately restricted:

  • Middleware Home directory
  • WebLogic Server product installation directory
  • WebLogic domain directories
  • Persistence Store

If you have questions, please contact us at

 -Michael Miller, CISSP-ISSMP

Please Note:
  • Register for March 19th Webinar: OBIEE Security Examined
  • Collaborate 2014 session OAUG – #14366 OBIEE Security Examined, Friday, April 11, 12:15pm
Tags: Oracle Fusion MiddlewareOracle Business Intelligence (OBIEE)
Categories: APPS Blogs, Security Blogs

Oracle Business Intelligence Enterprise Edition (OBIEE) Security Examined

Tue, 2014-03-11 05:00

Oracle’s Business Intelligence Enterprise Edition (OBIEE) 11g is a powerful tool for accessing data, however this power means OBIEE security is imperative in order to protect the data. Throughout March and April 2014 Integrigy will be focusing our blog posts on the security of all layers of the OBIEE technology stack: the OBIEE application, the WebLogic application server, and the repository database. In addition, the topic of the monthly webinar for March will be OBIEE security.

As OBIEE is part of the Oracle Fusion Middleware product suite, a review of Oracle WebLogic’s security features will be followed by a discussion of security features of each layer of the OBIEE technology stack.  Figure 1 graphically depicts the architectural components of OBIEE.  The sizes of the boxes are relative to the importance of OBIEE security.

If you have questions, please contact us at

 -Michael Miller, CISSP-ISSMP

Please Note:
  • Register for March 19th Webinar here: OBIEE Security Examined
  • Collaborate 2014 session OAUG – #14366 OBIEE Security Examined, Friday, April 11, 12:15pm


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

Oracle E-Business Suite Logging and Auditing: Page Access Tracking

Thu, 2014-03-06 21:00

Sign-On Audit only logs professional forms activity – it does not log Oracle Applications Framework (OAF) user activity.  Page Access Tracking is required to log OAF activity.  Once enabled, the level of logging needs to be set as well as flagging those applications to be logged and has negligible overhead.

To configure Page Access Tracking, use the following navigation: System Administration -> Oracle Applications Manager -> Site Map > Monitoring > Applications Usage Reports > Page Access Tracking.

Once enabled, Page Access Tracking requires two concurrent programs to be run.  The program Page Access Tracking Data Migration must be run to move data from the staging tables into the reporting tables.  This is usually done daily.  To purge data on a regular basis, run the program Page Access Tracking Purge Data.

The levels of logging are:

  • Session info
  • Session Info and Cookies
  • Session Info, Cookies and URL Parameters
  • Session Info, Cookies and All Parameters

Once configured, reports can be run for the following types of activity:

  • Session
  • Date
  • Form
  • User
  • Application
How to do you know if Page Access Tracking is enabled?
  • Check the system profile option JTF_PF_MASTER_ENABLED and if it set to TRUE for monitoring Web Access
  • Check the system profile option JTF_PF_LEVEL. This will be set for each Application. As well, it can be set for Responsibilities and users:




Session info


Session Info and Cookies


Session Info, Cookies and URL Parameters


Session Info, Cookies and All Parameters


What Tables Store Page Access Tracking Data?

The table below identified the tables used to store Page Access Tracking data. Remember that the concurrent programs Page Access Tracking Data Migration and Page Access Tracking Purge Data respectively insert data into and remove data from these tables.

Page Access Tracking Tables







Figure 1 - Page Access Tracking Configuration Page


Figure 2 - Page Access Tracking Configuration Screen

If you have questions, please contact us at

 -Michael Miller, CISSP-ISSMP

References Tags: AuditingOracle E-Business Suite
Categories: APPS Blogs, Security Blogs

Oracle E-Business Logging and Auditing: PCI, SOX, HIPAA, 27001 and FISMA

Thu, 2014-02-27 21:00

Continuing this blog series on Oracle E-Business logging and auditing, Integrigy’s log and audit framework is based on our consulting experience. We have also based it on compliance and security standards such as Payment Card Industry (PCI-DSS), Sarbanes-Oxley (SOX), IT Security (ISO 27001), FISMA (NIST 800-53), and HIPAA.

The foundation of the framework is the set of security events and actions that should be audited and logged in all Oracle E-Business Suite implementations.  These security events and actions are derived from and mapped back to key compliance and security standards most organizations have to comply with.  We view these security events and actions as the core set and most organizations will need to expand these events and actions to address specific compliance and security requirements, such as functional or change management requirements.

Figure 1 - Integrigy's Framework for Auditing and Logging in Oracle E-Business Suite