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

Oracle E-Business Suite Security - Signed JAR Files - What Should You Do – Part II

Fri, 2014-07-11 05:00

In our blog post on 16-May, we provided guidance on Java JAR signing for the E-Business Suite. We are continuing our research on E-Business Suite Java JAR signing and will be presenting it in a forthcoming educational webinar. Until then we would like to share a few items of importance based on recent client conversations -

  • Apply latest patches - The latest patches for Oracle E-Business Suite JAR signing are noted in 1591073.1. There are separate patches for 11i, 12.0.x, 12.1.x and 12.2.x. To fully take advantage of the security features provided by signing JAR files the latest patches need to be applied.
  • Do not use the default Keystore passwords - Before you sign your JAR files change the keystore passwords.  The initial instructions in 1591073.1 note that a possible first step before you start the JAR signing process is to change the keystore passwords. Integrigy recommends that changing the keystore passwords should be mandatory. The default Oracle passwords should not be used. Follow the instructions in Appendix A of 1591073.1 to change both keystore passwords. Each password must be at least six (6) characters in length. If you have already signed your JAR files, after changing the keystore passwords you must create a new keystore and redo all the steps in 1591073.1 to create a new signed certificate (it is much easier to change the keystore passwords BEFORE you sign your JAR files).
  • The keystore passwords are available to anyone with the APPS password - Using the code below anyone with the APPS password can extract the keystore passwords. Ensure that this fact is allowed for in your polices for segregation of duties, keystore management and certificate security.

SQL> set serveroutput on
spass varchar2(30); 
kpass varchar2(30); 
ad_jar.get_jripasswords(spass, kpass); 

This will output the passwords in the following order:

store password (spass) 
key password (kpass)

If you have questions, please contact us at

References Tags: Security Strategy and StandardsOracle E-Business Suite
Categories: APPS Blogs, Security Blogs

Oracle E-Business Suite Security, Java 7 and Auto-Update

Wed, 2014-07-02 05:00

Maintaining a secure Oracle E-Business Suite implementation requires constant vigilance. For the desktop clients accessing Oracle E-Business Suite, Integrigy recommends running the latest version of Java 7 SE.  Java 7 is fully supported by Oracle with Public Updates through April 2015 and is patched with the latest security fixes. Most likely in late 2014 we anticipate that Oracle will have released and certified Java 8 with the Oracle E-Business Suite.

Most corporate environments utilize a standardized version of Java, tested and certified for corporate and mission critical applications. As such the Java auto-update functionality cannot be used to automatically upgrade Java on all desktops. These environments require new versions of Java to be periodically pushed to all desktops. For more information on how to push Java updates through software distribution see MOS Note 1439822.1. This note also describes how to download Java versions with the Java auto-update functionality disabled.

Keep in mind too that the version of Java used with the E-Business Suite should be obtained from My Oracle Support. Your Desktop support teams may or may not have Oracle support accounts.

Other points to keep in mind:

  • To support Java 7, the Oracle E-Business Suite application servers must be updated per the instructions in MOS Note 393931.1
  • “Non-Static Versioning” should be used the E-Business Suite to allow for later versions of the JRE Plug-in to be installed on the desktop client. For example, with Non-Static versioning JRE 7 will be invoked instead of JRE 6 if both are installed on a Windows desktop. With Non-Static versioning, the web server’s version of Java is the minimum version that can be used on the desktop client.
  • You will need to implement the Enhanced JAR File signing for the later versions of Java 7 (refer to Integrigy blog posting for more information)
  • Remember to remove all versions of Java that are no longer needed – for example JIinitiator

You may continue using Java 6.  As an Oracle E-Business Suite customer, you are entitled to Java 6 updates through Extended Support.  The latest Java 6 update (6u75) may be downloaded from My Oracle Support. This version (6u75) is equal to 7u55 for security fixes.

If you have questions, please contact us at



Tags: Security Strategy and StandardsOracle E-Business SuiteIT Security
Categories: APPS Blogs, Security Blogs

