Upcoming Webinar: The Manager's Guide to Securing the Oracle E-Business Suite

The Manager's Guide to Securing the Oracle E-Business Suite
Wednesday, June 20, 2:00pm - 3:00pm EDT

For those of you that missed this session at the recent Collaborate12 conference, please read on.

The Oracle E-Business Suite is usually an organization’s most important application and the consequences of having it compromised could be catastrophic. However, often CIOs, project managers, and technical managers have little understanding of Oracle E-Business Suite security and compliance risks and issues. This session will provide a managerial level overview of how to properly secure the application and comply with requirements such as SOX, PCI, and HIPAA, including key questions to ask DBAs and IT Security.

Click here to register for this Oracle Database Security webinar.

Upcoming Webinar: Credit Cards and Oracle E-Business Suite - Security and PCI Compliance Issues

Credit Cards and Oracle E-Business Suite - Security and PCI Compliance Issues
Thursday, August 16, 2:00pm - 3:00pm EDT

Credit card data breaches are headline news, thus organizations must properly protect credit card data or risk being tomorrow's headline. Oracle E-Business Suite implementations that "store, process, or transmit cardholder data" must comply with Payment Card Industry (PCI) security standards regardless of size or transaction volume. PCI is focused on securely handling cardholder data, but also has a significant emphasis on general IT security. The difficultly with the Oracle E-Business Suite and achieving PCI compliance is that even though credit card processing may be only a one minor feature, the entire application installation must be fully PCI compliant due to the tight-integration and data model of the Oracle E-Business Suite. This presentation will review the credit card processing within the Oracle E-Business Suite and will provide general guidance for the Oracle E-Business Suite implementations on securing cardholder data and complying with relevant PCI requirements.

Click here to register for this Oracle E-Business Suite educational webinar.

As part of a default Apache installation, two default cgi-bin scripts, printenv and test-cgi, are installed. Oracle has included these scripts in the installation of 11i. This script provides information regarding the installation, which could be used in an attack.

Oracle E-Business Suite self-service applications are often connected to the Internet for direct access by customers, suppliers, and employees. Using search engines (Google, Altavista, etc.) and simple search phrases, hackers can quickly find instances of the Oracle E-Business Suite to attack. All Internet accessible instances of the Oracle E-Business Suite should be shielded from web crawlers and indexing services.

The Oracle Reports Server may disclose the current APPS password. Oracle Reports Server is installed as part of the default installation and is used by Oracle Business Intelligence (BIS) and related business intelligence modules (Financial Intelligence, etc.).

The Oracle Applications FNDFS program, used to retrieve report output from the Concurrent Manager server, can be used to remotely retrieve any file from the server without operating system or application authentication. A mandatory patch from Oracle is required to solve this security issue.

Integrigy Security Alert
______________________________________________________________________

Oracle E-Business Suite AOL/J Setup Test Information Disclosure

July 23, 2003

______________________________________________________________________

Summary:

The Oracle Applications AOL/J Setup Test Suite, used to trouble-shoot the Self-Service framework, can be exploited to remotely retrieve sensitive configuration and host information without application authentication.  The AOL/J Setup Test Suite is installed by default for all 11i implementations.  A mandatory patch from Oracle is required to solve this security issue.

Product:    Oracle E-Business Suite

Versions:   11.5.1 – 11.5.8

Platforms:  All platforms

Risk Level: Low

_____________________________________________________________________

Description:

The Oracle Applications Self-Service Framework (OA Framework) is the foundation for self-service HRMS, iProcurement, iExpenses, and other web applications.  The OA Framework includes a Test Suite used to verify its installation and configuration.  The AOL/J Setup Test Suite is implemented as Java Server Pages (JSP) and the main JSP page is "aoljtest.jsp".  The AOL/J Setup Test Suite is installed for all 11i web and forms servers in the $COMMON_TOP/html/jsp/fnd directory. 

Multiple vulnerabilities exist in the AOL/J Setup Test Suite allowing an attacker to obtain valuable information on the configuration of Oracle Applications without any database or application authentication.  This information includes the GUEST user password and application server security key.

Solution:

