Skip navigation.

Stephen Kost's E-Business Suite Security Blog

Syndicate content
Integrigy's Oracle Security Blog with information on security for the Oracle Database, Oracle E-Business Suite and other Oracle products.
Updated: 4 hours 37 min ago

Oracle 12c Real Application Security and Standard Database Auditing - Warning Database Logins Not Logged

Fri, 2014-09-05 05:00

Oracle 12c introduces several major new security features. Data redaction is one new feature and Real Application Security (RAS) is another.  Per Oracle, RAS is the next generation Virtual Private Database (VPD) and is installed with Oracle Enterprise Edition – no additional license required. RAS is a new declarative and granular authorization model and is designed to be an application security platform for end-to-end application security. For those developing APEX applications (also installed with Enterprise Edition), RAS will certainly become an integral tool.

With RAS, developers define security policies instead of having to create and maintain PL/SQL code. Most notably, RAS however extends the security solution to define both application users and roles separate from database users and roles.

RAS allows for the creation of users, complete with user names and passwords, and stores them in the database. RAS users are not stored in DBA_USERS. RAS users are defined in DBA_XS_USERS, and their passwords are stored in SYS. XS$VERIFIERS.

With 12.1.0.1, RAS users can also directly connect to the database. It appears that with 12.1.0.2, RAS users can be defined with a flag to allow or disallow direct database logons. As any database security monitoring and logging solution should be monitoring database logon activity, it should be known that RAS users will NOT show up in standard Oracle database auditing. Standard database auditing instead picks up login activity by the generic user XS$NULL. Because it is designed to be part of an application, RAS has its own logging and auditing solution.

Basic logon activity for RAS users, however is logged in SYS.UNIFIED_AUDIT_TRAIL.  Even if you have NOT enabled Unified Auditing in 12c, SYS.UNIFIED_AUDIT_TRAIL is being populated. Why this is the case will be the topic of another blog post.  If you have compliance requirements to log and audit database logons, you will need to monitor SYS.UNIFIED_AUDIT_TRAIL for RAS user activity as well as for the creation of RAS users if not also potentially configuring RAS auditing. The example below should get you started.

With the below you can test for yourself how standard database auditing logs RAS user logons:

  1. Ensure auditing for create session is enabled, if not: audit create session by access;
  2. Create Real application security user

BEGIN

XS_PRINCIPAL.CREATE_USER(NAME=>'INTEGRIGY_RAS_USER');

END;

  1. Set password for Real Application Security user

BEGIN

XS_PRINCIPAL.SET_PASSWORD('INTEGRIGY_RAS_USER','oracle');

END;

  1. Review both dba_users and dba_xs_users to see for yourself where RAS users are defined.
  2. Log into the database with: INTEGRIGY_RAS_USER/oracle
  3. Look at your auditing and see a logon from XS$NULL instead of INTEGRIGY_RAS_USER

select * from sys.aud$ order by 1 desc

  1. Now look at SYS.UNIFIED_AUDIT_TRAIL. You will see XS$NULL for the DBUSERNAME but you will see  'INTEGRIGY_RAS_USER' in XS_USER_NAME.

select dbusername,xs_user_name ,event_timestamp

from SYS.UNIFIED_AUDIT_TRAIL

where xs_user_name = 'INTEGRIGY_RAS_USER'

order by event_timestamp

If you are not familiar with XS$NULL, XS$NULL is created when the database component Oracle XML Database (XDB) is installed. XDB is now a mandatory component of 12c and as such, XS$NULL must exist in the database.  Per Oracle, XS$NULL is an internal account that represents the absence of a user in a session.  It is used by the lightweight session infrastructure for APEX, RAS and XDB and the name of this user is hard coded in those modules.  Because XS$NULL is not really a user, this account can only be accessed by the Oracle Database instance.  XS$NULL has no privileges, and no one can authenticate as XS$NULL, nor can authentication credentials ever be assigned to XS$NULL. 

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

