Oracle Security Blog

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?

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.

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.

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:

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.

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.

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.

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.

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. 

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

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:

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.

Come see Integrigy’s sessions at Collaborate 2014 in Las Vegas (http://collaborate14.com/). 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

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.

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.