The recent OAUG "Automating Compliance Survey" (OAUG login required) showed 7% of the organizations surveyed responded as being compliant with the Payment Card Industry (PCI) Data Security Standard (DSS), while 19% were in the process of planning or implementing and 71% were either not planning or not sure about PCI compliance.  Having 71% of the organizations respond "not planning/not sure" seems a little high to me since all Oracle Applications implementations that "store, process, or transmit credit card data" must comply with Payment Card Industry (PCI) Data Security Standard 1.1 regardless of size or transaction volume.  This means 71% of the respondents either don't handle any credit cards in their Oracle Applications environments or there were a lot of "not sure" responses.

Let me step back first and provide a brief background of PCI compliance.  The PCI Data Security Standard (DSS) 1.1 is a set of stringent security requirements for networks, network devices, servers, and applications.  The standard 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.  Even if you are not required to have annual on-site audits, perform quarterly scans, complete annual self-assessment questionnaires, or submit compliance documentation, "nevertheless must comply with, and are subject to liability under, all other provisions of" the then-current Payment Card Industry Data Security Standard.

The difficultly with Oracle Applications and achieving PCI compliance is that even though credit card processing may be only a one minor feature of the application, the entire application installation must be fully PCI DSS compliant due to the tight-integration and data model of Oracle Applications.  One of the key requirements is that all credit card numbers are encrypted in the database and only recently has Oracle included such functionality in Oracle Applications.

For those organizations that have completed SOX audits and remediation, the level of difficulty associated with PCI compliance is in the eye-of-the-beholder.  For those IT managers and DBAs who struggled with broadness and poor definition around SOX requirements will welcome PCI as it is a well-defined and documented standard.  On the other hand, it provides for few exceptions related to compensating controls.

To help Oracle Applications implementations sort through PCI compliance issues, we have compiled from some recent work general guidance for each PCI requirement related to the installation and configuration of Oracle Applications.  This whitepaper also provides details on the Oracle Applications Credit Card Encryption Patch (see Metalink Note ID 338756.1).

Whitepaper: Oracle Applications 11i: Credit Cards and PCI Compliance Issues

Oracle has certified Oracle 10g (10.2.0.2) Transparent Data Encryption (TDE) with Oracle Applications 11i -- TDE is part of the Oracle Advanced Security Option (ASO), which is a database option and is an additional cost.

TDE allows you to selectively encrypt a column when stored on disk.  All database users with permissions on the table and column will see the unencrypted value, but the data is encrypted in the data file, redo log, archive logs, and backups.  The encryption key is stored in the Oracle Wallet in the file system, which must not be included in any backups.  If a backup tape, data file, or storage media is stolen or lost, the data can not be accessed without the encryption key stored in the Oracle Wallet.

Oracle Metalink Note ID 403294.1 has instructions for the requirements, limitations, and configuration of TDE with 11i.  Oracle RDBMS 10.2.0.2 is required, thus TDE can only be used with 11.5.9 and up.  Patch 5693160 provides a nice FND SQL script that analyzes if an Oracle Applications column may be encrypted.

TDE impacts performance in two ways: (1) there is overhead associated with the encryption and decryption and (2) the encrypted column can not be indexed, thus some SQL statements after the change may result in a full table scan.  Organizations most likely will want to use TDE for national identifiers (i.e., social security numbers, driver license numbers), credit card numbers, and bank account numbers.  A number of these columns are indexed, therefore, application performance needs to be thoroughly tested prior to implementing TDE in a production environment.

Reference:

Oracle Metalink ID 403294.1 "Using Transparent Data Encryption (TDE) with the eBusiness Suite (EBS)"

Oracle has released the January 2007 Critical Patch Update (CPU).  A major change for this quarter's CPU was the release of a pre-announcement on January 11th giving an overview of the products patches and a summary of the vulnerabilities.  On the surface, the pre-announcement looked pretty bad with the highest CVSS base score being 7.0 for the database, Enterprise Manager, and E-Business Suite.  However, the worst database vulnerabilities are exclusively in the Oracle HTTP Server, which is an optional component for the database.

Generally, the CPU is very similar to previous quarters in terms of the types of vulnerabilities and scope.  The most disconcerting issue is that the same packages keep appearing in the CPUs - sys.dbms_capture_adm_internal (January 2006) and sys.dbms_cdc_subscribe (April 2005).

The worst vulnerabilities are in the Oracle HTTP Server SSL Module (OpenSSL) with OpenSSL versions prior to 0.9.7l and 0.9.8d being vulnerable.  SSL must be configured for the Oracle HTTP Server in order to exploit these bugs.  Only the 9i versions (9.0 and 9.2) of the Oracle Database HTTP Server and Oracle E-Business Suite Oracle Application Server (1.0.2.2) are vulnerable, not any supported versions of the Oracle Application Server.  If you are running a desupported version of the Oracle Application Server, you most likely are vulnerable to these OpenSSL bugs.

Here are some further observations -

• The 9.2.0.8 database patch is really the October 2006 CPU patch, which was released late on December 29, 2006.  I am assuming Oracle just rolled-up any January 2007 fixes in the October 2006 patch, although it could be a mistake in the advisory.
  
• For 10.2.0.3, the installation note says the patch for 10.2.0.3 is "not applicable", but the advisory says the assessment of vulnerabilities in 10.2.0.3 is not complete and patches are forthcoming.  When performing your risk and impact assessment, be sure to include 10.2.0.3 as needing to be patched.
  
• Again this quarter, a number of CPU patches are delayed including the following -