References Tags: AuditingSecurity Strategy and StandardsOracle Database
Categories: APPS Blogs, Security Blogs

UTL_FILE_DIR Security Weakness: Why and How To Use Oracle Directories

Mon, 2014-07-28 12:39

UTL_FILE_DIR is the database initialization parameter the Oracle Database uses to determine what operating system directories and files PL/SQL packages, functions, and procedures may read from or write to when using the standard UTL_FILE database package.  The directories specified in the UTL_FILE_DIR parameter may be accessed by any database user, which can be a security issue.  In Oracle 9iR2, Oracle released new functionality called “Directories” that provides a more secure and robust capability to access operating system directories and files.  The advantages of using Directories over UTL_FILE_DIR are –

  • Read and/or Write access to a Directory can be granted to individual database accounts or roles
  • A Directory can be added without having to bounce the database
  • Directory name is used in the UTL_FILE.FOPEN statement rather than the directory path, which allows changes to the directory path without modification to the PL/SQL source code
Securing UTL_FILE

The UTL_FILE database package is used to read from and write to operating system directories and files.  By default, PUBLIC is granted execute permission on UTL_FILE. Therefore, any database account may read from and write to files in the directories specified in the UTL_FILE_DIR database initialization parameter.

Oracle usually assumes that PUBLIC has execute permission on UTL_FILE, therefore, many Oracle product installations do not specifically grant execute permission on UTL_FILE to Oracle installed database accounts.  Consequently, revoking execute permission on UTL_FILE from PUBLIC will result in errors in a number of standard Oracle database utilities and The Oracle E-Business Suite.  Also, some Oracle products and third party products will grant execute on UTL_FILE to PUBLIC during the installation of the product.

We do not recommend revoking execute permission on UTL_FILE from PUBLIC in database instances running the Oracle E-Business Suite and other complex applications (i.e., SAP, Peoplesoft, Oracle Clinical, etc.) due to the possibility of encountering errors in the application and third party products.  Only revoke execute permission from PUBLIC in database instances where the application, third party products, and all database management tools can be thoroughly tested.  All Oracle delivered products must be tested since Oracle often assumes UTL_FILE is granted to PUBLIC and does not provide the necessary grants when any products are installed – this includes products like Enterprise Manager Grid Control and Apex.

Security considerations with UTL_FILE can be mitigated by removing all directories from UTL_FILE_DIR and using the Directory functionality instead.

Oracle E-Business Suite and UTL_FILE_DIR

The combination of UTL_FILE being granted to PUBLIC and UTL_FILE_DIR being publicly accessible creates a significant security issue for the Oracle E-Business Suite.  The Oracle E-Business Suite uses UTL_FILE_DIR to read and write concurrent manager request temporary files.  Also, UTL_FILE_DIR is extensively used by most organizations to access interface and conversion data files from PL/SQL interface programs.

In the Oracle E-Business Suite, UTL_FILE_DIR is usually set to include at least the directories specified in $APPLPTMP and $APPLTMP – in the default installation this will include at least “/usr/tmp”.  Frequently, additional custom directories will be included for custom interfaces and other custom programs.

By accessing the APPLSYSPUB database account, an attacker can easy read and write interface data files.  Depending on the exact configuration, implemented modules, and custom interfaces, this could allow access to sensitive information including social security numbers and credit card numbers.

Migrating From UTL_FILE_DIR

For Oracle E-Business Suite customers, migrating from UTL_FILE_DIR to Directories requires only minimal changes and may require no source code changes depending on the design of the interfaces and other custom programs. The steps are as follows -

  1. Identify where UTIL_FILE is used
  2. Create Directories
  3. Change FOPEN calls to use Directories
  4. Edit UTL_FILE_DIR to remove physical Directories

Step One – Identify Where UTIL_FILE Is Used

The most difficult issue is identifying the packages, functions, and procedures using the physical directories in UTL_FILE_DIR.  The UTL_FILE_DIR physical directories are only directly referenced by the UTL_FILE.FOPEN function.  The FOPEN specifies the operating system directory and file name to open.  All subsequent read, write, and close function calls use the file handle returned by FOPEN.

