Skip navigation.

Security Blogs

Logging Oracle Database Link Activity

A database link is a one-way connection between two databases.  Starting with Oracle version 11.2.0.3, database session information now reports additional information for those sessions involving database links.  As often database links are created between databases of different security profiles; it is important to log session activity that includes the details of the database link.

DBLINK_INFO returns the source of a database link.  Specifically, it returns a string of the form –

SOURCE_GLOBAL_NAME=dblink_src_global_name

DBLINK_NAME=dblink_name

SOURCE_AUDIT_SESSIONID=dblink_src_audit_sessionid

where:

  • dblink_src_global_name is the unique global name of the source database
  • dblink_name is the name of the database link on the source database
  • dblink_src_audit_sessionid is the audit session ID of the session on the source database that initiated the connection to the remote database using dblink_name

You can verify DBLINK_INFO –

  • Oracle 12c provides a DBLINK_INFO column in SYS.UNIFIED_AUDIT_TRAIL.
  • SELECT SYS_CONTEXT('USERENV','DBLINK_INFO') FROM DUAL

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

Reference Tags: AuditingOracle Database
Categories: APPS Blogs, Security Blogs

Logging Actual Application User Names for Oracle E-Business Suite, SAP, PeopleSoft, and OBIEE

Knowing which person, not just which database account, has been a challenge for database logging and auditing when working with enterprise software applications such as the Oracle E-Business Suite, SAP, PeopleSoft, and OBIEE.  Knowing which application user did what and when is now much easier because of adoption of standard Oracle functionality.

Standard functionality of Oracle database is the CLIENT_IDENTIFER attribute.  The CLIENT_IDENTIFIER is a predefined attribute of the built-in application context namespace, USERENV, and can be used to capture the application user name.

CLIENT IDENTIFIER is set using the DBMS_SESSION.SET_IDENTIFIER procedure to store the application username.  The CLIENT IDENTIFIER attribute is one the same as V$SESSION.CLIENT_IDENTIFIER.  Once set, you can query V$SESSION or select sys_context('userenv','client_identifier') from dual.

The table below offers examples of how CLIENT_IDENTIFIER is now being used by the Oracle E-Business Suite, SAP, and PeopleSoft. If you are running one of these software packages, Integrigy highly recommends that you incorporate the information that the CLIENT_IDENTIFIER provides into your logging and auditing solution.

Oracle CLIENT_IDENTIFIER

Application

Application Usage

Oracle

E-Business Suite

As of Release 12, the Oracle E-Business Suite automatically sets and updates client_identifier to the FND_USER.USERNAME of the user logged on.  Prior to Release 12, follow Support Note How to add DBMS_SESSION.SET_IDENTIFIER(FND_GLOBAL.USER_NAME) to FND_GLOBAL.APPS_INITIALIZE procedure (Doc ID 1130254.1)

Oracle

PeopleSoft

Starting with PeopleTools 8.50, the PSOPRID is now additionally set in the Oracle database CLIENT_IDENTIFIER attribute. 

SAP

With SAP version 7.10 above, the SAP user name is stored in the CLIENT_IDENTIFIER.

Oracle Business Intelligence Enterprise Edition(OBIEE)

When querying an Oracle database using OBIEE the connection pool username is passed to the database.  To also pass the middle-tier username, set the user identifier on the session.  To do this in OBIEE, open the RPD, edit the connection pool settings and create a new connection script to run at connect time.  Add the following line to the connect script:

CALL DBMS_SESSION.SET_IDENTIFIER('VALUEOF(NQ_SESSION.USER)')

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

Reference Tags: AuditingOracle DatabaseOracle E-Business SuiteOracle PeopleSoftSAPOracle Business Intelligence (OBIEE)
Categories: APPS Blogs, Security Blogs

Oracle Critical Patch Update October 2014 - Massive Patch

Just when you thought the Oracle Database world was getting safer, Oracle will be releasing fixes for 32 database security bugs on Tuesday, October 14th.  This is in stark contrast to the previous twenty-five quarters where the high was 16 database bugs and average per quarter was 8.2 database bugs.  For the previous two years, the most database bugs fixed in a single quarter was six.

In addition to the 32 database security bugs, there are a total of 155 security bugs fixed in 44 different products.

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

Oracle Database

  • There are 32 database vulnerabilities; only one is remotely exploitable without authentication and 4 are applicable to client-side only installations.
  • Since at least one database vulnerability has a CVSS 2.0 metric of 9.0 (critical for a database vulnerability), this is a fairly important CPU due to severity and volume of fixes.
  • The remotely exploitable without authentication bug is likely in Application Express (APEX).  Any organizations running APEX externally on the Internet should look to apply the relevant patches immediately.  To patch APEX, the newest version must be installed, which requires appropriate testing and upgrading of applications.
  • There are four cilent-side only installations and likely most are in JDBC.
  • Core RDBMS and PL/SQL are listed as patched components, so most likely there are critical security vulnerabilities in all database implementations.

Oracle Fusion Middleware

  • There are 17 new Oracle Fusion Middleware vulnerabilities, 13 of which are remotely exploitable without authentication and the highest CVSS score being 7.5.
  • Various Fusion Middleware products are listed as vulnerable, so you should carefully review this CPU to determine the exact impact to your environment.
  • The core WebLogic Server is listed as a patched component, therefore, most likely all Fusion Middleware customers will have to apply the patch.

Oracle E-Business Suite 11i and R12

  • There are nine new Oracle E-Business Suite 11i and R12 vulnerabilities, seven of which are remotely exploitable without authentication.  Many of these are in core Oracle EBS components such as Oracle Applications Framework (OAF) and Application Object Library (AOL/FND).  Even though the maximum CVSS score is 5.0, most of these vulnerabilities should be considered high risk.
  • All DMZ implementations of Oracle EBS should carefully review the CPU to determine if there environment is vulnerable.  As all Oracle EBS CPU patches are now cumulative, the CPU patch should be prioritized or mitigating controls, such as AppDefend, be implemented.

Planning Impact

  • We anticipate this quarter's CPU to be higher risk than most and should be prioritized.  Based on the patched components, this may be a higher than average risk CPU for all Oracle database environments.
  • 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.
  • For Oracle E-Business Suite customers, DMZ implementations may have to apply this quarter's patch faster than previous quarters due to the number and severity of bugs.
Tags: Oracle Critical Patch Updates
Categories: APPS Blogs, Security Blogs