Oracle Security Blog

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.

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.

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.

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.

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.

Most Oracle E-Business Suite implementations do not fully take advantage of the auditing and logging features. These features are sophisticated and are able to satisfy most organization’s compliance and security requirements. 

PCI requirement 3.4 requires PAN data to be unreadable anywhere it is stored unless it is protected. With Release 12 credit cardholder data can be decrypted at any time as easily as it is encrypted by simply running the request set “Decrypt Sensitive Data Request Set” or any of the individual programs.

Creating clones and copies of production E-Business Suite databases is a regular occurrence. There are several PCI DSS requirements that apply to non-production instances of the Oracle E-Business Suite. 

The real challenge for meeting PCI compliance is the secure management of all the components and parts of the Oracle E-Business Suite environment every day of year. While Release 12 of the Oracle E-Business Suite by default does not protect cardholder data, it can be enabled. The steps are rather straight forward and can easily be completed in a non-production instance for testing.  Future blog posts will review the daily, weekly, monthly and annual PCI requirements once these basic PCI setups have been completed.

Continuing this blog series on PCI compliance and the Oracle E-Business Suite, this posting focuses on the Secure Payments Repository.  New with Release 12 of the E-Business Suite, credit card processing and data storage within Oracle Financials, for customer’s and vendor’s card data, is now done within the Secure Payment Data Repository within Oracle Payments.  It is through this new standard functionality built into the Secure Payment Data Repository that PCI DSS compliance can be met.

To help understand the Oracle E-Business Suite’s standard functionality to help meet PCI compliance, it is useful to know the difference between what Oracle deems as external and internal accounts.

A common question we receive is about Corporate Cards and PCI compliance. Corporate Cards, credit cards held by employees for corporate purposes, are not usually subject to the scope of PCI DSS compliance.  Corporate Cards are classified as internal accounts and PCI DSS applies only to external accounts.  The full definition of internal vs.

The next few blog postings will focus on PCI and the Oracle E-Business Suite.

PCI requirement 3.4 mandates that the Primary Account Number (PAN) is unreadable anywhere it is stored using one-way hashes or strong encryption. The Oracle E-Business Suite Release 12 meets this requirement first by centralizing cardholder data (into the Secure Payments Repository) and then applying strong encryption.

Oracle Payments offers two modes of encryption, full or partial, as well as immediate or scheduled. Which encryption options are selected should be the result of discussions with legal counsel, compliance and risk management. 

Through parameter and URL tampering an attacker, or nefarious insider, can manipulate and/or construct URLs to expose information and/or attempt to circumnavigate Oracle E-Business Suite functionality - including parts of application security. There are several profile options that provide defense in depth against cross-site scripting (XSS), HTML injection attacks, and parameter and URL tampering. Setting these profile options to the recommended values below will contribute to reducing your information leakage risks.

If you have questions, please contact us.