1. Database patches 9.2.0.5 (Unix/Linux), 9.2.0.6, 10.1.0.3 (Unix/Linux), and 10.2.0.3.  With the October 2006 CPU, some of these short delays did become almost 75 days.
2. Oracle Application Server 9.0.4.1 (Unix/Linux)
   
3. Oracle Identity Management 10.1.4
4. Oracle Enterprise Manager 10.2.0.1

Overall, I think Oracle is beginning to get a little sloppy with the Critical Patch Update process as there seems to be many more missing patches and minor errors in the advisory and notes (incorrect titles, etc.).  The whole process from an internal Oracle perspective is very complex with the number of products and platforms involved, but after 2 years of CPUs Oracle should have the internal handling of CPUs in a little better shape.

For those of you who are OAUG members, I will be presenting an OAUG eLearning session on the Oracle Critical Patch Update January 2007 and the impact on the E-Business Suite.  This session will include a review of the security vulnerabilities fixed in the CPU, an analysis of the required CPU patches, and a discussion of a high-level patch strategy.  Depending the vulnerabilities fixed in the CPU, there may even be some demonstrations of the actual vulnerabilities.

There will be two sessions on Thursday, January 18th at 9:00am and 5:00pm EST.  Space is limited to 25 participants and you must register on-line for the session.  If your organization is not a member of OAUG, I recommend you join as it is a very effective and beneficial user organization.

The registration URL is -

http://secure.meetingexpectations.com/oaug/eLearning/elSchedule.aspx?DayOfWeek=THU



 

Here is a quick analysis of the pre-release announcement for the January 2007 Critical Patch Update (CPU) -

• Overall, 52 vulnerabilities are fixed in this CPU, which is inline with previous CPUs (Oct-06=101, Jul-06=63, Apr-06=36, Jan-06=82).
• The product mix is similar to previous CPUs with the notable addition of Oracle Identity Management 10.1.4.0.1.  All supported Oracle Database, Oracle Application Server, and Oracle E-Business Suite versions are included.
• A number of the vulnerabilities have a CVSS metric of 7.0, which for database and application vulnerabilities is severe.  7.0 is really the practical maximum for a database or application vulnerability. 
  
1. For the Oracle Database, there are one or more easy to exploit, remotely exploitable, and authentication not required vulnerabilities, which are not typical of previous database vulnerabilities.  Most previous database vulnerabilities require database authentication to exploit.
2. For the Oracle E-Business Suite, there are one or more easy to exploit, remotely exploitable, and authentication not required vulnerabilities.  It appears the most severe vulnerabilities are in Oracle Application Server 1.0.2.2, so Internet accessible Oracle Applications implementations should look to prioritize these patches.
   

Oracle is now going to publish a "Pre-Release Announcement" for each Critical Patch Update starting with the CPU to be released next week.  The Pre-Release Announcement contains the executive summaries, list of affected products, and the highest CVSS score for each product.  The January 2007 CPU Pre-Release Announcement is available here.

In the short-term, I don't think it will have much of an impact on your planning as there is such a back-log of open security bugs, all the CPUs to-date and in the foreseeable future are very similar in scope and severity.  There are a few instances where the pre-announcement will be helpful to a customer -

• Oracle Application Server implementations that are connected to the Internet  - customers should be prioritizing these servers for patching.
  
• Internet Accessible Oracle Applications modules (iStore, iSupplier, etc) - again these implementations should be prioritize and downtime scheduled to apply these patches based on the CPU announcement.
• Applications that are not routinely in a CPU (PeopleSoft, Siebel, JD Edwards, Oracle Collaboration Suite, Oracle Pharmaceutical, Oracle Retail, etc.) - at least you will know to look or not look at the CPU.

If and when the number of fixed security bugs reaches a more manageable number, then the announcement will be more useful and provide an indicator of what to expect in the CPU.

Customers should push Oracle to have the pre-announcement released earlier than 5 days before the CPU.  I would suggest at least the Monday or Tuesday prior to allow for the necessary approvals and notification for downtime the weekend following the CPU release or the end of the month.

Due to the number of client inquiries regarding my recent posting on the Oracle Applications 11i password decryption issue, we have written a whitepaper on the subject to provide more details and additional recommendations.  This issue is really a "perfect storm" with the convergence of (1) an inherent architectural weakness in the application, (2) generally accepted insecure operational policies and procedures for ad-hoc query access and cloning, and (3) multiple examples of effective, easy to execute exploit code for decrypting application passwords.

For those of you not familiar with the issue, the fundamental problem is that the Oracle Applications 11i application account passwords are stored in the database encrypted using the APPS database password as the encryption key rather than using a strong, one-way hash algorithm. In order to provide access to the APPS database password upon login and for other processes, it is stored encrypted in the database for each application account using the account username and password as the encryption key. In a well-controlled and secured Oracle Applications environment, this issue is difficult to exploit. However, most implementations allow some form of ad-hoc query access and have numerous cloned databases. Using published exploit code, an insider via ad-hoc query access or in a cloned database is able to decrypt easily both application account passwords and the APPS database account password. In our experience performing security assessments of Oracle Applications environments, virtually all Oracle Applications 11i implementations are vulnerable to this issue to some degree. The question is most often not if a production database is vulnerable rather can 10 or 500 people exploit it, can only trusted employees exploit it or every off-shore developer.

Whitepaper: Oracle Applications 11i Password Decryption

If you haven't noticed due to the holidays, Oracle has finally released the October 2006 Critical Patch Update (CPU) for 9.2.0.8 on Unix/Linux and Windows.  These patches were released 75 days after the CPU and at least 45 days after the initial projected date.

The 9.2.0.8 Database patch should be applied for all Oracle E-Business Suite databases running 9.2.0.8, even though the patch is not listed in the CPU documentation for the E-Business Suite.