Trusting Privileged Users, DBMS_SQLHASH, and Three Misconceptions about Encryption

Thu, 2014-06-26 05:00

Clients often contact Integrigy requesting assistance to protect their sensitive data. Frequently these are requests for assistance to locate and then encrypt sensitive data. While encryption  offers protection for sensitive data, it by no means solves all security problems. How to protect sensitive data (and how to verify the trust of privileged users such as database administrators with sensitive data) requires more than just encryption.

The Oracle Database Security Guide (a great read for anyone interested in Oracle database security) makes three key points in Chapter Eight about encryption:

  1. Encryption does not solve access control problems - A user who has privileges to access data within the database has no more nor any less privileges as a result of encryption
  2. Encryption does not protect against a malicious database administrator - If untrustworthy users have significant privileges, then they can pose multiple threats to an organization, some of them far more significant than viewing unencrypted credit card numbers
  3. Encrypting everything does not make data secure – Data must be available when needed as well as backups and DR solutions considered. Moreover, encrypting all data will significantly affect performance.

Besides encryption, one of the security tools that Oracle provides is the DBMS_SQLHASH package. Hash values are similar to data fingerprints and can be used to validate if data has been changed (referred to as data integrity). Hashing is different from encryption and it is important to know the difference. If you need to know more about hashing, see the reference section below.  

The DBMS_SQLHASH package has been delivered since 10g and provides an interface to generate the hash value of the result set returned by a SQL query and provides support for several industry-standard hashing algorithms including SHA-1.

DBMS_SQLHASH.GETHASH(sqltext IN varchar2,

                                                digest_type IN BINARY_INTEGER,

                                                chunk_size IN number DEFAULT 134217728)



The SQL statement whose result is hashed


Hash algorithm used: HASH_MD4, HASH_MD5 or HASH_SH1

Use 3 for HASH_SH1, Use 2 for HASH_MD5 and 1 for HASH_MD4


Size of the result chunk when getting the hash

When the result set size is large, the GETHASH function will break it into chunks having a size equal to chunk_size. It will generate the hash for each chunk and then use hash chaining to calculate the final hash. The default chunk_size is 128 MB.


How Can Auditors use DBMS_SQLHASH

One use case for DBMS_SQLHASH is to help auditors trust-but-verify the actions of privileged users such as database administrators. By hashing key tables an auditor can quickly determine if the database administrator has made changes – either authorized or unauthorized. An auditor can do this by recording hashes at the start of an audit period for comparison to hashes at the end of the period. If the hashes at the end of the audit period match the hashes at the beginning of the period, no changes have been made. If there are a large number of databases and/or tables to audit, this approach is a very beneficial means of identifying what requires additional review – assuming sufficient logging has been configured to capture the details of the changes.

For example, to determine if there have been changes to Oracle database users and their associated privileges over a period of time, such as granting access to sensitive data, an auditor can hash the following Dictionary tables:



Note: to call the SYS.DBMS_SQLHASH package, the user will need execute rights granted from SYS.














































Key Point

The order by clause will change the HASH. Oracle Support Note 1569256.1 explains this in more detail.  To guarantee the same HASH for a SQL issued at different times, the same ordering of the data must be used.

If you have questions or are interested in Integrigy's hashing methodology for Oracle and the Oracle E-Business Suite, please contact us at

References Tags: AuditingSecurity Strategy and StandardsSensitive DataOracle DatabaseAuditor
Categories: APPS Blogs, Security Blogs

Splunk DB Connect Tail for Oracle E-Business Sign-on Audit

Fri, 2014-06-06 05:00

Integrigy has received a lot of great feedback about our Framework for logging and auditing the Oracle E-Business Suite.  The Framework is posted here.  The Framework is a direct result of our consulting experience and clients have found it equally useful to both those wanting to improve their auditing capabilities as well as those just starting to implement logging and auditing.  Our goal with the Framework is to provide a clear explanation of the native auditing and logging features available, present an approach and strategy for using these features and a straight-forward configuration steps to implement the approach.