Oracle has released a patch for the Oracle E-Business Suite 11i to correct this vulnerability.  Oracle has corrected multiple vulnerabilities in the AOL/J Setup Test Suite JSPs.

The following Oracle patch must be applied --

      Version     Patch

      -------     -----

      11i         2939083     (11.5.1 – 11.5.8)

Oracle Applications customers should consider this vulnerability low risk and apply the above patch during the next normal maintenance cycle.  Customers with Internet facing application servers should apply the patch immediately or consider removing or restricting access to the AOL/J Setup Test Suite.  In addition, the GUEST user account should be checked to ensure that it has only publicly accessible responsibilities assigned to it.

Appropriate testing and backups should be performed before applying any patches.

Additional Information:

  http://www.integrigy.com/resources.htm

  http://otn.oracle.com/deploy/security/pdf/2003alert55.pdf

For more information or questions regarding this security alert, please contact us at alerts@integrigy.com.

Credit:

This vulnerability was discovered by Stephen Kost of Integrigy Corporation.

______________________________________________________________________

About Integrigy Corporation (www.integrigy.com)

Integrigy Corporation is a leader in application security for large enterprise, mission critical applications. Our application vulnerability assessment tool, AppSentry, assists companies in securing their largest and most important applications. Integrigy Consulting offers security assessment services for leading ERP and CRM applications.

For more information, visit www.integrigy.com.

The Oracle Applications FNDWRR CGI program, used to retrieve report output from the Concurrent Manager server via a web browser, has a remotely exploitable buffer overflow. A mandatory patch from Oracle is required to solve this security issue.

Multiple SQL injection vulnerabilities exist in the Oracle E-Business Suite 11i and Oracle Applications 11.0. These vulnerabilities can be remotely exploited simply using a browser and sending a specially crafted URL to the web server. A mandatory patch from Oracle is required to solve these security issues.

An undisclosed security vulnerability exists in Oracle Applications 11i that may allow an unauthenticated, internal attacker to obtain Oracle Applications' user account encrypted password strings, which in turn can be decrypted using previously published information. An attacker can potentially obtain either any user's password or the Oracle Applications' main database account password (APPS). The attacker must have direct SQL*Net access to the database (e.g., SQL*Plus) and to exploit the vulnerability neither of the Oracle Applications security features "Managed SQL*Net Access" and "Server Security" can be enabled. The underlying issue is that Oracle Applications passwords can be easily decrypted using methods previously published. All Oracle Applications implementations should enable at least "Server Security" and preferably also enable "Managed SQL*Net Access".

Attachment	Size
Integrigy_Encrypted_Password_Disclosure.pdf	130.89 KB

Oracle today released its fourth Critical Patch Update (October 2005). The patches contained in the Critical Patch Update will correct numerous security bugs in the Oracle Database, Oracle Application Server, and Oracle E-Business Suite. Some of the vulnerabilities in the Critical Patch Update are high risk and a few can be exploited remotely using a web browser. Almost all the security bugs fixed in this Critical Patch Update are exploitable in Oracle E-Business Suite environments and the appropriate patches should be applied as soon as possible. Patches for the Oracle Database, Oracle Application Server, Oracle Developer 6i, and Oracle E-Business Suite 11i must be applied -- almost all implementations will have to apply at least 12 patches. Customers with Internet-facing implementations of the Oracle E-Business Suite are at most risk and should consider applying these patches quickly.

Here is a brief analysis of the pre-release announcement for the upcoming April 2011 Oracle Critical Patch Update (CPU) -