The following SQL may assist in identifying uses of UTL_FILE_DIR in FOPEN statements –

SELECT * FROM dba_source 

WHERE upper(text) like '%FOPEN%' 

AND name like '%<custom prefix>%' 

AND owner = 'APPS' 

 If the calls to FOPEN are not in a common function and are not accessed through some other indirection, it should be fairly straightforward to find and change the necessary FOPEN references in any custom PL/SQL packages, functions, and procedures.  If the physical directory paths are stored in a table or in a concurrent program definition, then no changes to the source code are required.

At this time, converting the standard the Oracle E-Business Suite directories ($APPLPTMP and $APPLTMP) is not recommended as this is not supported by Oracle.  Theoretically it should work without any issues, however, the Oracle E-Business Suite references the directories in multiple places including the $APPLPTMP and $APPLTMP environmental variables, system profile options (e.g., “ECX: XSLT File Path”), and potentially in some configuration files.

Step Two – Create Directories

The following general steps are required to change the references from UTL_FILE_DIR to Directories. Please note that the directory name MUST always be in uppercase in all UTL_FILE.FOPEN statements, otherwise errors may be encountered

For each custom directory in UTL_FILE_DIR, execute the following SQL statements in each development, test, and production database instance –

 
CREATE OR REPLACE DIRECTORY <name> AS '<physical directory path>'; 
GRANT READ, WRITE ON DIRECTORY <name> TO APPS;            

as an example –

CREATE OR REPLACE DIRECTORY TMP_DIR AS '/usr/tmp'; 
GRANT READ, WRITE ON DIRECTORY TMP_DIR TO APPS; 

 

The directories “/usr/tmp” and “../comn/temp” and any other directories specified in $APPLPTMP and $APPLTMP should remain in UTL_FILE_DIR, since these directories are required by Oracle.

Step Three – Change FOPEN Calls to Use Directories

Once directories have been created the next step is to edit your code to use them. The process is straightforward. If a physical directory is specified in the UTL_FILE.FOPEN statement, change the hard-coded path to the Directory name. 

As an example –

FILE_ID := UTL_FILE.FOPEN('/usr/tmp', 'dummy.txt', 'W'); 

 change to –

FILE_ID := UTL_FILE.FOPEN('TMP_DIR', 'dummy.txt', 'W'); 

 Two pointers to keep in mind:

  1. Always be sure to use the directory name in uppercase and it must be enclosed in single quotes  
  2. If the physical directory is specified in a table or as a parameter in a Concurrent Program definition, then just specify the Directory name rather than a physical path – /usr/tmp becomes TMP_DIR

Step Four – Edit UTL_FILE_DIR to Remove Physical Directories

Remove all the custom physical directories from UTL_FILE_DIR.  The standard Oracle directories of ‘/usr/tmp’, ‘../comn/temp’, etc. should not be removed.  The database must be bounced for the change to take effect.

 

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

References Tags: Information DisclosureOracle DatabaseOracle E-Business Suite
Categories: APPS Blogs, Security Blogs

Oracle E-Business Suite Security - Signed JAR Files - What Should You Do – Part II

Fri, 2014-07-11 05:00