The Framework is also specifically designed to help clients meet compliance and security standards such as Sarbanes-Oxley (SOX), Payment Card Industry (PCI), FISMA, and HIPAA. The foundation of the Framework is PCI DSS requirement 10.2.

Splunk DB Connect

The Framework defines three levels of maturity. Level one identifies basic logging, level two calls for passing log data to a centralized log management solution and level three is a continuous improvement loop where increasingly more data is correlated. Level two is the key step. Given the complexity of the Oracle E-Business Suite and compliance requirements for protection and non-repudiation of log data, a centralized logging solution is required.

Splunk, ArcSight, Envision and the Oracle Audit Vault all offer solutions for centralized logging. Recently a client was asking for assistance to implement our Framework using Splunk. Splunk has a native parser for Oracle Syslog as well as a free application to import data directly from tables. Splunk’s DB Connect provides real-time integration is an ideal solution to pull data from the E-Business Suite’s Sign-On Audit tables.

Sign-On Audit

Sign-On Audit is optional functionality to track end-user navigation activity in the professional forms (not Web or HTML forms).  It has three levels: Login, What Responsibility was used, and What Forms were visited.  For each option, the length of time is captured.  Only Navigation activity is a captured – it is important to understand that what the end-user did in the form, be it viewed a record or updated a record, is not captured.  If the requirement is to capture the end-user actions in the form, auditing must be enabled using Oracle E-Business Suite AuditTrail or third-party tools are required.

Sign-On Audit is turned off/on by the system profile option “Sign-On: Audit Level.”  If enabled, Sign-On Audit needs to regularly purge the data it collects.  This can be done using the Purge Concurrent Request and/or Manager Data concurrent program.

Sign-On Audit data is collected in real-time and can be viewed through standard reports, a Form, or by using SQL. The following are the tables for Sign-On audit data that can be used by Splunk’s DB Connect:

How to Tail Sign-On Audit activity using Splunk DB Connect

Below is a description of how to get starting using Splunk and DB Connect to implement Integrigy’s Framework for logging and auditing for the Oracle E-Business Suite. The sample is for how to tail the table APPLSYS.FND_LOGINS such that every hour Splunk will log into the E-Business Suite’s database and check if there are any new rows in the table. The high-level summary is a follows:

  1. Do this first in a development or test instance, do not attempt first in production.
  2. Obtain the documentation for the Splunk DB Connector and Integrigy’s Framework whitepaper.
  3. For this example, enable Sign-On audit if you have done so already.
  4. Install the Splunk DB Connector. To finish the installation you will need to install Java 1.6 (or greater) and/or reference the location of the Java Home. You will also need the Oracle JDBC driver. The installation of the Oracle JDBC driver for Splunk is well documented in the DB Connector instructions. The JAR file must be placed within the Splunk file system.
  5. Within Splunk create a database connection to the E-Business Suite. Integrigy’s recommendation is to create an appropriately privileged account (do not use APPS).
  6. Create an input to the Splunk database. These are referred to as ‘Database Inputs’. This is a key step. As a quick note be sure to reference all Oracle objects in UPPER CASE:
    1. Choose “Tail”.
    2. Select the database connection you defined earlier.
    3. For the table APPLSYS.FND_LOGINS, the following Specific SQL can be used to ignore scheduled concurrent program activity. Copy the following SQL exactly, including the last line with Splunk’s syntax for the rising column:





{{AND $rising_column$ > ?}}

  1. Identify the rising column, enter: LOGIN_ID
  2. Identify the index, as a quick demo to get going just use the default, enter: default
  3. Identify a Host Field value, you can enter the database SID, for example, VIS121
  4. Select the output format, use: multi-line key-value format
  5. Identify the timestamp column, enter: START_TIME
  6. Set the polling frequency or interval to hourly (default if left blank will be auto): 1h
  1. Test by logging into the Oracle E-Business Suite and then looking at Splunk.
  2. To fully implement the Integrigy Framework for logging and auditing the Oracle E-Business Suite, database auditing well as E-Business Suite auditing and Page Access Tracking  will need to be enabled, but you can repeat step five above for each table identified for logging E-Business Suite end-user navigation. The SQL used will differ from the above but should be straight forward. Keep in mind too that you will need enable both Sign-On Audit and Page Access Tracking in order to log end-user navigation within the Oracle E-Business Suite.


Figure 1 – Example of Searching Splunk for Oracle E-Business Suite Sign-On for the User SYSADMIN


If you have questions, please contact us at

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

Kerberos Authentication for Oracle - Benefits and Recommendations

Fri, 2014-05-30 05:00

Kerberos authentication support in the Oracle Database is now included with all editions of the Oracle Database.  Previously, Kerberos authentication required an Oracle Advanced Security Option license.  Since this licensing change, we have been working with our clients to design and implement database user authentication using Kerberos and Active Directory.  This allows for authentication and verification of database users using Active Directory without implementing other identify management products or servers.  Although, it does require both server and client-side configuration.

First, we need to note that there are three options for creation of users in an Oracle database - users can be identified as:

  • Locally – accounts and passwords are defined with the local database.
  • Externally – accounts and passwords are defined locally but authenticated by an external service, such as an operating system or third party service (e.g.  Active Directory or LDAP).  This includes Kerberos.
  • Globally – accounts and passwords are both defined outside the local database.  Authentication must be done through an external service.  This Oracle feature is called Enterprise User Security (EUS).
What is Kerberos?

Kerberos is not OS authentication.  Remote OS authentication is a security option where the Oracle database allowed a connection if the user has an open session within the operating system.  Remote OS Authentication is now obsolete and is no longer supported after Oracle 11gR1, however, it remains a feature only for backwards compatibility.

Kerberos is a network authentication protocol originally developed by the Massachusetts Institute of Technology (MIT).  Kerberos has for years been built into Microsoft Active Directory and is designed to authenticate users to network resources, such as Oracle databases. Kerberos uses tickets and symmetric-key cryptography to eliminate the need to transmit passwords over the network.

Previously, Oracle Kerberos Authentication was a component of Advanced Security Option (ASO) - Kerberos Authentication required an ASO license per database server. As of Fall 2013, Oracle Kerberos Authentication is no longer part of ASO and it can be used with any database edition for all supported versions of the database without additional licensing. (See Note 1375853.1 for further information.)

What does this mean?

Using Kerberos can improve security and save time and money. For Kerberos authenticated users, database administrators will still need to create accounts and assign roles, but they will no longer need to worry about password resets, nor will need they need to close accounts upon termination of employment (assuming the AD account is closed).

The benefits of using Kerberos will differ per client and the identity management strategy being pursued.

  • Consider Kerberos for named user accounts (end-users), not service accounts.
  • Existing users will need to be altered from locally defined to external.
  • Case sensitivity of user names can be an issue. Oracle by default creates usernames in upper case. AD is case in-sensitive. Kerberos authentication requires uppercase.
  • The Oracle database server must be in the AD domain or, if not, the krb5.conf file needs to explicitly include it in the realm mapping.
  • Oracle Kerberos authentication does not require any external Kerberos libraries to be added.
  • Be sure to log Kerberos authentication events in Splunk, ArcSight, or whatever your centralized logging solution may be

If you have questions, please contact us at



Tags: Security Strategy and StandardsOracle DatabaseIT Security
Categories: APPS Blogs, Security Blogs

Oracle E-Business Suite Denial of Service Attacks and Locking the APPS Password

Fri, 2014-05-23 05:00

My wake-up call one day last week came from an acquaintance. Somebody at his company typed the APPS password in wrong too many times and locked the APPS database account. This caused the Oracle E-Business Suite to lock-out ALL users from accessing the application and concurrent processing to stop. Since it was production, excitement ensued. By the time he had called me, the APPS password had been reset and the Oracle E-Business Suite was back up. The question was what do to prevent it from occurring in the future?

