Skip navigation.

Security Blogs

Oracle Database 12c Security Auditing

Pete Finnigan - Tue, 2014-03-04 09:20

I started to ask a question a few blog posts ago about how does the 12cR1 database affect database security audits. I have decided to come back to it now as it is a good chance to do so. I....[Read More]

Posted by Pete On 08/07/13 At 05:31 PM

Categories: Security Blogs

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

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

Table 1 presents the core set of audits that, if implemented, will serve as a foundation for more advanced security analytics.  Implementing these audits will go a long way toward meeting logging and auditing requirements for most compliance and security standards like PCI requirement 10.2.  The numbering scheme used in Table 1 will be referenced throughout the framework.

 

Table 1 – Foundation Events for Logging and Security Framework

Security Events

and Actions

PCI

DSS 10.2

SOX (COBIT)

HIPAA

(NIST 800-66)

IT Security

(ISO 27001)

FISMA

(NIST  800-53)

E1 - Login

10.2.5

A12.3

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E2 - Logoff

10.2.5

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E3 - Unsuccessful login

10.2.4

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

A.11.5.1

AC-7

E4 - Modify authentication mechanisms

10.2.5

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E5 – Create user account

10.2.5

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E6 - Modify user account

10.2.5

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E7 - Create role

10.2.5

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E8 - Modify role

10.2.5

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E9 - Grant/revoke user privileges

10.2.5

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E10 - Grant/revoke role privileges

10.2.5

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E11 - Privileged commands

10.2.2

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

E12 - Modify audit and logging

10.2.6

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

AU-9

E13 - Objects:

Create object

Modify object

Delete object

10.2.7

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

AU-14

E14 - Modify configuration settings

10.2.2

DS5.5

DS5.6

DS9.2

164.312(c)(2)

A 10.10.1

AU-2

 

Integrigy’s Framework for Oracle E-Business Suite logging and auditing is fully documented in our whitepaper. The whitepaper is available for download in the link referenced below.

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

 -Michael Miller, CISSP-ISSMP

 

References Tags: AuditingSecurity Strategy and StandardsComplianceSarbanes-Oxley (SOX)PCIFISMA/DODHIPAAOracle E-Business SuiteAuditor
Categories: APPS Blogs, Security Blogs

Oracle E-Business Logging and Auditing, CMM and SIEM

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. 

The default Oracle E-Business Suite installation only provides a basic set of logging functionality.  In Integrigy’s experience, the implementation of database and application logging seldom exceeds meeting the needs of basic debugging.  Most organizations do not know where to start or how to leverage the built-in auditing and logging features to satisfy their compliance and security requirements.

Even organizations already using centralized logging or Security Incident and Event Management (SIEM) solutions, while being more advanced in the Common Maturity Model (CMM), in Integrigy’s experience are commonly challenged by the E-Business Suite’s auditing and logging features and functionality.

This guide presents Integrigy’s framework for auditing and logging in the Oracle E-Business Suite.  This framework is a direct result of Integrigy’s consulting experience and will be equally useful to both those wanting to improve their capabilities as well as those just starting to implement logging and auditing.  Our goal 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.

Integrigy’s 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.

To make it easy for clients to implement, the framework has three maturity levels – which level a client starts at depends on the infrastructure and policies already in place.

The three levels are:

  • Level 1 – Enable baseline auditing and logging for application/database and implement security monitoring and auditing alerts
  • Level 2 – Send audit and log data to a centralized logging solution outside the Oracle Database and E-Business Suite
  • Level 3 – Extend logging to include functional logging and more complex alerting and monitoring

This blog series will be reviewing the Framework in detail. The full whitepaper is available for download – the link is referenced below.

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

 -Michael Miller, CISSP-ISSMP

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

Oracle E-Business Suite PCI DSS Compliance, Requirement 3.4 and Decryption Risk

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.