In our blog post on 16-May, we provided guidance on Java JAR signing for the E-Business Suite. We are continuing our research on E-Business Suite Java JAR signing and will be presenting it in a forthcoming educational webinar. Until then we would like to share a few items of importance based on recent client conversations -

  • Apply latest patches - The latest patches for Oracle E-Business Suite JAR signing are noted in 1591073.1. There are separate patches for 11i, 12.0.x, 12.1.x and 12.2.x. To fully take advantage of the security features provided by signing JAR files the latest patches need to be applied.
  • Do not use the default Keystore passwords - Before you sign your JAR files change the keystore passwords.  The initial instructions in 1591073.1 note that a possible first step before you start the JAR signing process is to change the keystore passwords. Integrigy recommends that changing the keystore passwords should be mandatory. The default Oracle passwords should not be used. Follow the instructions in Appendix A of 1591073.1 to change both keystore passwords. Each password must be at least six (6) characters in length. If you have already signed your JAR files, after changing the keystore passwords you must create a new keystore and redo all the steps in 1591073.1 to create a new signed certificate (it is much easier to change the keystore passwords BEFORE you sign your JAR files).
  • The keystore passwords are available to anyone with the APPS password - Using the code below anyone with the APPS password can extract the keystore passwords. Ensure that this fact is allowed for in your polices for segregation of duties, keystore management and certificate security.

SQL> set serveroutput on
declare 
spass varchar2(30); 
kpass varchar2(30); 
begin 
ad_jar.get_jripasswords(spass, kpass); 
dbms_output.put_line(spass); 
dbms_output.put_line(kpass); 
end; 
/

This will output the passwords in the following order:

store password (spass) 
key password (kpass)

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

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

Oracle E-Business Suite Security, Java 7 and Auto-Update

Wed, 2014-07-02 05:00

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

 

Tags: Security Strategy and StandardsOracle E-Business SuiteIT Security
Categories: APPS Blogs, Security Blogs

Trusting Privileged Users, DBMS_SQLHASH, and Three Misconceptions about Encryption

Thu, 2014-06-26 05:00

Clients often contact Integrigy requesting assistance to protect their sensitive data. Frequently these are requests for assistance to locate and then encrypt sensitive data. While encryption  offers protection for sensitive data, it by no means solves all security problems. How to protect sensitive data (and how to verify the trust of privileged users such as database administrators with sensitive data) requires more than just encryption.

The Oracle Database Security Guide (a great read for anyone interested in Oracle database security) makes three key points in Chapter Eight about encryption:

  1. Encryption does not solve access control problems - A user who has privileges to access data within the database has no more nor any less privileges as a result of encryption
  2. Encryption does not protect against a malicious database administrator - If untrustworthy users have significant privileges, then they can pose multiple threats to an organization, some of them far more significant than viewing unencrypted credit card numbers
  3. Encrypting everything does not make data secure – Data must be available when needed as well as backups and DR solutions considered. Moreover, encrypting all data will significantly affect performance.
     
DBMS_SQLHASH

Besides encryption, one of the security tools that Oracle provides is the DBMS_SQLHASH package. Hash values are similar to data fingerprints and can be used to validate if data has been changed (referred to as data integrity). Hashing is different from encryption and it is important to know the difference. If you need to know more about hashing, see the reference section below.  

The DBMS_SQLHASH package has been delivered since 10g and provides an interface to generate the hash value of the result set returned by a SQL query and provides support for several industry-standard hashing algorithms including SHA-1.

DBMS_SQLHASH.GETHASH(sqltext IN varchar2,

                                                digest_type IN BINARY_INTEGER,

                                                chunk_size IN number DEFAULT 134217728)

 

sqltext

The SQL statement whose result is hashed

digest_type

Hash algorithm used: HASH_MD4, HASH_MD5 or HASH_SH1

Use 3 for HASH_SH1, Use 2 for HASH_MD5 and 1 for HASH_MD4

chunk_size

Size of the result chunk when getting the hash

When the result set size is large, the GETHASH function will break it into chunks having a size equal to chunk_size. It will generate the hash for each chunk and then use hash chaining to calculate the final hash. The default chunk_size is 128 MB.

 

How Can Auditors use DBMS_SQLHASH

One use case for DBMS_SQLHASH is to help auditors trust-but-verify the actions of privileged users such as database administrators. By hashing key tables an auditor can quickly determine if the database administrator has made changes – either authorized or unauthorized. An auditor can do this by recording hashes at the start of an audit period for comparison to hashes at the end of the period. If the hashes at the end of the audit period match the hashes at the beginning of the period, no changes have been made. If there are a large number of databases and/or tables to audit, this approach is a very beneficial means of identifying what requires additional review – assuming sufficient logging has been configured to capture the details of the changes.