In order to provide a more secure default configuration, Oracle began setting the default profile FAILED_LOGIN_ATTEMPTS in 11g to 10 (failed logins). This profile is assigned to all database accounts by default, including the APPS account in Oracle E-Business Suite environments.  Thus, most are vulnerable to a very simple to execute denial of service attack. The risk of allowing the APPS password to be easily locked is essentially risking an intentional or unintentional denial-of-service attack.

As part of Integrigy’s standard security assessment checks for the Oracle E-Business Suite, we recommend that a custom database password profile be created for key service accounts such as APPS. In this custom profile for service accounts, FAILED_LOGIN_ATTEMPTS should be set high value or UNLIMITED for key application service accounts. To mitigate any risk of brute force attempts against these accounts, failed login attempts should be monitored and a PASSWORD_VERIFY_FUNCTION set to require password complexity and a minimum password length.

The default password profile should not be used. Integrigy recommends a set of custom profiles be developed and segment accounts into interactive service accounts, other service accounts, and named users.

What might be a few other denial-of-service attacks for the E-Business Suite? This not inclusive, but a few of them are:

  • If the profile option ‘Upload File Size Limit’ is not set, a user could potentially upload an inordinately large document or a number of large attached documents sufficient to consume storage to the point that the database would become inoperable. The file size limit should be set and be set appropriately small for your business processes.
  • If you are Internet facing, such as running iRecruitment, there is another profile option, ‘IRC: Document Upload Count Limit’ which limits the total number of documents that can be uploaded per user.
  • As well, if you are Internet facing, such as running iRecruitment or any other module that allows self-registration and creation of accounts, you should consider implementing CAPTCHA – these are the hard-to-read random words you need to retype that are used by web sites to prove you are a human. Someone with nefarious intent could create numerous bogus E-Business Suite user accounts (most likely through automation) sufficient to interfere with the normal operation of the Suite.  See the reference below for the Oracle Support note for how to implement CAPTCHA.
  • Not directly related to the E-Business Suite, but those accounts used in OBIEE data source connections (defined in the RPD) should certainly be treated the same as what is suggested above for the APPS account. Locking the accounts used for data connections will render OBIEE unusable for users.

 If you have questions, please contact us at

References Tags: DMZ/ExternalOracle E-Business Suite
Categories: APPS Blogs, Security Blogs

How To Stop Insiders from Stealing Your Secrets – Recommendations on Rings of Security

Mon, 2014-05-19 07:27

For those of you who attended our webinar on 15-May-2014 on how to secure privileged users, Bruce Schneier’s blog post on 5/16/2014 will be of interest. The post was titled “How to Stop an Insider from Stealing All Your Secrets”. In the post he referenced a magazine article by Bob Toxen in the Communications of the ACM.

Bob Toxen’s article is here and it is a fascinating read on Edward Snowden’s exploits at the NSA and what should have been in place to stop him. The article reviews best practices for “Rings of Security” with which to protect against insider threats from privileged users. Of particular interest were Bob’s comments about the NSA’s use of SharePoint and his recommended best practices for the implementation and use of SSH (Secure Shell).

If you have questions or comments on this topic, please contact us at We would enjoy hearing from you.

References Tags: AuditingSecurity Strategy and StandardsSensitive Data
Categories: APPS Blogs, Security Blogs

Oracle E-Business Suite Security - Signed JAR Files - What Should You Do

Fri, 2014-05-16 05:00