• Overall, 47 Oracle security vulnerabilities (non-Solaris bugs) are fixed in this CPU, which is an average number and well within the range of previous CPUs (Jan-11=43, Oct-10=50, Jul-10=38, Apr-10=31, Jan-10=24, Oct-09=38, Jul-09=30, Apr-09=43, Jan-09=41, Oct-08=36, Jul-08=45, Apr-08=41, Jan-08=26, Oct-07=51, Jul-07=45, Apr-07=36, Jan-07=51, Oct-06=101, Jul-06=62, Apr-06=34, Jan-06=80).  These numbers have been normalized for Oracle products and excludes any Sun products.
• The Oracle product and vulnerability mix appears to be similar to previous CPUs.  All CPU supported Oracle Database and Oracle E-Business Suite versions are included.  The list of supported versions is getting very short and should be carefully reviewed to determine if version upgrades are required prior to applying the CPU security patches -
  • • • Database = 10.1.0.5, 10.2.0.4, 10.2.0.5, 11.1.0.7, 11.2.0.1, 11.2.0.2 for major platforms
      • Application Server = 10.1.2.3.0, 10.1.3.5.0, 11.1.1.2.0, 11.1.1.3.0, and 11.1.1.4.0
      • E-Business Suite = 11.5.10.2, 12.0.6, 12.1.1, 12.1.2, and 12.1.3
• As anticipated by Integrigy, this is the first CPU available for Oracle Database 11.2.0.2.
• For the Oracle E-Business, as of the April 2011 there is no CPU support for all versions prior to 11.5.10.2 and 12.0.0 - 12.0.5.  11.5.10.2 requires the "Minimum Baseline for Extended Support" as specified in Metalink Note ID 883202.1.
• The highlight of this CPU is 6 of 9 Oracle Application Server/Fusion Middleware security vulnerabilities are remotely exploitable without authentication with the highest CVSSv2 score being 10.0.  The vulnerabilities are in Oracle Help, Oracle HTTP Server, Oracle JRockit, Oracle Outside In Technology, Oracle Security Service, Oracle WebLogic Server, Portal, and Single Sign On components.
• Integrigy will be presenting more information on this CPU in the following webinars: (1) Oracle April 2011 CPU E-Business Suite Impact Webinar Thursday, April 28, 2pm ET and (2) Oracle April 2011 CPU Oracle Database Impact Webinar Thursday, May 5, 2pm ET.

Oracle Database

• There are 6 database vulnerabilities and 2 are remotely exploitable without authentication.
• Since at least one database vulnerability has a CVSS 2.0 metric of 6.5 (important to high for a database vulnerability), this is a fairly important CPU.
• The components fixed by this CPU are not the usual suspects and several will not be implemented in many environments.  It will be interesting to see what the actual vulnerabilities are in these components: Application Service Level Management, Database Vault, Network Foundation, Oracle Help, Oracle Security Service, Oracle Warehouse Builder, and UIX.  If the Network Foundation bug is a denial of service and most of the other components are not implemented in an environment, this could be one of the first CPUs to be classified as low risk for some Oracle databases.

Oracle Fusion Middleware

• There are 9 new Oracle Fusion Middleware vulnerabilities, 6 of which are remotely exploitable without authentication with the highest CVSS score being 10.0.
• Of critical importance will be the fixes in the Oracle HTTP Server and Oracle Web Logic Server.  All Oracle Fusion Middleware implementations should carefully review this CPU to determine the exact impact to your environment.

Oracle E-Business Suite 11i and R12

• There are 4 new Oracle E-Business Suite 11i and R12 vulnerabilities, two of which are remotely exploitable without authentication.
• The vulnerabilities are Oracle Application Object Library (AOL), Applications Install, and Web ADI.  It is not clear if the AOL vulnerabilities can be exploited externally in DMZ implementations.

Planning Impact

• We anticipate the criticality of this quarter's CPU will be in-line with previous CPUs.  The only exception may the significant number of Oracle Fusion Middleware remotely exploitable vulnerabilities, especially any in the Oracle HTTP Server.  For specific databases based on configuration and installed options, this may be a lower than average risk CPU.
• As with all previous CPUs, this quarter's security patches should be deemed critical and you should adhere to the established procedures and timing used for previous CPUs.
• Oracle E-Business Suite customers with externally facing implementations should carefully review the remotely exploitable vulnerabilities in Application Object Library to determine if these pages are blocked by the URL firewall.  If any of the vulnerable web pages are externally accessible, customers should look to immediately patch these environments.

Upcoming Integrigy CPU Webinars

Oracle April 2011 CPU E-Business Suite Impact
Thursday, April 28, 2pm ET