Integrigy Corporation highly recommends removing the request set, as well as the concurrent programs within it, from all request groups and then disabling (end-date the request set and disable its concurrent programs.  If for any reason the programs need to be run at a later date, they can be enabled. This will help prevent accidental decryption along with nefarious attempts to access cardholder data.

It is also highly recommended by Integrigy Corporation to set up special monitoring for these Decrypt Sensitive Data concurrent programs in production (non-production instances cannot have live credit cardholder data per requirement 6.4.3). Oracle Alerts can be configured if other monitoring tools do not exist.  Whatever monitoring process is setup it needs to be monitored daily to ensure that these programs are not run.

When not in use remove from all request groups and disable:

Request set (end-date)

  • Decrypt Sensitive Data Request Set

Concurrent Programs (disable)

  • Decrypt Credit Card Data
  • Decrypt External Bank Account Data
  • Decrypt Transaction Extension Data
  • Decrypt Credit Card Transaction Data
  • Payments Scheduled Decryption
Further Information

For further information on PCI compliance, Corporate Cards and the E-Business Suite please refer to our whitepaper in the link below.

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

 -Michael Miller, CISSP-ISSMP

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

Oracle E-Business Test and Development Databases and PCI Compliance

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. 

No Production Cardholder Data

The most important PCI DSS requirement that applies to non-production instances is requirement 6.4.3 which forbids production cardholder data to be used for development, testing, training and/or any other reason or purpose other than supporting business transactions in production.  Production cardholder data cannot exist outside production. Non-production instances need to have production cardholder data either removed or scrambled.

Protect Production Encryption Keys

Requirement 3.5 governs the protection and management of encryption keys which when applied to non-production databases means that production encryption keys (specifically the Payment Wallet) cannot be copied to and/or exist in non-production instances. If, for whatever reason, the production wallet is copied to a non-production instance, the production encryption key MUST be rotated and the production wallet MUST be destroyed by a secure wipe (not just deleted from the file system). If the non-production instance is virtualized, depending on how memory is locked or shared to the guest, a secure wipe may be even more critical.

Building Non-Production Instances

The points below highlight the requirements to build non-production instances:

  • The production Payment Wallet will need to be rotated and securely wiped if copied from production.
  • The location of the Payment Wallet will need to be reset. Do not use SQL to update to table IBY_SYS_SECURITY_OPTIONS directly. The user interface must be used to update the file location.
  • Remove, purge and/or scramble production cardholder data. Depending on requirements there are several options for creating and sanitizing cardholder data. These options make use of the fact that cardholder data (the PAN and supplemental data) is separate and different from the related business transaction and that the cardholder data is centralized within the Secure Payment Repository.

For further information on PCI compliance, Corporate Cards and the E-Business Suite please refer to our whitepaper in the link below.

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

 -Michael Miller, CISSP-ISSMP

References

 

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

Enabling Credit Card PCI Protection for 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.

Three Basic Steps

There are the three basic steps to enable PCI protection for a new Release 12 implementation are:

  1. Create Payment encryption wallet
  2. Set protection configuration options
  3. Encrypt existing cardholder data
  Step 1: Create the Payment Encryption Wallet

With Release 12, the most critical step in meeting PCI DSS is the creation and on-going protection and maintenance of the Payment encryption wallet. There are several decisions to be made before creating a Payment Wallet. Wallets can either be self-signed, where the certificate is the same as the subject, or use a third party certificate from a well-known Certificate Authority. Which type of wallet is created is dependent on your trust requirements and expected usage. Payment Wallets must also be backed up separately from the E-Business database.

Step 2: Set Protection Configuration Options

Setting the protection configuration options is done using the Funds Capture Setup Administrator or Payments Setup Administrator responsibility. The decisions regarding which options to use should be carefully reviewed with internal audit, security and counsel.

  • Wallet - Location of the wallet file, the name of the wallet and the wallet password. Another decision is the whether the system key will be system generated or user defined. Integrigy Corporation recommends using a system generated key unless specific requirements are identified.
  • Account Number - Yes or No to encrypt the credit card number - select ‘Yes’
  • Supplemental data - Yes or No whether card holder name and expiration date will also be encrypted. This is also referred to as partial encryption if set to ‘No’.
  • Type – Whether or not encryption will occur immediately prior to being written to the database or later at a scheduled time. The options are ‘Immediate’ or ‘Scheduled’.  If you select scheduled, data will be unencrypted until the request set ‘Encrypt Sensitive Data Request Set’ is run.  Oracle does not automatically schedule this and it will need to be manually scheduled.  Integrigy Corporation strongly recommends using ‘Immediate’ and not ‘Scheduled’.
  • Card Owner Verification – Requiring the ‘Security Code’ and/or ‘Require Statement Billing Address’ by setting to ‘Yes’ requires the entry of the credit card security code or card statement billing address. This information is passed to the payment system, which in turn, checks with the credit card issuer to confirm the credit card owner's security code and/or statement billing address.
  • Credit Card Masking - Allows for masking of all but the first or last x digits of a PAN, for which x is identified by the field ‘Number of Digits to Display.

Step 3: Encrypt Existing Cardholder data

Cardholder data created prior to setting the encryption configurations will not be automatically encrypted. To encrypt cardholder data that already exists run the request set ‘Encrypt Sensitive Data Request Set’.

Next Blog Posting

In the next blog posting we will review the PCI requirements for creating non-production instances from copies of production.

For further information on PCI compliance, Corporate Cards and the E-Business Suite please refer to our whitepaper in the link below.

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

 -Michael Miller, CISSP-ISSMP

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

Oracle E-Business Suite, PCI Compliance and the Secure Payments Repository

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.

With Release 12, the Oracle E-Business Suite has eleven modules that use Oracle Payments for the processing and storage of cardholder data.  Only these eleven products can be configured to meet PCI DSS requirements through the PA DSS functionality provided by Oracle Payments.  From the release notes for the Oracle Payment Application Data Security Standard (PA DSS) Consolidated Patch Release 12.1.2 (Doc ID 981033.1), the following list of products now use the Secure Payment Repository –

Oracle Modules using the Secure Payment Repository

  • Oracle Advanced Collections
  • Oracle iExpenses
  • Oracle iReceivables
  • Oracle iStore
  • Oracle Order Capture
  • Oracle Order Management
  • Oracle Partner Management
  • Oracle Payables
  • Oracle Payments
  • Oracle Quoting
  • Oracle Service Contracts
Secure Payment Repository

With Release 12, the Trading Community Architecture (TCA) defines party information (e.g. suppliers and customers) and the Secure Payment Data repository stores the payment instruments (credit card and bank accounts) for the parties.  It is through this consolidation of payment instruments into the Secure Payment Repository that Oracle Payments offers its new functionality for the encryption and masking of payment instruments to meet the PA DSS requirements.

The key point to note is that only those products identified above make use of the Secure Payment Repository. More importantly, the PA DSS functionality provided by the Secure Payment Repository is NOT enabled by default.  The steps to enable it will be reviewed in the next blog posting

For further information on PCI compliance, Corporate Cards and the E-Business Suite please refer to our whitepaper in the link below.

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

 -Michael Miller, CISSP-ISSMP

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

Oracle E-Business Suite, PCI Compliance and External vs Internal Accounts

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.

Oracle defines “external accounts” as those accounts belonging to customers, suppliers, vendors, students, and external third parties.  These are the credit cards and bank account numbers customers and vendors use to conduct business with a company.  Oracle defines “internal accounts” as those accounts a company uses internally such as bank accounts defined within Accounts Payable or employee bank accounts defined within Oracle HR/Payroll for direct deposit. 

While it is highly recommended by Integrigy Corporation to appropriately protect the security of both external as well as internal accounts, PCI compliance requirements apply to only external accounts. 

For further information on PCI compliance and the E-Business Suite please refer to our whitepaper in the link below.

In the next blog posting we will review the Oracle E-Business Suite’s Secure Payments Repository and how it is used to help meet PCI compliance.

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

 -Michael Miller, CISSP

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

Oracle E-Business Suite, Corporate Cards and PCI DSS

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. external accounts is discussed in the whitepaper referenced below.  The Oracle E-Business Suite’s functionality for protecting external accounts does, however, includes protection for Corporate Cards.  When the functionality is enabled to protect external accounts, Corporate Cards are also protected.

While it is highly recommended by both Integrigy Corporation and the PCI Council to appropriately protect Corporate Cards, specific guidance and requirements for the protection of corporate cards should be sought from legal counsel and compliance teams as well as the issuer of the Corporate Card.

For further information on PCI compliance, Corporate Cards and the E-Business Suite please refer to our whitepaper in the link below.

In the next blog posting we will review the Oracle E-Business Suite’s definition of internal vs. external accounts.

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

 -Michael Miller, CISSP-ISSMP

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

Oracle E-Business Suite PCI Compliance

The next few blog postings will focus on PCI and the Oracle E-Business Suite. All Oracle E-Business Suite implementations that "store, process, or transmit cardholder data" must comply with Payment Card Industry (PCI) Data Security Standard regardless of size or transaction volume.  The PCI Data Security Standard (DSS) is a set of stringent security requirements for networks, network devices, servers, and applications.  PCI DSS details specific requirements in terms of security configuration and policies and all the requirements are mandatory.  PCI DSS is focused on securely handling credit card data, but also has a significant emphasis on General IT security controls.

To meet PCI DSS requirements for an environment, even though credit card processing may be only one minor feature of the application, the entire application installation and the entire environment must be fully PCI DSS compliant.  In a large global implementation that may include financials, manufacturing, projects, sales/CRM or human resources, PCI compliance can be a daunting endeavor and will impact operations and management of the non-card processing modules as well as the underlying supporting environment.

Basic Guidelines for PCI DSS
  • Do not store sensitive authentication data
  • Do not store cardholder data unless it’s absolutely necessary
  • Use strong cryptography to render unreadable cardholder data that you do store
  • Do not permit any unauthorized people to access stored cardholder data
  • Understand the data flow for the entire transaction process
How do you know if PCI is enabled?

The Oracle E-Business Suite’s standard functionality to help meet PCI compliance is disabled by default. The functionality must be manually enabled. The following is a quick check to confirm if one of the basic E-Business Suite configurations is set for the encryption of credit cards. If the select statement below returns a value of ‘None’ then PCI is not enabled. If you see ‘SCHEDULED’ OR ‘IMMEDIATE’ then PCI, or parts of it, may be enabled. For further information please refer to our whitepaper in the link below.

select cc_encryption_mode
from iby.iby_sys_security_options

In the next blog posting we will review a common question with regard to Corporate Cards, PCI compliance and the E-Business Suite.

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

 -Michael Miller, CISSP-ISSMP

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

Oracle E-Business Suite PCI DSS Credit Card Encryption

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. 

Partial encryption refers only to the encryption of the PAN. Full encryption refers to the encryption of the Primary Account Number (PAN) along with the cardholder name and card expiration date. The cardholder name and expiration date are also referred to in the documentation as supplemental data.

Immediate encryption encrypts cardholder data as it is being written to the database. Scheduled encryption leaves cardholder data unencrypted until a concurrent request is run manually or scheduled at a later point in time to encrypt cardholder data. Integrigy Corporation strongly recommends only using immediate encryption.

Specifically, to meet requirement 3.4, Oracle Payments uses a chained encryption key approach and a Triple Data Encryption Algorithm (TDEA, Triple DEA, TDES or 3DES) symmetric-key block cipher.  A master encryption system key is used to encrypt sub-keys.  This master key is stored in the Oracle Payment Wallet (cwallet.sso).

The sub-keys are 156-bit-length system generated and are encrypted using 3DES and the master key as the key. The encrypted sub-keys are then stored in the table IBY.IBY_SYS_SECURITY_SUBKEYS.

Cardholder data collected by the Secure Payments Repository is stored in the table IBY.IBY_CREDITCARD. When encryption is enabled, the records in IBY.IBY_CREDITCARD are flagged as being encrypted and the specific PCI cardholder data is moved to the table IBY.IBY_SECURITY_SEGMENTS. 

Cardholder data in IBY.IBY_SECURITY_SEGMENTS is encrypted using the 156-bit sub-keys and a 3DES algorithm. The standard Oracle package DBMS_OBFUSCATION_TOOLKIT performs the encryption. The 156-bit key exceeds the PCI DSS required minimum of double-length keys for 3DES. It is also interesting to note that the Oracle E-Business Suite is using the depreciated DBMS_OBFUSCATION_TOOLKIT package rather than the newer DBMS_CRTYPO package.

Remember to Rotate Wallet Keys Annually

PCI requirement 3.6 requires that encryption keys be rotated on a regular basis – at a minimum of annually. This means that the Oracle Payment Wallet keys needs to be rotated. Changing the password for the wallet does not change the key. The process of rotating the wallet key for Oracle Payments requires that an entire new wallet be created, and the old wallet destroyed (both the *.p12 and the *.sso files) through a secure wipe – not just deleted from the file system. 

Further Information

For further information on PCI compliance, Corporate Cards and the E-Business Suite please refer to our whitepaper in the link below.

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

- Michael Miller, CISSP-ISSMP

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

Risk of Information Leakage from the Oracle E-Business Suite - Validation Levels

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.

Profile Option

Default Value

Recommended Value

FND: Validation Level

Error as of R12

Error

(R12.2 does not allow to be changed)

FND: Function Validation Level

Error as of 11.5.10 CU 10

Error

(R12.2 does not allow to be changed)

Framework Validation Level

Error as of 11.5.10 CU 10

Error

(R12.2 does not allow to be changed)

Restricted Text Input

Yes

Yes

FND: Fixed Key Enabled

Null

Yes

FND: Fixed Key

None

Yes, only at User level

References
  • Secure Configuration of Oracle E-Business Suite Profiles (MOS Doc ID 946372.1)
  • Oracle Application Framework Profile Options (MOS Doc ID 1107970.1)
Tags: Oracle E-Business Suite
Categories: APPS Blogs, Security Blogs

Risk of Information Leakage from the Oracle E-Business Suite – Attached Files

Attached files are an information leakage risk for the Oracle E-Business Suite. There are two sources, and the second is not commonly recognized.

The first source is straight forward. Users of the E-Business Suite are free to upload and attach files with content at their discretion. There is nothing to prevent users from attaching files with confidential information such as credit card and/or social security numbers other than business policies supported by security awareness training. Because of this, the risk of information leakage with attached files is best mitigated by purging attached files on a regular basis.

The second source is less obvious and stems from the fact that, besides attachments, the Oracle E-Business Suite also retains file exports in the same table with attachments. There is a risk of information leakage with these file exports. For example, if your Human Resources department regularly exports to Excel from Forms, it is likely you will have a large number of export files. Due to the nature of Human Resources data, this probably means that you have sensitive information stored in these files.

By design the Oracle E-Business Suite needs to purge attached files. It is through the purge process for attached files that file-exports files are removed. However, many organizations do not regularly purge attachments. Integrigy’s security assessment services can assist with scanning your attached files for sensitive data.

If you have any questions about this or Oracle E-Business Security, please contact us at info@integrigy.com

 -Michael Miller, CISSP-ISSMP

References
  • Questions on Purge Obsolete Generic File Manager Data (MOS Doc ID 1165208.1)
  • Purging Strategy for eBusiness Suite 11i (MOS Doc ID 732713.1)
Tags: Sensitive DataOracle E-Business Suite
Categories: APPS Blogs, Security Blogs

Risk of Information Leakage from the Oracle E-Business Suite - Diagnostics

It is rare to find customers who are not using Diagnostics to support their Oracle E-Business Suite. However, Diagnostics is commonly overlooked as a source of information leakage. By design, Diagnostics should not be enabled in production, or if it is, it should be enabled only at the user level and for a limited period of time. If your non-production instances have DMZ nodes, then the same advice applies.

Setting the profile option ‘FND: Diagnostics’ from its default of ‘No’ to ‘Yes’ causes a Diagnostics global button to be rendered on every page. As well, enabling this profile option renders the ‘About This Page’ link at the bottom of every OA Framework page. With Diagnostics enabled, and access to About This Page, configuration data, diagnostic, and other log messages is displayed to anyone who clicks on the button or link. This information should only be displayed to appropriately privileged and trusted personnel. Making diagnostics globally available to all users, including external DMZ users such as for iStore and iRecruitment, is not a best practice.

What is not commonly understood is that the Diagnostics profile option setting changes the behavior of several purpose-built diagnostic and monitoring pages shipped with the E-Business Suite. These pages provide large amounts of information on critical configurations and system performance and are intended only to be used by system and database administrators. While arguably these monitoring and diagnostics pages should be protected by the Oracle EBS URL Firewall (if enabled and properly configured), and may be obscure, they may be known to somebody attempting to attack you from the outside or an insider with nefarious purposes. These pages should not be accessible by general users and certainly not by anonymous Internet users. Turning Diagnostics off greatly reduces, if not completely disables, access to these diagnostics pages. This is another reason that best practice is to set Diagnostics off and only enable at the user level as needed.

How do you know if Diagnostics is enabled?
  • Check your system profile option ‘FND: Diagnostics’. It should be set to ‘No’ at the Site level.

If you have questions, please contact us.

References
Categories: APPS Blogs, Security Blogs

Risk of Information Leakage from the Oracle E-Business Suite

The Oracle E-Business Suite provides a large number of diagnostic and monitoring solutions. While these solutions offer comprehensive and in-depth information about your implementation, they can also be the source of serious information leakages. Especially if you have Internet facing applications such iStore, iSupplier or iRecruitment, you need to take steps to secure your implementation against accidental information leakage and provide as little information as possible to anyone who might want to attack you.

URL Firewall

If you are running the E-Business Suite with a DMZ, such as for iStore or iSupplier, you must use the URL firewall. If you don’t, you will be exposing your implementation to serious security risks and leaking large amounts of information.

The Oracle E-Business Suite automatically installs all 250+ modules and all related web pages.  Even though many of these modules are not selected to be installed, licensed, or configured, the web pages are nevertheless installed and accessible.  In order to block these 15,000+ web pages when deploying Oracle E-Business Suite in a DMZ, Oracle developed the URL firewall.  The URL firewall is a whitelist of permitted web pages and is enabled through autoconfig.

How to know if your URL Firewall is running
  • Review your autoconfig settings for the variable: s_enable_urlfirewall. If you see a ‘#’, the URL firewall is off. Integrigy also recommends reviewing the Apache httpd.conf files on each server in your DMZ to ensure that the url firewall is being called.

Integrigy's AppDefend, our Web Application Firewall optimized for Oracle E-Business Suite, provides another layer of security to block unused modules like the URL Firewall, but also provides real-time protection from web application vulnerabilities like SQL injection and cross-site scripting (XSS) and blocks Oracle Critical Patch Update vulnerabilities.

If you have questions, please contact us.

References

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

11.5.10 Sustaining Support - Security Patches Through October 2015

As of December 1, 2013, Oracle E-Business Suite 11.5.10 moved into Sustaining Support.  Normally, Oracle Sustaining Support does not include security fixes in the form of Critical Patch Updates.  However, for 11.5.10, there is an exception until December 2015 and Severity 1 fixes, payroll/1099 updates, and Critical Patch Updates will be available.

Oracle E-Business Suite Critical Patch Updates (CPU) will be available for 11.5.10 up to and including the October 2015 CPU.  No Oracle E-Business Suite CPUs or security fixes will be released after the October 2015 CPU.  In order to continue applying security patches after October 2015, you will need to upgrade to at least Oracle E-Business Suite 12.1.  CPU support for 12.0 will end January 2015 with the end of Extended Support.

CPUs for the Oracle E-Business Suite database will be dependent on the version being used and currently CPUs are only available for 11.1.0.7, 11.2.0.3, 11.2.0.4, and 12.1.0.1.  For the application server, which is very old and is basically on life support, was last patched in the October 2012 CPU.

Tags: Oracle E-Business SuiteOracle Critical Patch Updates
Categories: APPS Blogs, Security Blogs