Until recently the Oracle E-Business Suite allowed self-designed certificates to assure the validity of Java code run within end-users’ browsers. This meant that the Java JAR files downloaded from the middle tier server were tested by the end-user’s browser for validity using a certificate created by you and/or you organization during installation. Use of a Trusted Certificate Authority (CA) issued certificate, while always an option for enhanced security, is now a requirement. Oracle has recently deemed self-signed certificates as no longer being secure. Oracle strongly recommends that Oracle E-Business Suite users now sign their Java content using a Trusted CA.

  • Does this apply to me? This requirement applies to you if you are running the later JRE releases – specifically 7u40 or above. As Oracle releases new versions of Java over time, and for many good security reasons, Integrigy recommends that you start signing your JAR files using a Trusted CA.
  • What is Java JAR signing? - In short, signing code confirms the author of the code (where it is coming from) and that code has not been altered or corrupted. Each file in the Java archive (JAR) is programmatically profiled and an inventory file is then added to the JAR file. You then sign this inventory file using public key encryption. You sign using your private key and, once signed, your public key is then automatically inserted into the JAR file – this is your digital certificate of authenticity. When the JAR file is used, the end-user’s browser will verify your public key to test whether or not it should trust the JAR file. You buy your public and private keys from a Certificate Authority (CA). A good reference on Java JAR signing is here.
  • How do I sign E-Business JAR files? -  Follow the instructions in the Oracle Support note ID 1591073.1 to generate a certificate request, send the request to a CA, import the certificate once it has been generated by the CA and then regenerate your JAR files using the adadmin utility.
  • What is a CA? Will this cost money? A CA usually is a third party such as Verisign or Thawte, who for a fee, will sell you a certificate. This certificate will then be verified by the master root certificates that ship with all major browsers. You can also be your own CA. However, if you decide to be your own CA, you will need to take responsibility for distributing your CA root certificates throughout your end-user community’s desktops and laptops.  
  • Can I use an existing SSL certificate to sign my Java JAR files? No you cannot. The two certificates are used for two different purposes. The SSL certificate authenticates your server and the code signing certificate verifies the authenticity of the code on the server. As such the two certificates are built differently to do two different tasks.
  • Why is Oracle not signing their code? – There is an enhancement request for Oracle do this. There are also several reasons why Oracle is not signing their code that involve their flexibility to package and ship patches.
  • Can I ignore this? – Talk with your IT security team. Depending on your version of Java there are options to setup a “whitelist” of applications that can ignore checking for signed code. This involves using “Exception Site Lists” or “Deployment Rule Sets”.   If you attempt to use Deployment rule sets, you will need to distribute files to each end-user’s desktop. This is however, after you have a CA sign the DeploymentRuleSet.jar. Use of Deployment Rule Sets are typically used as an additional security tool along with signed JAR files.
  • Will this require downtime? – Most likely yes. You may need to apply patches to begin signing code, and to sign your JAR files, the Application tier will need to be stopped while your JAR files regenerated.
  • How often will I need to sign JAR files? - Every time you patch or potentially clone, depending on if, or how, you decide to share certificates among production, test and development.
  • Can I share certificates among instances? - Yes. One certificate can be used for or multiple E-Business Suite environments. 
  • How should I protect my Private Key used to sign JAR files? – Very carefully is the answer. Do not leave your private key (adkeystore.* files) on the middle tier. Securely wipe it from the operating system after using it and store it in a secure location. You can also potentially use solutions from Vendor such as Symantec or Vormetric who offer hardware security modules, smart cards and smart card-type devices such as USB tokens. Lastly, you can also just use a USB thumb drive that is locked in a safe.
  • What should I do? - Java security is only to become more stringent over time.  Integrigy recommends that you start signing your code, preferably using a certificate from a third party CA. Set aside time for a small project and be prepared to apply patches and make changes to your cloning and post-cloning steps and procedures depending on if, or how, you decide to share certificates among production, test and development.

If you have questions, please contact us at

References Tags: Security Strategy and StandardsOracle E-Business SuiteDBAIT Security
Categories: APPS Blogs, Security Blogs

PreInstall RPM Makes Oracle Database Installation Easy

Mon, 2014-05-12 06:41