For example, to determine if there have been changes to Oracle database users and their associated privileges over a period of time, such as granting access to sensitive data, an auditor can hash the following Dictionary tables:

  • SYS.DBA_USERS
  • SYS.DBA_ROLES
  • SYS.DBA_TAB_PRIVS
  • SYS.DBA_SYS_PRIVS
  • SYS.DBA_ROLE_PRIVS

Examples

Note: to call the SYS.DBMS_SQLHASH package, the user will need execute rights granted from SYS.

Control

DBA_USERS

SQL

SELECT SYS.DBMS_SQLHASH.GETHASH ('SELECT * FROM SYS.DBA_USERS ORDER BY USER_ID', 3) sh1_dba_user_hash FROM DUAL;

Sample

Result

Sh1_dba_user_hash

7BD61E22E35FA2F95035E6A794F5B8CF0E37FDF6

 

Control

SYS.DBA_ROLES

SQL

SELECT SYS.DBMS_SQLHASH.GETHASH('SELECT * FROM SYS.DBA_ROLES ORDER BY ROLE', 3) sh1_dba_roles_hash FROM DUAL;

Sample

Result

sh1_dba_roles_hash

C80D69048D613E926E95AF77B627D9B5D6CB20C8

 

Control

SYS.DBA_TAB_PRIVS

SQL

SELECT SYS.DBMS_SQLHASH.GETHASH('SELECT * FROM SYS.DBA_TAB_PRIVS ORDER BY OWNER,TABLE_NAME', 3) sh1_dba_tab_privs_hash FROM DUAL;

Sample

Result

sh1_dba_tab_privs_hash

53FBDBDBF95186400A4DEEE611F51CD0B1E998DF

 

Control

SYS.DBA_SYS_PRIVS

SQL

SELECT SYS.DBMS_SQLHASH.GETHASH('SELECT * FROM SYS.DBA_SYS_PRIVS ORDER BY GRANTEE, PRIVILEGE', 3) sh1_dba_sys_privs_hash FROM DUAL;

Sample

Result

sh1_dba_sys_privs_hash

A27E8C71AD0CAEFB94AFEAB5DB108871F09BC281

 

Control

SYS.DBA_ROLE_PRIVS

SQL

SELECT SYS.DBMS_SQLHASH.GETHASH('SELECT * FROM SYS.DBA_ROLE_PRIVS ORDER BY GRANTEE, GRANTED_ROLE', 3) sh1_dba_role_privs_hash FROM DUAL;

Sample

Result

sh1_dba_role_privs_hash

5715D1B2C2A775D579B36DEBD2C2F1F608762AEC

 

Key Point

The order by clause will change the HASH. Oracle Support Note 1569256.1 explains this in more detail.  To guarantee the same HASH for a SQL issued at different times, the same ordering of the data must be used.

If you have questions or are interested in Integrigy's hashing methodology for Oracle and the Oracle E-Business Suite, please contact us at info@integrigy.com

References Tags: AuditingSecurity Strategy and StandardsSensitive DataOracle DatabaseAuditor
Categories: APPS Blogs, Security Blogs

Splunk DB Connect Tail for Oracle E-Business Sign-on Audit

Fri, 2014-06-06 05:00

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$ > ?}}

  1. Identify the rising column, enter: LOGIN_ID
  2. Identify the index, as a quick demo to get going just use the default, enter: default
  3. Identify a Host Field value, you can enter the database SID, for example, VIS121
  4. Select the output format, use: multi-line key-value format
  5. Identify the timestamp column, enter: START_TIME
  6. Set the polling frequency or interval to hourly (default if left blank will be auto): 1h
  1. Test by logging into the Oracle E-Business Suite and then looking at Splunk.
  2. 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 Tags: AuditingComplianceOracle E-Business Suite
Categories: APPS Blogs, Security Blogs