Oracle April 2011 CPU Oracle Database Impact
Thursday, May 5, 2pm ET

Improve Security in Your Oracle R12 Upgrade
Thursday, May 12, 2010 2:00 PM - 3:00 PM EDT

The upgrade from Oracle E-Business Suite (EBS) 11i to R12 is a unique opportunity to improve the security of your implementation by resolving existing security issues, configuring R12 securely, and taking advantage of new security features in R12.  This one hour education session will highlight R12 security changes and discuss a framework for a security focused R12 upgrade project.

Topics will include:

• 11i and R12 differences and changes that impact security
• R12 security enhancements and new features
• Improving security throughout the R12 upgrade process

Click here to register for this webinar.

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 info@integrigy.com.

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: http://theobieeserver.yourcompany.com:9704
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 info@integrigy.com

 -Michael Miller, CISSP-ISSMP

References

• OBIEE Security Examined - Webinar and Presentation:  OBIEE Security Examined Webinar
• OBIEE Security Examined - Whitepaper: OBIEE Security Examined

In an Oracle E-Business Suite environment, there are a number of generic, privileged accounts at the database, application, and operating system layers.  Often, there is little control or active management of accounts like APPS and SYSADMIN with passwords being loosely controlled and frequently shared.  This webinar describes the risks associated with these accounts and ways to manage and control them.

Attachment	Size
Integrigy Securing Oracle EBS Privileged Accounts APPS SYSADMIN oracle.pdf	644.88 KB

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.

FAQ

• 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 info@integrigy.com

References

• Enhanced JAR Signing for Oracle E-Business Suite, 19-March-2014, Doc ID 1591073.1 https://support.oracle.com/rs?type=doc&id=1591073.1
• Oracle Tutorial on Java JAR signing: http://docs.oracle.com/javase/tutorial/deployment/jar/intro.html

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 info@integrigy.com

References

• Preventing a Hacker from Creating Bogus Users and Uploading the Maximum Files in iRecruitment (Doc ID 402662.1)  https://support.oracle.com/rs?type=doc&id=402662.1
• What is CAPTCHA http://en.wikipedia.org/wiki/CAPTCHA

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:

• APPLSYS.FND_SIGNON
• APPLSYS.FND_LOGIN_RESPONSIBILITIES
• APPLSYS.FND_LOGIN_RESP_FORMS
• APPLSYS.FND_UNSUCCESSFUL_LOGINS

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:

SELECT  U.USER_NAME,U.PERSON_PARTY_ID, LI.*

from APPLSYS.FND_LOGINS LI, APPLSYS.FND_USER U

WHERE LI.TERMINAL_ID IS NULL

AND LI.USER_ID = U.USER_ID

{{AND $rising_column$ > ?}}

4. Identify the rising column, enter: LOGIN_ID
5. Identify the index, as a quick demo to get going just use the default, enter: default
6. Identify a Host Field value, you can enter the database SID, for example, VIS121
7. Select the output format, use: multi-line key-value format
8. Identify the timestamp column, enter: START_TIME
9. Set the polling frequency or interval to hourly (default if left blank will be auto): 1h

7. Test by logging into the Oracle E-Business Suite and then looking at Splunk.
8. 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 info@integrigy.com.

References

• Integrigy Guide to Auditing and Logging in Oracle E-Business Suite
• Splunk DB Connector download: http://apps.splunk.com/app/958/
• Documentation for DB Connector (look for PDF link in lower left): http://docs.splunk.com/Documentation/DBX/latest/DeployDBX/Abouttheconnector
• Really good YouTube tutorial on the DB Connector: http://www.youtube.com/watch?v=aBU54PbSDHI

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 info@integrigy.com

References

• Oracle E-Business Suite Security - Signed JAR Files - What Should You Do
• All Java SE Downloads on MOS  https://support.oracle.com/rs?type=doc&id=1439822.1
• Deploying JRE for Windows Clients in EBS R12 https://support.oracle.com/rs?type=doc&id=393931.1
• Static vs. Non-static Versioning and Set Up Options See Appendix B in https://support.oracle.com/rs?type=doc&id=393931.1