Last week I had to build an Oracle 11gR2 database in the lab. Usually this process involves selecting one of several VirtualBox VM images for an appropriate Oracle Enterprise Linux (OEL) build and then several hours of effort. I selected a basic OEL6 image then instead decided to try out Oracle’s preinstall RPM package for Oracle database installations. I had heard about these packages that automate several of the more tedious pre-installation tasks such as modifying kernel parameters and installing and resolving required software packages.

The RPMs respectively are named:

  • oracle-rdbms-server-11gR2-preinstall

  • oracle-rdbms-server-12cR1-preinstall

The result was that it worked and I was surprised how easy it was.  Starting with a basic OEL6 image I followed the blog post referenced below. The first attempt resulted in strange errors deep into the install which when researched proved to be only the result of running out of file system space. I had opted to run the yum update prior to running the database install. Evidently this sufficiently filled my root file system to force errors. I trashed the VirtualBox image and selected a new OEL6 image with more space, ran the preinstall 11gR2 RPM and then let the database install program run before going off to a meeting. When I got back, my database was installed and running.

Overall for the lab this worked well, but for a production environment I would recommend validating all configuration steps performed by the preinstall RPM.

If you have questions, please contact us at

-Michael Miller, CISSP-ISSMP

References Tags: Oracle Database
Categories: APPS Blogs, Security Blogs

OBIEE Authentication Using the Oracle E-Business Suite

Fri, 2014-05-02 05:00

There are two primary options for sharing authentication solutions with the Oracle E-Business Suite. The Oracle E-Business Suite and OBIEE both can take advantage of Oracle’s Single Sign-On (SSO) solutions. If SSO is used, both OBIEE and the E-Business Suite would be subscribing applications.

The other option is for OBIEE to use the Oracle E-Business Suite for authentication. This solution requires that users first log into the E-Business Suite and from there exercise (click-on) a menu function to bring them into OBIEE without having to type a user name or password.

OBIEE and Oracle E-Business Suite Integration

Configuring OBIEE to use the Oracle E-Business Suite for authentication is straight forward and can be completed in a test environment with only a small amount of effort.  It is technically accomplished through the sharing of the E-Business Suite session cookie.

Further documentation on the specific steps to configure OBIEE to use the E-Business Suite for authentication can be found on Metalink as well as in the OBIEE documentation.  A high level summary is as follows:

  1. Using the BI Admin client tool, modify the RPD file to add a connection to the E-Business Suite database.
  2. Add an initialization block to the RPD file that calls the E-Business Suite API APP_SESSION.validate_icx_session and then call FND_GLOBAL to collect the variables resp_id, resp_appl_id, security_group_id, resp_name, user_id, employee_id and user_name.
  3. Edit the OBIEE configuration files authenicationschema.xml and instanceconfig.xml
  4. Create a menu function to launch OBIEE. You must use the SSWA OracleOasis.jsp$mode=OBIEE
  5. Populate the system profile option ‘FND: Oracle Business Intelligence Suite EE base URL’ with the url for OBIEE. For example:
  6. Upload the modified RPD file using Enterprise Manager and bounce all OBIEE services
Technical Summary

Authentication integration between OBIEE and the E-Business Suite is through a combination of a shared session cookie and a dynamic URL. The key to making it work are edits to OBIEE’s instanceconfig.xml configuration file. It is in this file that OBIEE instructed is to look for the E-Business Suite session cookie.


If you have questions, please contact us at

 -Michael Miller, CISSP-ISSMP

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

OBIEE Security: Questions IT Security and Audit Should Ask

Fri, 2014-04-25 05:00

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.




Level of access

Full or read-only access, on a single user

Full access

Users whose identity can be assumed by the proxy user

Defined list of users

Any and all users, anytime

Access method

Standard functionality of UI

Construct URL manually

How to know if being used

Both proxy and Target are shown in the UI

No indication given

Security risk

Little to none

Credentials exposed in plain text when URL submitted


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.


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

 -Michael Miller, CISSP-ISSMP

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

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:


  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

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