You are on page 1of 89

Practice Aid

Oracle
System Administration
Release 12

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 1 of 89

Oracle System Administration Practice Aid


Table of Contents
A. INTRODUCTION.........................................................................3
1. Engagement Tools..............................................................................................................................3

B. ORACLE ENGAGEMENT CONSIDERATIONS ...................................6


C. ORACLE APPLICATION HIGHLIGHTS............................................7
1. Application Structure...........................................................................................................................7
2. Oracle Application Release History.....................................................................................................9
3. Overview of System Administration...................................................................................................10

D. FLEXFIELDS............................................................................14
1. Flexfield Types..................................................................................................................................14
2. Key Flexfield Components.................................................................................................................16
3. Descriptive Flexfield Components.....................................................................................................21

E. AUDITING...............................................................................23
1. Oracle Auditing Methods...................................................................................................................23
2. Non-Audit based Change Control......................................................................................................25
Configuration/Functionality Changes with iSetup..................................................................................25

F. END USER ACCESS...................................................................26


1. Responsibility and Security Group Management...............................................................................26
2. User Management.............................................................................................................................37
3. Password Management.....................................................................................................................47
4. Identity Management.........................................................................................................................49
5. Multi organization access control.......................................................................................................52

G. APPLICATION SUPPORT RESPONSIBILITIES AND USERS .............56


1. Support Responsibilities....................................................................................................................56
2. Application Support User IDs ............................................................................................................64
3. APPS Database ID............................................................................................................................64

H. SYSTEM PROFILE OPTIONS......................................................70


1. Site-Level .........................................................................................................................................70
2. Application-Level ..............................................................................................................................70
3. Responsibility-Level ..........................................................................................................................70
4. User-Level ........................................................................................................................................71
5. Key Profile Options............................................................................................................................72

I. SEGREGATION OF DUTIES CONCEPTS.........................................78


J. RESTRICTED ACCESS/SEGREGATION OF DUTIES .........................80
1. Application Setups.............................................................................................................................80
2. Standing Data ...................................................................................................................................80
3. Segregation of Duties........................................................................................................................80

K. RELEVANT MODULES...............................................................84
1. iSetup................................................................................................................................................84
2. AME..................................................................................................................................................85

L. FORMS THAT ACCEPT SQL ENTRY.............................................86


M. GLOSSARY.............................................................................89
1. Key Oracle Functionality....................................................................................................................89
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 2 of 89

A. Introduction
This Practice Aid and the associated tools (Work Program(s) and GATE) are for INTERNAL USE ONLY.
As management is responsible for designing and implementing a system of internal control, this Practice
Aid and its associated tools should not be distributed to our clients.
These tools are intended to be used by PwC Oracle specialists performing an audit, attestation or
consulting engagement involving the review of the client's Oracle application. For individuals intending to
use this Practice Aid and / or related tools, they must have sufficient technical skills to conduct such work.
It is highly recommended that at least one member of the team has specific training or experience in the
ERP wherever practicable.

1. Engagement Tools
The Tools noted below provide a general overview of the Oracle application, along with its related
control risks and common application controls. When these tools are utilized, the following important
caveats and reminders should be considered prior to the use of these tools:
Refer to PwC Audit Guide for policy on understanding, evaluating and validating internal controls.
This Practice Aid and related tools are not a substitute for PwC Audit.
This Practice Aid and its related tools should only be used in conjunction with proper risk-based
engagement planning and scoping. The relevance and importance to the engagement of
transaction processing, risks and controls associated with the noted modules of Oracle should be
clearly understood before work is begun, and the tools should be tailored to each client
environment.
This Practice Aid and its associated Work Program(s):
o
May not present all control risks associated with your client's use of Oracle
o
Are not intended to address all possible relevant application controls in the
process(es) supported by the modules noted herein within Oracle ;
o
Do not address Information Technology General Controls (ITGCs);
o
Are focused primarily on automated, not manual, controls; and
o
Do not present all possible key controls and do not represent the minimum nor
maximum level of key controls that must exist.
o
May have particular functionality or controls referenced as "key". This term
indicates that this control / functionality might be important to the client's control
environment. However, the identification of a key control for a client's environment will
vary based on the client's unique risk circumstances, control environment and / or the
client's use of the application.
This Practice Aid and its associated tools are based on a standard installation of the ERP
package. Clients often customize their applications. Since each ERP implementation is unique,
our work should be based on an understanding of the client's actual systems and processes, as
implemented, not on a generic/sample process or system configuration.
Because inherent functionality and controls can be affected by system customizations,
practitioners should discuss any customizations and the approach to testing inherent functionality
with engagement management.
Each practice aid is specifically written for Oracle Release 12. Use with any other versions should
be done with careful consideration, as there are differences between each Oracle release.

1.1. Practice Aid


PwC's Oracle Practice Aids are documents designed to give a user a broad understanding of Oracle's
associated applications, their functionality, and control considerations. These documents are not
intended to provide comprehensive general guidance on this process in non-Oracle environments.
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 3 of 89

For guidance on other modules within Oracle for which there is no PwC Practice Aid, please refer to
appropriate Oracle User guides for further details. These can be found at
http://www.oracle.com/technology/documentation/index.html
Each practice aid is specifically written for Oracle's Release 12 and is divided into 5 main sections, as
outlined below:
1.1.1. Introduction/Engagement Approach
The Introduction section of each practice aid outlines potential tools and engagement
approaches that may be used when conducting an assessment of an Oracle ERP system. In
addition, this contains important Risk and Quality-related caveats and reminders that should
be followed for every Oracle engagement.
1.1.2. Business Setups
In this section, key set-ups and configurations that are generally only configured upon
installation, upgrades, or major business events are discussed. Definitions of the key
configurations are provided to give the practitioner a basic understanding of the setups.
1.1.3. Standing Data
Within the Standing Data section, key configurations that are subject to periodic changes are
discussed. Along with functionality definitions, this section outlines how standing data is
generally entered into the application. In addition, the linkages between the standing data and
business setups are outlined.
1.1.4. Transactions
This section outlines the key transactions within the business process. This includes the
definition of the transactions, how transactions are generally entered into the system, as well
the data flow between transactions, standing data, and business setups.
1.1.5. Access and Segregation of Duties
This section outlines the typical access and segregation of duties risks within the Practice
Aid's business process.
Within the Standing Data and Transactions sections of the Practice Aid, "Control
Considerations" are also outlined. Each Control Consideration section is broken into 4 parts,
as outlined below:
o
Business Process Variables: These discuss the most common
configurations/transactions that may be set up or used differently depending upon the
client's use of Oracle's functionality.
o
Control Dependencies: This section outlines how configurations or transactions
are dependent upon each other or other settings within the application.
o
Control Limitations: This section outlines how system configurations or
transactions may be overridden. In addition, this section highlights common
misconceptions about how the configuration or transaction operates.
o
Testing Notes: This section provides suggestions on how a practitioner might test
or assess configurations and/or transactions.
The controls considerations section of the Practice Aid focuses solely on high-level concepts.
For a listing of controls, refer to the module's work program. This Practice Aid does not list all
Oracle standard reports that exist for this cycle. For a complete list of this module's standard
Oracle Reports, refer to the Oracle user guide at
http://www.oracle.com/technology/index.html. However, for the SA functionality the user
guide does not cover all existing reports.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 4 of 89

1.2. Work Program


The Work Program outlines the typical automated controls within the Oracle application. For each
control, this document provides a typical control description, business risk, control objective, financial
statement assertions, information processing objectives, Oracle Application navigation path,
validation procedures, and expected results. Each processes' work program is specifically designed
for a particular release of the Oracle Application.
For the purposes of an audit of financial statements, an audit of internal controls over financial reports
or an integrated audit, teams should consider those controls which have been classified as Financial
in nature. The work program is currently available through the Knowledge Gateway in the US
(accessible through Knowledge Curve) or Guardian (http://guardian.pwcinternal.com) in other
territories.

1.3. GATE
Oracle GATE is a proprietary web-based tool developed to assist in the analysis of Oracle
configuration and security. The tool may be used in an audit of financial statements, audit of internal
controls over financial reporting or a consulting non-attest review of the Oracle application. For Oracle
releases 11.5.7 and later, Oracle GATE can assist with segregation of duties analysis and module
configuration. To use Oracle GATE, a series of SQL queries are run against the client's environments
to pull data from Oracle database tables. The output from these queries is uploaded to the GATE
server and queries can be run against the server to obtain information about how the client's Oracle
Application is configured. The Oracle GATE tool can be accessed at oraclegatev2.pwcinternal.com.
For individuals intending to use GATE, they must have sufficient technical skills to conduct such work.
Note: Prior to running any command or script on a client system, discuss with the client and obtain
verbal consent. Written consent is also recommended to the extent that this may be obtained.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 5 of 89

B. Oracle Engagement Considerations


Practitioners may want to consider the following items during an audit of financial statements, an audit of
internal controls over financial reporting, or a consulting non-attest review of the Oracle application.
1) Determine which version of the software your client is using. Check the version against the
compatibility table in the "Application Highlights" section of this Practice Aid, to ensure the
appropriate Practice Aid is utilized.
2) Inquire of the client's business owners and system administrator if any customizations to the
standard software have been made. Request a list of these customizations to assess the effect.
3) Confirm the number of instances (separate Oracle databases environments) that the client
maintains.
4) Confirm the number of Ledgers, Operating Units and Modules in scope within each Oracle
instance.
5) Interview the systems administrator or other suitable IT personnel to gain knowledge and
understanding of the system design (linkage with external applications, databases and network).
6) Ascertain the approximate size of the user population and number of responsibilities.
7) Approach the security manager and request that a user is created for the practitioner. This role/
group should enable the practitioner to have read-only access to all menus and programs in the
in-scope Oracle application.
8) Discuss the relevant business processes with the client, ensuring an understanding of the
application version, functionality, and reports (customized or normal) that the client relies upon.
9) A fresh copy of the Practice Aid and its related Work Program(s) should be downloaded for each
new engagement to ensure the most up-to-date version is used for tailoring.
10) Based upon the knowledge gained regarding the client's environment, tailor the Work Program to
match the client's business processes and specific risk profile.
11) When documenting any test results and resulting risks, consider both the
mitigating/compensating controls, and manual processes that may impact an automated
environment.
12) If needed, contact the key contacts shown in the Contacts section of this for additional guidance
regarding complex technical situations that may arise during the engagement.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 6 of 89

C. Oracle Application Highlights


1. Application Structure
The Oracle E-Business Suite (EBS) Enterprise Resource Planning (ERP) system is an integrated
software solution that runs off an Oracle database instance. An ERP consists of applications or
modules. Most modules hold transactional data for each business process area (financials, supply
chain management, customer relationship management, manufacturing, human resources, etc.).
Some modules are used for system-wide support. Each module is linked to each other via the
database; therefore, information is seamlessly integrated.
Users access functions either via a forms-based model, or in the case of Self-Service modules, a
web-based model via the End User Tier mentioned in further detail below.
The Oracle EBS system is a three-tier system that consists of the End Users Desktop, Application
Servers and Database Servers.

Tier 1 End-User Tier

Tier 2 - Application Tier


Web Servers (optional)

Optional

Optional

Application Servers (Forms


servers, concurrent processing
servers, administration servers)

Oracle
Database
Server

Tier 3 - Database Tier

1.1. End User Tier


The end user tier is the path by which users gain access to the application tier. Users access the
application via their own computers and a URL address. From the URL address, users enter a user
name and password (previously defined at the application tier), which grants them access to the
application tier. Once onto the application tier, user access is governed by responsibilities assigned to
the user.

1.2. Application Tier


The application layer, or middleware, contains the key application programs as well as programs to
support web use, screens and administrative tasks within the system. There are several key servers
that may exist within this layer some of which are detailed below:

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 7 of 89

1.2.1. Web Server (Oracle Portal)


The Portal manages access to Oracle Forms (note that this is the definition Oracle uses to
describe screens or windows displayed on the monitor).
1.2.2. Forms Server
The forms server stores the format of the Oracle forms. This is also where the application and
some administrative functions reside (i.e. entering and posting of journal entries). The forms
server interfaces directly to the Database tier.
1.2.3. Concurrent Processing
The Concurrent Processing's primary purpose is to load balance the system and enhance
performance. Concurrent processing is managed through a scheduling system that controls
when updates occur. Along with the scheduling system, concurrent processing can prioritize
activities based on transaction importance. It is also used to provide batch processing
capability.
Reports and other requests are executed by this server, which interfaces directly to the
Database tier.
1.2.4. Administration Server
This server interfaces directly to the Database tier and provides operational support such as
backup, recovery, startup and shutdown. In addition, it provides statistical information on
system use and performance.

1.3. Database Tier


The database environment allows for storage and retrieval of user and administrative data and of
other application programs and components. Oracle Enterprise Database Management System
(DBMS) is the only DBMS that will work with Oracle applications. Releases of Oracle DBMS are
intended to operate with specific versions of Oracle applications. The version numbers of the
database do not correspond with the Oracle applications version numbers. Within Oracle EBS, all
data (master, standing, security and transactional) are stored in the Oracle DBMS.
Since the Oracle DBMS contains all Oracle-related financially-significant data, the Oracle DBMS is
considered the highest risk of the three tiers.

1.4. File System


Oracle has made a primary change to the file structure supporting the applications in Release 12.
Oracle has now provided an instance-specific directory(s) to support each unique environment - dev,
test, prod, etc. The new instance home model supports two key concepts:

The base configuration directories APPL_TOP and ORACLE_HOME can be read-only to


support change control. With instance-specific data files separated into dedicated directories,
upgrades and migrations should be more easily controlled. Common application files are not
touched for instance-specific modifications.

Another advantage of employing the concept of an Instance Home is that log files can be
stored centrally for an instance, and therefore managed more easily. This is particularly
significant from a security perspective, as log files may contain sensitive data that should not
be accessible to general users.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 8 of 89

The following picture depicts the structure of the Oracle EBS file system:

2. Oracle Application Release History


Version

Rele
ase
date

Market Prevalence

10.7

1998

11.0.3

1999

-Rare.
-Limited support by
Oracle corporation.
-Limited.
-Full support by
Oracle.

11i Environment
11.5.5,
2000 -Limited Use
11.5.6
-Supported by Oracle
11.5.7,
11.5.8,
11.5.9

2002
(5.7)

11.5.10

2005

-11.5.7 & 5.9 in broad


use
-11.5.8 use limited
(buggy)
Broad use

12

2007

Latest release.

Functionality Changes

Practice Aid
and Work
Program
Applicability
No

OASIS/ GATE

No

OASIS

-Enhanced performance
-Web based

Yes

GATE

-Expansion in Web based and


workflow functionality

Yes

GATE

-Significant changes in System


Administration module, including
limited introduction of Role
Based Access Control.
-Significant changes in System
Administration module, General
Ledger, and infrastructure.

Yes

GATE

Yes

GATE

-Limited system audit


capabilities
-Full character based
-Corrected Y2K deficiencies
-Included client / server
environment
-Introduced GUI Interface

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Compatibility
OASIS

Page 9 of 89

3. Overview of System Administration


The Application Object Library (AOL) module is the gateway to all functionality in Oracle applications. The
following key functions are performed within the AOL module:
Flexfields
Auditing and Change Control
User Management
System Profile Options
System Reports
NOTE: Internally at PwC, we refer to the AOL and System Administration module together as
System Administration (SA).

3.1. Flexfields
As the name suggests, flexfields are flexible fields made up of sub-fields, or segments. Oracle uses
two types of flexfields: key flexfields and descriptive flexfields. Key flexfields are stored codes (or
values) used system-wide for general ledger accounts, part numbers, and other business entities. On
the other hand, Descriptive flexfields provide customizable "expansion space" on Oracle forms to
track unique to the company's business. For a more detailed discussion of flexfields, refer to the
Flexfields section below.

3.2. Auditing and Change Control


Auditing can be enabled to monitor changes made either through the application or directly to the
database rows. In addition, the application can be enabled to monitor successful and unsuccessful
user logons and the responsibilities, terminals, or forms accessed by a user are noted.
Change control monitors who requested the change, the expected results from the change, the
testing procedures and their outcomes, and the final approval by management to implement the
change in production. A record of change control includes who, what, when, where and why. Please
see the Auditing section of this Practice Aid for further discussion.
The iSetup functionality available from 11i can support the change management process. It enables
administrators to extract, transform and migrate setup data in a controlled way and compare setup
data with available standard reports.

3.3. User Management


In addition to the AOL module, the System Administration module is used to store the Oracle
responsibility (user profile) definitions. There are various objects/settings assigned to a responsibility
within the application that allow a User ID the ability to perform activities within Oracle (i.e. data
groups, menus, functions and request security groups). The application comes with a number of
default responsibilities, but a company can customize responsibilities to suit their business needs and
restrict access to various tasks as appropriate.
Responsibilities can be defined to allow access to the following areas:
Specific applications/modules.
Ledger name/Legal entity.
Restricted list of windows.
Restricted list of functions.
Reports in specific application.
A diagram outlining the relationship between users, responsibilities, functions and modules is below:

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 10 of 89

Oracle End Users

Oracle Role
(available in
11.5.10)

User 1

GL Controller

User 2

AR Inquiry

AP Payment
Supervisor

Oracle
Responsibility
GL Forms /
Functions

Oracle Forms /
Functions

Oracle Modules

Oracle General
Ledger

AR Forms /
Functions

Oracle
Accounts
Receivables

AP Forms /
Functions

Oracle
Accounts
Payables

There is no default user access that is granted just by being given an account in Oracle EBS. The
security administrator (through the System Administrator responsibility) must assign a User ID with
responsibilities for the user to be granted abilities to perform tasks/functions within Oracle.
Due to the newly introduced functionality multi-organizational access control (MOAC) functionality,
users can access multiple operating unit (OU) data either within or across business groups from a
single responsibility. Using MOAC, multiple operating units are assigned to a security profile. This
security profile is then assigned either to responsibilities or directly to users. A typical usage would be
responsibility in a shared service centre, which serves different operating units. For further details on
MOAC please refer to the section on Multiple Organization Access Control.

3.4. System Profile Options


System Profile Options can be grouped into three types: Security, Organization, and Server types.
Practitioners are mainly concerned with Security type profile options that affect the operation of
Oracle Applications. Security type profile options can be configured according to the needs of the
user community, as they can be set at the Site, Application, Responsibility, or User level. Security
profile options are generally maintained by the Application System Administrators and may be set at
more than one level: Site has the lowest priority, superseded by Application, then Responsibility, and
finally User. Higher profile option settings will override lower level options. The security system profile
options hierarchy is documented below in the diagram. Please see the System Profile Options
section of this Practice Aid for more details.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 11 of 89

3.5. System Reports


The following table lists key default reports that can be used for the assessment of Oracle System
Administration when the Oracle GATE Application is not being utilized:
Reports

Description

Active
Responsibilities
and
Users
(Application
Object Library)

The report of responsibilities linked to the users assigned to the responsibility

Active Users

All the usernames that are both currently active and have at least one active
responsibilities

CP SQL*Plus
Expire
FND_USER
Passwords

Concurrent Request to Force All Applications Users To Change their Password

Workflow
Directory
Services
User/Role
Validation
(Application
Object Library)

Validates the user/role information in Workflow Directory Services

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 12 of 89

Sample report: Active Responsibilities and Users Report

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 13 of 89

D. Flexfields
Flexfields are Oracle's main method of storing data. Flexfields provide clients with flexible features
needed to satisfy the following business needs:
Configure applications to conform to current business practice for accounting codes, item/product
codes, HR codes such as job and position codes, and other codes.
Configure applications to capture data that would not otherwise be tracked by the application.
Have "intelligent fields" that are fields comprised of one or more segments, where each segment
has both a value and a meaning.
Rely upon application to validate the values and the combination of values that are entered in
intelligent fields.
Have the structure of an intelligent field change depending on data in the form or application data.
Configure data fields to your meet your business needs without programming.
Query intelligent fields for very specific information.
Flexfields are generally created and maintained by a System Administrator via the Applications Object
Library (Sys Admin) module. The following sections describe the types of flexfields available and how
these flexfields are structured.

1. Flexfield Types
There are two types of flexfields in Oracle: Key flexfields (such as a job flexfield) and Descriptive
flexfields (additional order hold approval information). Each flexfield is made up of segments (i.e. subfields) for which data entry and validation procedures may be easily completed without programming.

1.1. Key Flexfields


Key flexfields provide a flexible way for the Oracle Applications to represent objects such as
accounting codes, item numbers, job descriptions, and more. Key flexfield definitions are seeded
within Oracle forms, and some key flexfields are required, while others are optional. Here is a table
listing all the key flexfields in Oracle Applications, ordered by the application that "owns" the key
flexfield. Note that other modules, who do not "own" the flexfield, may have access to define and/or
use the flexfield.
Owner
Oracle Assets

Name
Asset Key Flexfield
Category Flexfield
Location Flexfield
Accounting Flexfield (changes within the Flexfield)
Grade Flexfield
Job Flexfield
Personal Analysis Flexfield
Position Flexfield
Soft Coded KeyFlexfield
Account Aliases
Item Catalogs
Item Categories
SalesOrders
Stock Locators
System Items
Bank Details
Cost Allocation
People Group
Sales Tax Location

Oracle General Ledger


Oracle Human Resources

Oracle Inventory

Oracle Payroll

Oracle Receivables (Penaki)


PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 14 of 89

Owner
Oracle Service

Name
Territory
Oracle Service Item
Training Resources

Oracle Training Administration

To an end user, a key flexfield appears on the form as a normal text field with an ellipsis
prompt at
the end of the field. This prompt function has a drill down, bringing users to a list of values These
segments and combination of values (segment values) represent the object. For example, the
General Ledger uses a key flexfield to represent accounting codes throughout Oracle Applications.
The following screenshot illustrates the drilldown from an accounting flexfield on a journal entry
window to its individual segments and segment values.

Code Combination

Segment Values for Account Segment


Segments

For more information on the components of flexfields, refer to the following sections. For information
on how each key flexfield is used within its "owner" application, please refer to that module's Practice
Aid and/or Oracle User Guide at http://www.oracle.com/technology/index.html.

1.2. Descriptive Flexfields


Similarly, descriptive flexfields provide a flexible way for Oracle to provide configurable "expansion
space" or additional fields in forms. A descriptive flexfield appears on the form i.e. screen as a twocharacter-wide text field with square brackets [ ] as its prompt, or as context-sensitive fields that
appear only when needed.
The following screenshot illustrates a descriptive flexfield called Reconciliation Headers used to
capture additional data that would not normally be required in a journal entry window.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 15 of 89

Both types of flexfields described above enable clients to customize Oracle Application features
through simple configuration setups i.e. without programming. The following sections discuss the
setup steps required to configure these flexfields.

1.3. Control Considerations


Refer to each module's practice aid for control considerations pertinent to that's module's specific
flexfields.

2. Key Flexfield Components


2.1. Flexfield Structure
To create a key or descriptive flexfield, clients must first select the type of structure, such as an
Accounting Flexfield, Asset Flexfield, or Item Catalog. Then, they must create the structure. Flexfield
structures provide the framework for all of the flexfield's components and tie the Key Flexfield to the
Application. Below, the Accounting Flexfield named Operations_Accounting (the structure) is created.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 16 of 89

Each Key flexfield can be set with the following configurations.


2.1.1. Freeze Flexfield Definitions
Once the structure's setup has been completed (or modified), the flexfield definition must be
frozen and saved. These actions cause flexfields to compile automatically in order to improve
on-line performance.
2.1.2. Enabling Flexfield Structures
The Enabled check box is checked so that structures may be used in key flexfields.
Structures cannot be deleted from this window because they are referenced elsewhere in the
system, but they can be disabled at any time. A structure must be enabled before it can be
used.
2.1.3. Segment Separator
This character is used to separate flexfield segment values or descriptions whenever the
application displays concatenated segment values or descriptions. The available values are

2.1.4. Cross-validation rules


The Cross-Validate Segments check box is selected if clients want to cross-validate multiple
segments using cross-validation rules. Cross-validation rules are used to define valid
combinations using the Cross-Validation Rules window. This box is unchecked if clients want
to disable any existing cross-validation rules. For a detailed discussion of cross-validation
rules in the context of the General Ledger key accounting flexfield, refer to the General
Ledger practice aid. The cross-validation concepts discussed there apply to other key
flexfields.
2.1.5. Freeze Rollup Groups
Used to indicate whether rollup group definitions are to be frozen. If this is enabled, users are
prevented from modifying rollup groups using the Segment Values form. Refer to the General
Ledger practice aid for more information on rollup groups.
2.1.6. Allow Dynamic Inserts
Dynamic Inserts are used for General Ledger Key Flexfield to allow dynamic insertion of new
valid account code combinations into the GL code combinations table. For more information
on Dynamic Insertion, please refer to the General Ledger Practice Aid.

2.2. Value Sets


Oracle uses the concept of segments (i.e. sub-fields) to determine the data structure and they want to
use and in what order they want them to appear. Value sets govern the type of content that can be
entered into a segment and what validation needs to occur for each segment.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 17 of 89

Note: This screen was modified with the addition of the usages button. The usages button is used to
view which flexfield segment or concurrent program parameter uses a particular value.
Please also consider the new color scheme Oracle has added.

2.3. Flexfield Segments


A segment is a single sub-field within a flexfield. They can also be thought of as "containers" for
segment values. Flexfield Segments can have two components, the segment definition and a
segment qualifier.
2.3.1. Flexfield Segment Definition
For a key flexfield, a segment's definition usually describes a particular characteristic of the
entity identified by the flexfield. In the accounting flexfield each segment is separated by a
hyphen and represents a different characteristic, in the screenshot below the different
segments are Company, Department, Account, Sub-Account, and Product.

Flexfield Segments

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 18 of 89

The following window is used to configure the number of segments, their appearance and
meaning as well as the validation of segment values, if required. In the example below, the
account segment is assigned a value set Operations Account which restricts the range of
values that can be defined for the account segment to a maximum size of 4 alphanumeric
characters.

Because the conditions specified for value sets determine what values can be used for them,
both value sets and values should be defined at the same time. For example, if values are
designed to be 6 characters long ranging from 000001, 000002 to 999999 instead of 1, 2, etc,
the value set would be defined to accept only values with Right-Justify Zero-fill set to Yes
and other validation parameters set accordingly as illustrated below.
2.3.2. Flexfield Segment Qualifiers
A flexfield qualifier identifies a particular segment of a key flexfield. Usually an application
needs some method of identifying a particular segment for some application purpose such as
security or computations. However, since a key flexfield can be configured so that segments
appear in any order with any prompts, the application needs a mechanism other than the
segment name or segment order to use for segment identification. Flexfield qualifiers serve
this purpose. Flexfield qualifiers can be thought of as "identification tags" for a segment.
For example, the Oracle General Ledger product needs to be able to identify which segment
in the Accounting Flexfield contains balancing information and which segment contains
natural account information. Since the Accounting Flexfield can be configured so that
segments appear in any order with any prompts, Oracle General Ledger needs the flexfield
qualifier to determine which segment is being used for natural account information. When an
Accounting Flexfield is defined, flexfield qualifiers that apply to each segment must be
specified as illustrated below.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 19 of 89

Other applications, such as Oracle Human Resources, also use flexfield qualifiers. Oracle
Human Resources uses flexfield qualifiers to control who has access to confidential
information in flexfield segments.

2.4. Flexfield Segment Values


There are 3 key concepts to consider regarding Flexfield Segment Values:

Definition of Segment Values

Segment Value Qualifiers

Segment Value Combinations


2.4.1. Definition of Segment Values
Segment values are individual values contained within the segment that further define the
segment definition. In the example below, Total Assets (account 1000), Cash (account 1110)
and Payroll Cash Accounts (account 1120) are individual values within the 'Account'
Segment:

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 20 of 89

2.4.2. Segment Value Qualifiers


A segment value qualifier identifies a particular type of value within a single segment of a key
flexfield. In the Oracle Applications, only the Accounting Flexfield uses segment value
qualifiers. A segment value qualifier can be thought of as an "identification tag" for a value. In
the Accounting Flexfield, segment value qualifiers determine whether detail posting or
budgeting are allowed for a particular value. In the example below, the Cash Account is
defined as an Asset account, and this value can be used in budgeting and posted
transactions.

It is easy to confuse the two types of qualifiers. A flexfield qualifier is used by the whole flexfield to tag
its pieces i.e. segments, and a segment qualifier is used to tag its values and is only applicable to the
Oracle General Ledger accounting flexfield.
Because the GL Accounting Flexfield is the only Oracle Applications key flexfield that uses the parent,
rollup group, hierarchy level and segment qualifier information illustrated above, clients need only
enter this information for values that are associated with the Accounting Flexfield. For more
information on such account hierarchies, refer to the General Ledger practice aid.

2.5. Control Considerations


Refer to each module's practice aid for control considerations pertinent to that's module's specific
flexfields.

3. Descriptive Flexfield Components


Descriptive Flexfields (DFFs) use the same concepts as Key Flexfields, including Structure,
Segments, and Segment Values. The difference with descriptive flexfield is that they use columns
that are added on to a database table. The table contains any columns that its entity requires, such
as a primary key column and other information columns. For example, a Vendors table would contain
columns for standard vendor information such as Vendor Name, Address, and Vendor Number. The
descriptive flexfield columns provide blank columns that you can use to store information that is not
already stored in another column of that table. A descriptive flexfield requires one column for each
possible segment and one additional column in which to store structure
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 21 of 89

Once the DFF's structure is defined, compiled and frozen, Oracle Applications submits a concurrent
request to generate a database view of the table that contains the descriptive flexfield segment
columns.
Descriptive flexfields have two different types of segments, global and contextsensitive, that you can
decide to use in a descriptive flexfield structure. A global segment is a segment that always appears
in the descriptive flexfield popup window, regardless of context (any other information in your form).
A contextsensitive segment appears when the appropriate context information is entered in a related
field.
The following screenshot illustrates a descriptive flexfield called Reconciliation Headers used to
capture additional data that would not normally be required in a journal entry window.

Note that fields in a descriptive flexfield pop-up window are also referred to as segments even though
they do not necessarily make up meaningful codes like the segments in key flexfields.

3.1. Control Considerations


Refer to each module's practice aid for control considerations pertinent to that's module's specific
flexfields.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 22 of 89

E. Auditing
Oracle EBS supports two fundamental methods of auditing -- activity-based auditing and data-based
auditing. Individually, these two methods provide only a partial picture of the activity or changes to the
system. Together, these two methods provide for a deeper understanding of the activity and changes to
the system. The AuditTrail: Activate system profile option is required to be enabled for Oracle-based
auditing to function. Even though many audit features might be configured, those features will not function
unless this profile option is enabled.

1. Oracle Auditing Methods


1.1. Activity Based Auditing
Activity-based auditing focuses on the actions by individuals or groups of individuals. Oracle EBS can
track the actions of users, including login activities and which forms have been accessed by users.
The system profile option Sign-On: Audit Level is used to support this method of auditing. Much like
other system profile options, this profile option can be set at the site, application, responsibility and
user level. The values for this system profile option are None, User, Responsibility and Form.
Level
Site

Application

Profile Option Value


None

Audit Trail Impact


No global auditing is enabled to track when users signon to the system.

User

Global auditing is enabled to track when users sign-on


to the system. The size of the audit trail is dependent
on the active user population.

Responsibility

Global auditing is enabled to not only identify when


users sign-on to the system but also the responsibilities
selected. At a minimum, the audit trail will be twice the
size of the audit trail created by selecting the value
user.

Form

Global auditing is enabled that identifies the forms /


screens the user accesses while signed on in the
system. The size of the audit trail created by this
setting (site/form) will be significant.

None / blank

No auditing is specifically enabled to track when users


sign-on to the system. Oracle will default to the sitelevel value.

User

Auditing for the specific application is enabled to


identify which users access that application through
any responsibility.

Responsibility

Auditing for the specific application is enabled to


identify which users and responsibilities access the
application.

Form

Auditing is enabled that identifies the forms / screens


the user accesses within the application. The size of
the audit trail created by this setting (site/form) will vary

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 23 of 89

Level

Profile Option Value

Audit Trail Impact


based on the application selected and the amount of
activity in that application.

Responsibility

None / blank

No auditing is specifically enabled to track when


responsibilities are accessed. Oracle will default to the
application and site-level values.

User

Auditing for the specified responsibility is enabled to


identify which users access that responsibility.

Responsibility

At the responsibility level, this setting appears to be


redundant with the User value.

Form

Auditing is enabled that identifies the forms / screens


the user accesses from within the responsibility. The
size of the audit trail created by this setting (site/form)
will vary based on the responsibility selected and the
amount of activity performed by that responsibility.

None / blank

No auditing is specifically enabled to track when a


specified form is accessed. Oracle will default to the
responsibility, application and site-level values.

User

Auditing is enabled that identifies which user access a


specified form.

Responsibility

Auditing is enabled that identifies which responsibility


via any user accesses a specified form.

Form

At the form level, this setting appears to be redundant


with the Responsibility value.

Form

1.2. Data Based Auditing


Oracle EBS also supports auditing based on changes to data. These features in Oracle are called
Audit Groups and Audit Tables. Standing or master data can be monitored to identify changes to
specific fields. Audit groups assist the administrator in managing the various Audit Tables being used.

1.3. Control Considerations


1.3.1. Business Process Variables
o
Oracle's auditing functionality is generally not enabled at clients because
it consumes significant computing resources.
o
A balance between monitoring too much and too little should be
established. Clients who have set Sign-On: Audit Level at the site level with a value of
Form is recording voluminous information that probably is not providing the audit or
control benefit intended. Clients using this setting have not performed a risk-based
assessment to determine the sensitive areas, users and responsibilities within EBS that
should be monitored.
o
For the most efficient auditing, a risk-based approach should be used to
identify the high risk transactions and/or users.
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 24 of 89

1.3.2. Control Dependencies


o
None
1.3.3. Control Limitations
o
None
1.3.4. Testing Notes
o
PwC staff reviewing Oracle-based auditing should consider the client's
requirements for monitoring. Oracle-based auditing should compliment those
requirements.
o
Additionally, PwC staff should consider the relationship between activitybased auditing and the data-based auditing that the client has enabled, if any.

2. Non-Audit based Change Control


Without the auditing feature turned on, Oracle only maintains a minimal audit trail. When auditing is
not enabled, only the record creation date, record creator and the record's last modification date are
recorded. Oracle does not automatically store any changes made between the creation of the record
and the last update, and Oracle does not record what data was changed during the last update (only
that the form was changed).
Because change control is not maintained within the application, it can only be controlled manually or
via a third-party application. Since a comprehensive list of changes to the application is not available
within the application; clients often use a third party tool to track versions and movement of the code.
Tools and controls used to support a change control environment could include:
Application versioning using tools such as PVCS from Serena, or Oracle Enterprise Manager
Change request / ticket management using tools such as Remedy from BMC.
Operating system security controlling access to production files and folders.
Server change monitoring tool such as Tripwire from Tripwire, Inc.
Oracle EBS: This audit trail only includes a time/date stamp and the user responsible for the last
update to the record. This audit trail will show a history of changes or the elements that were
changed, only when the last update occurred and who performed that update. Please see the
Auditing section in this Practice Aid for further information.
Related topics are the new file structure and the usage of iSetup. iSetup is a data management product
that helps in automating migration and monitoring of EBS setup data. iSetup helps in the migration of data
between different instances of the EBS functionality. However iSetup might not be used widely in the
marketplace, especially for this purpose.
iSetup is a two-part application:

iSetup Configurator runs on the web and provides an interactive questionnaire to capture an
organization's business requirements and configurations.
iSetup Migrator is the load functionality that populates the application setup tables with the
requested parameter values.

Configuration/Functionality Changes with iSetup


iSetup Migrator: Hierarchical Selection Sets

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 25 of 89

Hierarchical Selection Sets capture functional dependencies between items scheduled for
migration. iSetup is able to remember and enforce these dependencies when migrating
configurations / data.
Upload Extracts
New functionality includes the ability to upload an iSetup Extract from the users desktop. Once
uploaded successfully, the extract can be re- used for reporting or the load process.
Comparison Reporting
iSetup now allows user to compare the snapshot files. These snapshot files can be data from a
single instance across a timeline or from two different instances. Users can view the generated
report online or download the report in PDF, RTF or Excel format.

2.1. Control Considerations


2.1.1. Business Process Variables
o
None
2.1.2. Control Dependencies
o
None
2.1.3. Control Limitations
o
None
2.1.4. Testing Notes
o

None

F. End User Access


1. Responsibility and Security Group Management
Users having access to Oracle EBS only have access to application functionality through the use of
responsibilities. A responsibility is a collection of menus that are, in essence, navigation paths. Each
menu, or sub-menu, is a collection of Oracle forms (screens) and functions (transactions). In addition
to these application features, groups of programs are assigned to responsibilities via a request
security group. In version 11.5.10, responsibilities could be grouped together under roles. A role can
be configured to consolidate the responsibilities, permissions, function security and data security
polices that users require to perform a specific function. This is accomplished with a one-time setup,
in which permissions, responsibilities, and other roles are assigned to a single role. For more
information on Role Based Access Control (RBAC) refer to section 2.3 in this practice aid.
The following illustration identifies and briefly describes the elements required to create a
responsibility.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 26 of 89

Responsibility Name -- Unique


User-created name for the
responsibility
Application -- selected application
(module) in which the responsibility
resides
Responsibility Key -- User-created

*Effective Dates -- range of


dates between which the
responsibility is active.

Data Group -Name - Selected data group


for the responsibility. Note:
This element corresponds to
the security group on the
Users form.
Application - The module
used in conjunction with the
data group name.

Menu -- selected main


menu for the responsibility.

Menu Exclusions, Excluded Items,


Securing Attributes -- additional
configurable elements that further restrict
the responsibility's access

Request Group -Name - selected request


security group associated
with the responsibility
Application - The module
used in conjunction with the
specified request security
group.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 27 of 89

From a functional perspective, this would be indicated by:

Responsibility

Form
Function

Submenu Access

1.1. Forms and Functions


Menu Functions, or functions, are the lowest level of access. A function is a part of an application's
functionality that is registered under a unique name for the purpose of assigning it to, or excluding it
from, a responsibility. From an end-user perspective, the function is the window (or screen) in which
data is entered into the application.
Within Oracle There are two types of functions: form functions, and non-form functions. For clarity,
Oracle refers to a form function as a form, and a non-form function as a sub function, even though
within the database, both are just instances of functions.
Within PwC's GATE tool, a form function is called a form, and the non-form function (or sub function)
is called a function. Together, these two values form the navigation path to the screen in which data is
entered. For example, invoices can be entered into the Invoices (form)>Invoices (function) screen or
via Invoices (form)>Invoice Batches (function).
Forms and Functions are defined within the System Administration module with the following
characteristics.
1.1.1. Description
o Function: Users do not see this unique function name. However, this may be used
when calling your function programmatically. Also known as the "database name".
o User Function Name: This name appears in the end users Navigator window. This
name is also used when assigning functions to menus. Within PwC's GATE tool, this
name is called the "function".
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 28 of 89

1.1.2. Properties

o Type: Type is a free-form description of the function's use. A function's type is passed
back when a developer tests the availability of a function. The developer can write code
that takes an action based on the function's type. Standard function types include the
following:

Form Type
FORM
SUBFUNCTION
JSP
WWW or WWK
WWR or WWL
WWJ

Description
Oracle Applications form functions are registered with a type of FORM. Even if it
is not register a form function with a type of FORM, Oracle Applications treats it
as a form if a valid Form Name/Application is specified.
Sub functions are added to menus (without prompts) to provide security
functionality for forms or other functions.
Functions used for some products in the Oracle Self-Service Web Applications.
These are typically JSP functions.
Functions used for some products in the Oracle Self-Service Web Applications.
These are typically PL/SQL functions.
Functions used for some products in the Oracle Self-Service Web Applications.
OA Framework JSP portlet.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 29 of 89

Form Type
SERVLET

Description
Servlet functions used for some products in the Oracle Self-Service Web
Applications.
Database provider portlet.
Web provider portlet.

DBPORTLET
WEBPORTLET

o Context Dependence: Some functions are controlled by profile options that affect what
the user can perform within the current context. Types of context dependence are:
Context
Responsibility
Organization
Security Group
None

Description
The function is controlled by the user's responsibility (RESP_ID/RESP_APPL_ID
(includes ORG_ID)).
The function is controlled by the user's organization (ORG_ID).
The function is controlled by the user's security group (service bureau mode)
There is no dependence on the user's session context.

1.1.3. Form

o Form/Application: This field is where the function is linked to a form. In the PwC GATE
tool, this value is referred to as the "form".
o Parameters: Parameters determine is a form is query only or entry. For a form function,
if the parameter is QUERY_ONLY=YES, the form opens in query-only mode.
1.1.4. Web HTML, Host and Region.
The fields in the Web HTML and Web Host are only required if your function will be accessed
from Oracle Applications Framework. Values are not required here if the functions are based
on Oracle Forms Developer forms. The Region section's fields are for future releases of
Oracle.

1.2. Menus
A menu is a hierarchical arrangement of functions and menus of functions. Functions are assigned to
menus, which can in turn be assigned to one or more menus. Finally, menus are assigned to
responsibilities, and those responsibilities to specific users. Menus are composed of the following:

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 30 of 89


Sequence: Specifies where a menu entry appears relative to other menu entries in a
menu. A menu entry with a lower sequence number appears before a menu entry with a higher
sequence number.

Navigator Prompt: This is a user-friendly, intuitive prompt the menu displays for the
menu entry. End users see this menu prompt in the hierarchy list of the Navigator window.

Submenu: Links another menu to the menu and allows end users to select menu
entries from that menu.

Function: A function included in the menu. A form function (form) appears in the
Navigate window and allows access to that form. Other non-form functions (sub functions) allow
access to a particular subset of form functionality from this menu.

Description: Appears in a field at the top of the Navigate window when a menu entry is
highlighted.

Grant: If enabled, this function is automatically enabled for the user. If this is not
checked then the function must be enabled using additional data security rules.
Note: Oracle uses the term "submenu" to define any menu that is assigned to another menu.
However, there is no technical distinction between a menu and submenu. However, a submenu must
be defined before it can be called by another menu.
Custom menus can be created using predefined forms (i.e., form functions) and their associated
menus of sub functions. However, Oracle does not recommend that a form be disassociated from its
developer-defined menus of sub functions.
Outlined below is a graphic illustration of how menus are compiled:

The function "invoice actions" is assigned to the AP_APXINWKB submenu.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 31 of 89

The AP_APXINWKB Menu is assigned to the AP_INVOICES_ENTRY_GUI12 Menu.

menu.

The AP_INVOICES_ENTRY_GUI12Menu is assigned to the AP_INVOICES_GUI12

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 32 of 89

The AP_INVOICES_GUI12 menu is assigned to the AP_NAVIGATE_GUI12 menu.

The AP_NAVIGATE_GUI12 menu is assigned to the Payables Manager Responsibility.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 33 of 89

Because of all the submenus attached to the AP_NAVIGATE_GUI12 menu, the Payables Manager
can enter data into the Invoice Actions function.

However, there is an additional method by which users can be assigned functions - permission sets.
Permission sets are granted independently of responsibilities and can be used to augment access
assigned through responsibilities. A permission set is a grouping of functions that can be assigned
directly to a user through permission assignments, or grants. Because permission sets are granted
independently of responsibilities, they can potentially increase the risk of SoD conflicts.

1.3. Request Groups


Oracle EBS requests not only include paper-based reports but also other programs that perform
transactions such as automatically creating invoices. Requests are grouped and assigned to
responsibilities via Request Security Groups. Common to Oracle EBS is the use of the "All Reports"
Request Security Group for each module. This default or seeded request security group contains all
reports/updateable programs defined in the system.

1.4. Process Navigator Tab


The first tab on an Oracle EBS form is the Functions tab. This feature contains the menus and
navigation paths to the various forms and functions granted to the responsibility. The Functions tab is
where users (end users and support personnel) spend a majority of their time.
The Process Navigator Tab within Oracle is a little-used feature that presents a heightened risk of
segregation of duties and sensitive access violations by indirectly granting access not intended for
specified users and not intentionally designed into their responsibilities. This Oracle feature is
intended to give the user an overview of a business process and walk them through each step. This
feature also allows support individuals a better view of the transaction and where problems might
exist during troubleshooting exercises.
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 34 of 89

The next two examples will show how the Application Developer responsibility, that does not have
access to transactions in the Functions tab, will have access to many different sensitive and
conflicting functions through the Process Navigator Tab.
Example 1: Application Developer access to purchase order processing
The Process
Navigator Tab is an
optional 3rd tab on the
primary transaction

By launching this
node of the process,
users can create and
approve purchase
orders.

Example 2: Application Developer access to vendor management, invoice and payment processing

The 1099 Reporting process


assigned to Application
Developer by default gives the
user the ability to:
create vendors,
process invoices, and
process payments.
Launching these specific nodes
of the process will display the
appropriate forms to enter the
transaction.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 35 of 89

1.5. Control Considerations


1.5.1. Business Process Variables
o Clients should have a defined process for developing and updating responsibilities. A
balance between flexibility and segregation of duties should be established.
Responsibility design focused solely on responsibility functionality and flexibility will
introduce conflicting and excessive access. Responsibility design focused solely on
segregation of duties might increase the cost of performing transactions. This increased
cost is due to the additional time introduced into the business process to separate
conflicting activities.
o Clients should not use seeded or default responsibilities in the production environment.
The responsibilities shipped with Oracle provide excessive and conflicting access to
users. Clients tend to copy seeded or default responsibilities in order to develop new
ones. The risk introduced in this method of creating responsibilities is that weaknesses in
one responsibility will be re-introduced in the new responsibility. For example, the
Process Navigator Tab is enabled for many seeded or default responsibilities and will be
enabled in new responsibilities unless the client actively manages this feature. Please
refer to the Process Navigator Tab section in this Practice Aid for further discussion on
this Oracle feature.
o An additional argument for not using seeded responsibilities (and even forms) is to
support upgradeability. Upgrades and patches to Oracle EBS will frequently overwrite
seeded functionality. This process "resets" seeded responsibilities and menus to their
original configuration. Clients that modify the seeded responsibilities and menus for
increased security will lose these customisations and will increase their risk of
unauthorised activity being performed in Oracle EBS.
o The presence of the Process Navigator Tab does not necessarily represent a control
deficiency in the client's environment. Better control practice is that the Process Navigator
Tab is not enabled in any responsibility. Processes available to the responsibility can be
added and removed.
1.5.2. Control Dependencies
o None
1.5.3. Control Limitations
o Because some concurrent processes (auto post journals, revenue recognition)
manipulate financial data, access to concurrent processes (reports) should be assigned
to complement the online access granted to responsibilities. Clients should not use the
"All Reports" request security group, as it contains all reports and processes, of which
access could pose an increased risk of excessive access and segregation of duties
violations.
o The functionality of a responsibility is independent of the naming convention of that
responsibility. Responsibilities named 'view' or 'inquiry could actually update and initiate
transactions. Clients should follow an appropriate naming convention so that effective
responsibility management can be supported.
1.5.4. Testing Notes o To test Security Groups using GATE: Run the GATE Responsibility Report
"Responsibilities by Request Groups" to identify the various request security groups
defined and to which responsibilities they are assigned. Additionally, run the report
"Reports within Request Groups" to identify which reports are associated with each
request security group. A specific report focusing on the "All Reports" request security
group is also available -- "All Reports Request Group"
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 36 of 89

o To test Security Groups using online testing: Effective online testing of reports and
request groups has not been identified. There is an Oracle report titled "Reports and
Sets by Responsibility" that identifies which reports, programs, and request sets are
included in a request security group available for a given responsibility. To run the report,
you must have the Application and Responsibility names you want to analyse.
o To test Process Tab access using Oracle GATE Responsibility Reports: PwC should
run the GATE report "Responsibilities with the Process Tab" to determine whether the
process tab is enabled throughout the client's environment.
o To Process tab access using Manual Testing -- An effective way for testing the AZN
menus by reviewing online in the client's system has not been identified. PwC should be
aware of this feature and, when they identify its use, should work with the client to identify
where it is being used. The database administrator should be able to identify the "AZN"
menus and potentially the responsibilities with which they are associated.
o Function and menu exclusion rules should be defined to restrict the application
functionality accessible to a responsibility.
o GATE does not pick up menu exclusions and therefore online testing is required in a
recent copy of PROD.

2. User Management
2.1. Defining Users
Entry and maintenance of users is completed in the User form, whose navigation path is Security /
User / Define menu path. When creating a new user ID, the following can be entered:

2.1.1. User Name (required)


This is a freeform text field in which the clients can enter a value. Oftentimes companies use
standard a naming convention to link the Oracle user name to the individual (jsmith, etc). This
is the user name the end users will enter when accessing the Oracle application.
2.1.2. Password and Password Expiration (required)
The password entered in the password field is a temporary password which will expire upon
first use. Once the user logs into the application for the first time, they will be required to enter
a new "permanent" password.
In addition, a user can be set up with a password expiration date that is used with the
"permanent" password. (For more information regarding passwords, refer to the Password
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 37 of 89

Management section of this practice aid.) Note: the option to set password expiration to
"NONE" will result in the user's password to never expire
2.1.3. Person (optional)
An Oracle user name can be linked to a person (employee) listed within the HR tables. This is
done by selecting a value in the person field. This is not required, as some users may need
access who are not employees (temporary workers, external suppliers, etc). However, some
functionality (workflow, purchasing) requires that a User Name have a person assigned to the
User record.
2.1.4. Supplier and Customer (optional)
An Oracle user name can also be linked to a supplier or customer as defined in the supplier
and customer master, respectively. This can be enabled in order to facilitate external supplier
and customer access to the application (refer to the Procure to Pay and Oracle to Cash
practice aids for more information).
2.1.5. Effective Dates (required)
When user accounts are created, effective dates control when the User ID is active. The
security administrator will supply an end-date to disable the User ID. This date can be in the
future so that the User ID is disabled at a predetermined time.
2.1.6. Direct Responsibilities
In order for a user to access the application, a responsibility needs to be assigned to a user.
The same Users form (identified above) is used, and the security administrator will select a
responsibility from the active responsibilities defined within the responsibilities table. The
security group automatically assigned to the user, based upon the responsibility selected.
When Responsibilities are removed from users, those responsibilities are "end-dated". The
effective to date indicates which date the Responsibility is no longer valid for the user. These
dates can be in the future, so that users, such as temporary users or contractors, will have
their access removed automatically on a certain date.
For more information on Responsibilities and Security Groups, refer to the Responsibility
section of this practice aid.
2.1.7. Indirect Responsibilities (new to 11.5.10)
A user may "inherit" an indirect responsibility through membership in a group to which the
responsibility has been assigned. Indirect responsibilities are used with Oracle User
Management only.
2.1.8. Securing Attributes
Securing attributes are used by Oracle HTML-based applications (Self Service) to allow rows
(records) of data to be visible to specified users or responsibilities based on the specific data
(attribute values) contained in the row. Essentially, self-service users can be limit or to add to
the information they see by assigning security attributes to their user record. For example,
Employee "A" can be assigned to securing attributes for Oracle iExpense for Employee "B".
When employee A logs onto the iExpense, they can choose to enter expenses for either
themselves or for employee "B".
2.1.9. MOAC
The Multiple Organization Access Control (MOAC) is a new functionality with R12. Using the
new MOAC functionality, users can access multiple operating unit (OU) data either within or
across business groups from a single responsibility. Using MOAC, multiple operating units
are assigned to a security profile. This security profile is then assigned either to
responsibilities or directly to users.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 38 of 89

2.1.10. Personalisation
The personalization functionality is accessibly for end-user via the diagnostic functionality.
The objective of personalization is to declaratively tailor the user interface (UI) look-and-feel,
layout or visibility of page content or a user preference. Personalization examples are:
Tailor the color scheme of the UI.
Tailor the order in which table columns are displayed.
Tailor a query result

2.1.11. Usage of roles


With Release 12, the usage of roles is widened. Please compare for the implication the
chapter about Role Based Access (RBAC). Oracle EBS users can also maintain user
functionalities like role assignment and functionalities as role inheritance through the usage of
the user Management Module. This might mainly used for the maintenance of Roles.
However maintenance features like reset of passwords or end dating of users can be done
via this module.

2.2 Proxy users


Functionality for management of the Proxy Users has been introduced covering the following
functions:
o Setting up Proxy Users
o Delegating Proxy User Privileges
o Acting as a Proxy User
o Running the Proxy User Report
2.2.1 Usage
There are a number of business scenarios in which users of Oracle EBS need to grant
delegates the ability to act on their behalf (act as proxy users for them) when performing
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 39 of 89

specific EBS functions. The new mechanism was designed to enable limited, auditable
delegation of privilege from delegators to their delegates.
2.2.3. Examples of Delegation
Executives allowing their assistants to access selected business applications on their behalf
Similarly, but for a more limited duration, managers may need to grant peers or subordinates
limited authority to act on their behalf while they are out of the office
Users may need to grant help-desk staff limited duration access to their EBS accounts, so
that help desk staff can investigate problems and provide assistance. The Proxy User
mechanism allows such users to obtain limited, auditable access to accounts such as
SYSADMIN that might otherwise have to be shared and therefore harder to audit.
The ability for users to access the proxy feature is controlled by a Security Administrator role.
Users with this role determine which set of users can create delegates who can act on their
behalf. Following screenshots depicts the functionality. The first picture shows how to assign
proxies as a separate role and then how to run the report in the user management module:

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 40 of 89

2.3 Role Based Access (RBAC)


In Oracle EBS 11.5.10 (and earlier with patch FND.H installed), the concept of roles is introduced.
Roles are a grouping of access rights at a level higher than responsibilities. Responsibilities cannot
be assigned to responsibilities; however, roles can be assigned to roles, and responsibilities can be
assigned to roles. Roles provide the client tools to better align access to the functional job
responsibilities of their employees.
2.3.1. RBAC Functionality
The user's ability to view, edit and perform certain actions on an object is determined by the
user's role on that object. Roles are granted to users by the owner of the object, or by
someone who has the privilege to add people. A role is a collection of privileges. Roles are a
convenient way to group privileges into a bundle that can later on be assigned to users. Roles
are object-type specific. For example, the role Item Reviewer contains the privileges View
Item and View Item People List. The user can give this role to various people on individual
item instances, and they can in turn view item and view item people list.
RBAC is a layer that builds upon the data and function security models of previous releases

tive
a
r
t
s
i
n
Admi dures
proce

Core
ity
secur

rovals
p
p
a
ic e &

rv
Self se
ices
v
r
e
s
ioning
ration
t
s
Provis
i
n
i
d Adm
e
t
a
g
e
Del
ion ontrol
t
a
r
t
s
i
Admined access c
as
Role b
ecurity
S
a
t
a
D
curity
e
S
n
o
Functi

ity
Secur

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 41 of 89

Role Based Access Control (RBAC) is an ANSI standard (ANSI INCITS 359-2004) supported
by the National Institute of Standards & Technology (NIST). To consolidate the
responsibilities, permissions, function security and data security polices that users require
performing a specific function
Roles can be included in role inheritance hierarchies that can contain multiple subordinate
roles and superior roles. With role inheritance hierarchies, a superior role inherits all of the
properties of its subordinate role, as well as any of that role's own subordinate roles. The
following example illustrates this:

In this example, some roles such as "Employee" or "Manager" are assigned general
permissions for a given function. For example, the Employee role may provide access to
menus generally available to all employees, while the Manager role provides access to
menus that should only be accessible by managers. Because the Employee role is to
subordinate to the Manager role, anyone assigned the Manager role automatically obtains the
permissions associated with the Employee role. Other roles in this example pertain to more
specific job functions, such as Sales Manager and Sales Representative, or Support Manager
and Support Agent. These roles may provide access to job-specific menus and data such as
the Sales Forecasting menu, or the Support application. Hierarchies within the roles
functionality is granted via the Oracle user management application.
Responsibilities are also a type of role and the same principal with regards to inheritance
hierarchies as detailed above applies to responsibilities. When responsibilities are structured
in the form of a hierarchy, assigning the top level responsibility to a user will result in all
inherited responsibilities also being automatically assigned to the user. One of the effects of
this is that if the top level responsibility assignment is end-dated for a specific user, all lower
level responsibilities will also be end-dated. When this occurs it has the effect that it will not
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 42 of 89

be possible to directly assign any of the lower level responsibilities to the user without either
dismantling the hierarchy or assigning the top-level responsibility to the user again.
2.3.2. Supporting functionality: Delegated Administration
Delegated Administration is a privilege model that builds on the RBAC system to provide
organizations with the ability to assign the required access rights for managing roles and user
accounts. With delegated administration, instead of relying on a central administrator to
manage all its users, an organization can create local administrators and grant them sufficient
privileges to manage a specific subset of the organization's users and roles. This provides
organizations with a tighter, more granular level of security, and the ability to easily scale their
administrative capabilities. For example, organizations could internally designate
administrators at division or even department levels, and then delegate administration of
external users to people within those (external) organizations. Delegation policies are defined
as data security policies. The set of data policies that are defined as part of delegated
administration are known as Administration Privileges.
The administrative privileges that can be delegated could be of the following privilege
categories:
o User Administration Privileges
o Role Administration Privileges
o Organization Privileges
Delegation policies are defined as data security policies. The set of data policies that are
defined as part of delegated administration are known as the Administration Privileges.
Administration Privileges determine what users and roles the delegated administrator can
manage. There are three aspects to administration privileges: roles, users, and organization.
Each privilege is granted separately, yet the three work together to provide the complete set
of abilities for the delegated administrator. These privileges can be defined along with the role
definition in the Role & Role Inheritance user interface in Oracle User Management.
See the following screens in the user management module, where you can see the search
function and an example of a delegated administration function.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 43 of 89

Example of delegated administrative functionality how it is assigned within the role


administration

2.4. User management tool


The functionality was established in the version 11.5.10, but was not mentioned in the Practice aid.
2.4.1. Self-Service Account Requests
Commonly referred to as Self-Service Registration, self-service account requests provide a
method for individuals to request a new user account. Consider a case where customers may
need to register before they can purchase an item from an online store.
Once the registration process has been completed, the customer obtains both a user account
and the necessary role(s) for accessing some portion of the web site in which they registered.
This release of Oracle User Management provides sample Self-Service registration UIs for
internal employees, and for new, external individuals. Organizations can copy these sample
Self-Service registration and extend them based on their own requirements. In addition,
organizations that wish to support other types of users, or capture additional information
specific to their applications, are able to extend or create their own registration UIs and
business logic.
Oracle User Management provides support for displaying different registration links on the
login page based on the application tier login page that provides access. The registration link
can contain additional parameters that are not known at design time, such as the country
code. These additional parameters can be used later during the registration process. Using
country code as an example, a registration process could route the approval requests to the
most appropriate approver. Therefore, all those who request an account from Norway could
be routed to a Norwegian account approver.
2.4.2. Request for additional access
Users can request additional access through the Oracle User Management Access Request
Tool (ART), available in the Global Preferences menu. Requests for additional access use
the same Oracle User Management infrastructure and processing logic as Self Service
Account Requests.
2.4.3. User Name Policies
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 44 of 89

Oracle User Management enables organizations to define their own user name policies for
new users. These can include such formats as email address, "firstname.lastname" (or an
abbreviated version), employee number, social security number, or some other meaningful
information. When the account request is submitted, Oracle User Management reserves the
specified user name for the duration of the approval process. Oracle User Management ships
with a default user name policy that identifies users by their email address. This is
implemented as a configurable infrastructure that organizations can easily customize to suit
their specific needs.
2.4.4. Email Verification
Oracle User Management provides a mechanism for verifying the identity of the requester
before the registration request is processed. Identity verification is based on the email
address provided by the requester. Oracle User Management sends the requester an email
notification when the requester has completes the registration flow. If the user does not reply
to the email notification within a specified time, the request is automatically rejected. Email
verification is only applicable to Self-Service account requests, and is enabled or disabled for
each registration process.
Note: Oracle recommends that when building self-service registration UIs with identity
verification enabled, an organization should indicate in the UIs and confirmation messages
that a response is required to process the user's request.
2.4.5. ICM Integration:
Functionality for integration of the role assignment and revocation processes with Oracle
Internal Controls Manager is described below:
Oracle User Management is now integrated with Oracle Internal Controls Manager (ICM) for
the prevention, detection, enforcement, and resolution of separation-of-duties constraints
during the assignment of roles by administrators to users. ICM is used to document and test
internal controls and monitor ongoing compliance. The application assembles the
components necessary to document, test and monitor internal controls and compliance. It
provides a workbench for managing tasks like define the business processes of the
enterprise, manage process documentation, manage the process Risk Library,
For example, a constraint (created using a set of ICM UIs) can be defined such that no user
is allowed to have "Role A" and "Role B" at the same time. In such a case, an administrator
attempting to assign Role B to a user who already has Role A will be presented with a dialog
page displaying the constraint violation information.
At this point, the administrator can take one of two actions:
o
o

Go back to the role assignment page and remove the assignment that is
causing the violation.
Override the constraint violation, if he has the "AMW: Allow SOD Violation
Override" permission granted to him. With this permission, the administrator
will see Apply and Cancel buttons on the constraint violation dialog page.
Clicking Apply will override the constraint, and assign Role B to the user
despite the warning. Clicking Cancel will cancel the save operation without
granting Role B to the user. UMX integration with ICM is enabled according
to the setting of site-level profile option "UMX: Enable ICM Validation". The
default value is "Yes".

2.5. Control Considerations


2.5.1. Business Process Variables
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 45 of 89

o
Security may be administered in a centralized or decentralized manner.
Each method has its own risks.
o
User Administration (creating/disabling user IDs and assigning access)
should be separate from business process transactions and responsibility design activities.
o
A user can be assigned multiple responsibilities and responsibilities can
be assigned to multiple users
o
Oracle EBS is highly configurable and any responsibility (even seeded
responsibilities including General Ledger Super User) can be modified.
o
Responsibilities cannot be deleted from a users profile, but they can be
end-dated to have the users access disabled.
o
Two responsibilities can be assigned to a single user that when
combined may create a SoD violation.
o
Clients might use the registration process that comes with Oracle user
management application as there are individual user registration, external organization
contact and employee registration, and the account creation for an existing person. These
registration processes create role assignments.
o
Clients using the roles concept must monitor the granting process for role
inheritance.
o
Enabling proxy users allow business process owners to delegate
responsibility, and therefore might grant function excessively or inappropriately resulting in
SoD violations.
2.5.2. Control Dependencies
o
Oracle General Ledger, Projects, and Human Resources have additional
security methods that may restrict a user's ability to view and update data. Please refer to
these Practice Aids for more information.
o
Whenever a role concept is followed, it should be thoroughly considered
that the roles and responsibilities do not represent a SoD conflict.
o
Proxy User functionality gives all-or-nothing delegation capability.
However, start and end dates can be defined to limit the duration of proxy access.
2.5.3. Control Limitations
o
If a proxy user access is given, this might violate the existing SOD and
cause a possible conflict, which would not haven been there without this proxy given.
2.5.4. Testing Notes
o Securing Attributes could be a significant security component of the client's user
population if iTime, iExpense, or iProcurement are used. PwC should understand the
requirements for securing attributes and consider testing those configurations.
o Appropriately completed authorisation request forms should accompany any
additions/changes to a user ID. This authorisation form should clearly indicate the specific
Oracle access (e.g., which Responsibility) that should be granted. Periodic review by
management of all active users and their currently assigned Responsibilities should occur.
o Monitoring controls over Roles, Responsibilities and user assignment throughout the
period should be used to understand the nature of any temporary changes to these
elements.
o Companies may create a specific user (the auditor) access to employees' EBS
accounts, normally on a read-only basis.
o Accessing the granted proxy users enables the auditor to analyze the usage of
delegated responsibilities (usage of the proxy user report). Overall proxy user related
privileges should only be granted on exceptional basis.
o Analyze the overall concurrence of RBAC, MOAG and the proxy user.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 46 of 89

3. Password Management
Oracle EBS provides multiple configurations to support the client's corporate security policy. The
Oracle E-Business suite password configurations are as follows:
Configuration Name
Sign on Password
Custom

Type of
configuration
System
Profile Option

Default
Setting
not set

Description

Sign on Password
Failure Limit

System
Profile Option

not set

This parameter setting identifies the number of


failed login attempts after which an EBS login is
disabled. The default is unlimited failures. Note:
This profile option became available in Release
11.5.7 or via patch 2061872.

Sign on Password
Hard to Guess

System
Profile Option

not set

The profile option Sign on Password Hard to


Guess is used to help ensure that the password
is "hard to guess." A password is considered
hard-to-guess if it follows these rules:
The password contains at least one letter
and at least one number.
The password does not contain the
username.
The password does not contain repeating
characters.

Sign on Password
Length

System
Profile Option

The minimum length of Oracle EBS user


passwords can be set using the profile option
Sign on Password Length.

Sign on Password No
Reuse

System
Profile Option

not set

The minimum number of days that a user must


wait before being allowed to reuse a password
can be set with the Sign on Password No Reuse
profile option.

Password Expiration

User Record

not set

Days - the number of days between password


changes
Accesses - the number of successful logins
until the next password change

Password case
sensitivity

Profile option

disabled

Passwords are either case sensitive or not case


sensitive

If the client has more advanced password


restrictions, custom Java classes can be used to
implement these restrictions. The Sign on
Password Custom profile option must be set to
be the full name of the java class.

Functionality for Login Assistance self service has been introduced in place of the Forgotten
Password administrative function.
It is not uncommon for system administrators to have to reset a user's forgotten password, or even
advise a user of the account's user (login) name. This is unproductive for both the user, who cannot
do any work in the meantime, and for the administrator. In addition, a user will occasionally request

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 47 of 89

the password to be reset, when it is actually the user name that has been forgotten, or vice versa.
This type of occurrence leads to even more time being lost.
A new feature reduces the time spent in such administrative activities by implementing a login help
mechanism that is easily accessed from the EBS Login Page. A user simply clicks on the "Login
Assistance" link located below the Login and Cancel buttons.
On the screen that appears, you can either:
o Go to the Forgot Password section, enter the correct user name and then click on the
"Forgot Password" button. You will then be emailed details of how to reset your password.
o Go to the Forgot User Name section, enter the email address associated with the
account, and click on the Forgot User Name button. The user name will then be emailed to
the address specified.
For security, the relevant data is stored securely in workflow tables, and the URLs employed have
both an expiration time and a single-use limitation.
The identity verification process required in previous Applications releases is no longer needed.
Instead, a link to a secure page is sent to the email address of the user name defined in the system.
From this secure page, the user can change password immediately.
Most of these configurations are profile options, set at the site level. However, the password
expiration is set for individual users. Refer to the controls consideration section for details on how this
may affect the review of the Oracle environment.

3.1. Control Considerations


3.1.1. Business Process Variables
o Not all password configurations are required to be used. Strong company security
policies will generally require password controls that are met by using all of the password
configuration settings in Oracle with the exception of "Signon Password Custom". This
password option has the potential of replacing one or more of the other password
options. If this configuration is used, a good understanding of its features is suggested.
o Password expiration parameter is associated with each user record; therefore,
consistency for enforcing password changes is not supported in Oracle. This flexibility
does allow the client to risk rate different users and require more or less frequent
password changes based on the user's functional job responsibilities For example, an
inquiry clerk ID might not have any password changes enforced; but an HR manager
having access to sensitive employee records might be required to change the password
every 30 days. Regardless of the client's approach, the approach for implementing
password parameters should be consistent.
3.2.2. Control Dependencies
o If Single Sign On (SSO) functionality is enabled, this will influence the password
management in the Oracle EBS.
3.2.3. Control Limitations
o Oracle has a known weakness with regards to the strength of the encrypted
passwords. The process that Oracle uses to encrypt the passwords can be reverseengineered resulting in the original clear-text password being disclosed. A compromise of
any database account will compromise the APPS ID or any other sensitive database
account. Clients tend to clone their production environment so that they may conduct
application development and testing. If passwords are not changed when the production
instance is cloned, individuals may be able to obtain PROD passwords within the test and
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 48 of 89

development environments. If the system passwords are the same in a non-production


environment as they are in production, then a compromise in one of these lower security
environments will significantly increase the risk of a compromise in the production
environments.
o Usage of SSO limits the existing Oracle EBS password management. Where a SSO
solution is used, the Oracle EBS password related profile options setting might be
overridden by the password setting in the SSO application.
3.2.4. Testing Notes
o The password weaknesses and control considerations discussed in this section are
applicable to the EBS but are found in the Oracle database. This issue should be
addressed during a database review performed in conjunction with the Oracle EBS
review.
o The goal is to limit access to the FND_USER table and the encrypted passwords, just
as should be done with DBA_USERS. This can be accomplished by:
Verifying the account APPLSYSPUB does not have SELECT privileges on
APPS.FND_USER_VIEW.
Ensuring the client has changed the passwords for all Oracle Applications 11i
seeded accounts (SYSADMIN, GUEST, WIZARD, APPSMGR, etc.) even though
these accounts may be already disabled.
Ensuring all seeded / default accounts, except for SYSADMIN and GUEST, are
disabled.
Ensuring the client has created all new user accounts with strong and unique
passwords.
Ensuring the client has limited access to the APPLSYS.FND_USER and
APPLSYS.FND_ORACLE_USERID tables by all non-DBA accounts including any
query-only accounts. Often an APPSREAD or similar database account is created for
support purposes or end-user query use. These accounts tend to be created with
SELECT ANY TABLE system privilege, which allows them access to FND_USER.
Ensuring the passwords for Oracle EBS accounts are unique across each of the
environments used in change control.

4. Identity Management
4.1. Identity management with non Oracle ERP`s
In many environments, Oracle might not be the only application used. Large companies could easily
have multiple ERP`s or other systems in place to support its businesses. In these situations, an
Identity Management ("IdM") solution could be used as the central point of creating, updating and
disabling users. Identity management is the process by which an employee is identified and managed
consistently through each of the applications in use at the company. An IdM solution involves five
basic components:
Directory services focuses on providing a common view of an individual regardless of what
databases and applications (and associated user IDs) to which that individual has access.
Access control involves providing a common mechanism for allow/denying access to
applications at the company.
User management involves providing a common mechanism throughout the company of
creating user accounts, managing the access granted to those user accounts, and then disabling
those accounts.
Workflow is the business logic enabled that provides for the approval process and other
notification activities required maintaining user accounts.
Provisioning is the process of automatically maintaining user records in various applications,
databases and operating systems that require their own internal authorisation mechanism as part
of the overall IdM environment.
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 49 of 89

User Creation and


Provisioning should be
sourced at the IdM solution

System 1

Users

Responsibilities

p
ers
rou
Us
sG
ce s
Ac

Us
Ac
ers
ce
ss
Gro
up

IdM

Oracle ERP

Technical and /or monitoring


controls should be enabled
to promote user creation and
assignment from the IdM
solution

System 2

4.2. Identity management within Oracle EBS


Oracle EBS as part of the overall Oracle identity management framework can be considered as
one additional application to be included. In principle users created in Oracle EBS are provisioned
to OID (and vice versa). The Oracle EBS has to be registered as an instance to the OID. In
addition there are some profile options (see profile options list), which have to be enabled and
some workflow events must be activated, for the process from OID to Oracle EBS.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 50 of 89

It is important to understand how the login and synchronization process works. Here is a brief
description for the simplest cases. Please see the main documentation for more details.
A. Authentication Phase: Validating a user's identity
User attempts to access a protected page from Oracle Applications Release 12. User is redirected
to Single Sign-On Server site. Single Sign-On Server verifies if user is already authenticated
(validates the cookie SSO_ID presented to this site). If user is not authenticated Single Sign-On
Server displays a login page requesting a user name and password. Single Sign-On Server verifies
the credentials against Oracle Internet Directory. The login page will continue to be presented until a
valid username and password are provided. Once the username and password have been
authenticated, Single Sign-On Server creates or updates the SSO cookie, and redirects the browser
to a predetermined Oracle Applications Release 12 page. Along this request, encrypted and signed
information regarding the authentication (user name for example) is sent in the redirect. Only the
receiving site can decrypt it. If the decrypted information is valid, Oracle Applications Release 12
will create an application session (reflected in the session cookie named <sid>_<host>). The
browser is redirected to the original requested page.
B. Synchronization Phase: From Applications to OID
In Applications, user information is propagated to OID using DBMS_LDAP commands
Profile values are checked to verify that the user should be propagated to OID If all checks pass the
changes are made to the user in OID.
C. Synchronization Phase: OID to Applications
When a change is made in OID, the change vector is stored (changeLog). When the DIP server
wakes up, it will scan the new changeLog and will filter them using the provisioning profiles. For
changes that are first in the profile, the DIP server will connect to the Applications database and will
use a WF interface (WF_OID) to raise corresponding WF events. Later the WF Agent will process
and implement the events.
Source: Oracle note ID380487.1

However with the usage of the new RBAC functionality, there might be enhanced usage of
provisioning within Oracle EBS. Therefore new functionalities are introduced in the new version
R12.
Provisioning services are modelled as registration processes that enable end users to perform
some of their own registration tasks, such as requesting new accounts or additional access to the
system. They also provide administrators with a faster and more efficient method of creating new
user accounts, as well as assigning roles. Registration Processes create Role Assignments,
which are equivalent to RBAC policies, as these Role Assignments control the actions or access
for a user.
Introduction of User Management: Security Administration Set Up Wizard for performing the
following system administration functions:
o Defining User Administration Privileges for Roles
o Defining Role Administration Privileges for Roles
o Defining Organisation Administration Privileges for Roles
The functionality of Administrator assisted request for additional access is added as the fourth
type of user registration process.
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 51 of 89

Addition of the new field Business Event Name in the user registration process to record the
custom business event that will be raised by Oracle User Management with context information
for processing.

4.3. Control Considerations


4.3.1. Business Process Variables
o None
4.3.2. Control Dependencies
o None
4.3.3. Control Limitations
o None
4.3.4. Testing Notes
o When IdMs are in use, the practitioner should understand to what degree the IdM
solution affects the Oracle Applications and the user provisioning process.
o When IdM is used, controls testing related to user management procedures should
focus more on the use of the IdM. When IdMs are in use, the practitioner should
understand to what degree the IdM solution affects the Oracle Applications and the user
provisioning process (e.g. the provisioning of non existing users in OEBS to most likely
users).
o When IdM is used, the practitioner should understand, where the authentication starts,
either via the Oracle EBS or via the OID application.
o Controls testing should also include change control and testing around the IdM as it
relates to integrating with Oracle. In addition, controls testing should address gaps that
might exist between the management of users in the IdM and in Oracle. For example, if
users are created in the IdM and automatically sent to Oracle, is access to user
provisioning in Oracle sufficiently restricted to prevent an Oracle System Administrator
from creating a new user outside of the IdM? Depending on how the IdM is structured,
the risk in this situation is that the IdM would never have knowledge of the new user.
o Each new or changed user ID should have a completed authorisation request form.
This user ID authorisation form should clearly indicate the specific Oracle access (e.g.,
which Responsibility) should be granted.
o The risks vary depending on how the IdM is architected.

5. Multi organization access control


Oracle Release 12 introduced for the first time the concept of Multiple Organization Access Control
(MOAC). Using the new MOAC functionality, users can access multiple operating unit (OU) data
either within or across business groups from a single responsibility. Using MOAC, multiple operating
units are assigned to a security profile. This security profile is then assigned either to responsibilities
or directly to users. Examples of MOAC's impact on Oracle Payables are provided below.
o Enter invoices or batches of invoices for one operating unit, and then seamlessly enter
invoices for another operating unit
o Select invoices across operating units for payment processing within a single pay run.
This functionality can be leveraged in shared service environments to improve efficiency of data
processing.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 52 of 89

5.1. Functionality
In the Oracle 11i environment, the E-Business Suite (EBS) uses the profile option MO: Operating Unit
to link an operating unit to a particular responsibility. This process creates one-to-one relationship
between the responsibility and the operating unit. The system administrator must set this profile
option for each responsibility. EBS allows a user to see only the information for that particular
operating unit is assigned to the responsibility. If a user wants to enter transactions or perform setup
functions across several business units, then that user must be assigned multiple responsibilities with
access to each of the relevant business units. The user must switch between responsibilities to
perform updates to different business units.
The old model of managing multi-organization access in Oracle 11.5.10 has been enhanced, but not
replaced, by the MOAC. The option to use MO: Operating Unit profile option to enforce one-to-one
relationship between responsibilities and business units can still be used. Optionally, if an
organization wants to provide multiple organization access from a single responsibility, then those
organizations will use MOAC. EBS introduces a new profile option that enables MOAC -- MO:
Security Profile
MOAC provides the following two security profiles that enable users to access, process, and report
data in multiple operating units from a single responsibility:
o MO: Security Profile - Allows the assignment of multiple operating units for the same
business group.
o MO: Global Security Profile - Allows the assignment multiple operating units across
multiple business groups.
The following profile options are relevant to MOAC:
o MO: Security Profile
o MO: Default Operating Unit
o MO: Operating Unit (legacy functionality)
o SLA: Enable data access set security in Sub-ledger
The last profile option might expose the client to a specific risk. If MOAC is used, users may be able
to enter Journals in multiple ledgers through their sub-ledger level access (e.g. AP Subledger) if this
Profile option is deactivated. If it is activated users with Sub-ledger access cannot enter data into any
ledger.
Further granular access controls can be achieved through set up of Definition Access Groups
covered under General Ledger module.
New reports in the various EBS modules are available as a result of MOAC and can be categorized
by the following:
o Cross Organization Reports report data for one or more Operating Units. MO: Security
Profile option controls the operating units a user can submit a report for. The Reporting
Level and Reporting Context determine the level a user can submit a report for.
o Multiple Organization Reports report data for one or more multiple operating units from
a single responsibility. With multiple organizations access control, a responsibility could
have access to multiple operating units from a single responsibility. Even though the user
can access one or more Operating Units, the user can only report data for one operating
unit at a time.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 53 of 89

5.2 Profile options


MO: Security Profile
This profile option needs to be set in order for the MOAC model to work. If a company wants to allow
access across operating units from a single responsibility, the MO: Security Profile option needs to be
defined. Within the MO: Security Profile option, there is also a Global profile option which allows a
single responsibility to access across business groups (i.e. the highest level of organization in the
hierarchy).
The use of the Global Security Profile is currently not recommended. (e.g., this setting would allow a
user in the US Company to access the UK Companys information.
MO: Default Operating Unit
This profile options sets the default value of a specific operating unit for a given responsibility.
However, if the MO: Security Profile is also defined, this default value can be changed / overridden by
the user. The MO: Security Profile will allow the user to choose from a drop-down list of operating
units so the default value is not enforced.
MO: Operating Unit
This profile option existed in 11i and prior. This profile option is used to establish and enforce a oneto-one relationship between responsibility and operating unit. The MO: Security Profile option should
NOT be enabled for this scenario. If both MO: Security Profile and MO: Operating Unit profile options
are defined for the responsibility or user, the system will grant access based on the rules defined in
the MO: Security Profile option.
SLA: Enable data access set security in Sub-ledger
See comment above
Exception
If a company is using journal tax functionality in GL, then the MO: Operating Unit profile option must
be defined for the GL responsibility, however, this does not prevent the use of MO: Security Profile
option. For access purposes, the MO: Security Profile option will still take precedence over the MO:
Operating Unit.

5.3. Control Considerations


5.3.1. Business Process Variables
o Take the time to understand the reason why a client might be using the MOAC model
to grant a single responsibility access to multiple operating units. Additional
considerations must be made if MO: Global Security Profile is used instead of just MO:
Security Profile, as this option allows a responsibility to access data across business
groups. This could be compared to a scenario where a user in the US subsidiary can
access data in the UK subsidiary, which presents an even greater risk to data and
transaction security. The client's IT operations should reflect a shared service
environment to truly leverage the benefits of using MOAC. If there remains separate
delegation within shared service (i.e. employees are assigned to handle data for a
specific region), then client should consider using the traditional 11i multi-org model
where a responsibility is restricted to a single operating unit.
5.3.2. Control Dependencies
o Consider this functionality in relation with other enhancements like ROBAC and proxy
user.
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 54 of 89

From a segregation of duties perspective, understand how the ledger / ledger sets are
impacted based on the organization structure of the company. For future details on this
concept, refer to the GL practice aid for information on Data Access Sets and Definition
Access Sets. Keep in mind, that a true segregation of duties violation exist when a user is
able to have conflicting functions within an organization/operating unit for transaction
modules such as AP and PO, within a ledger/ledger set for the GL module, within an
asset for the FA module, and within a inventory org for the INV module.
5.3.3. Control Limitations
o N/A
5.3.4. Testing Notes
o Begin testing by understanding what kind of Multi-Org Access Control is being used by
the client. Then, depending on the Oracle module, understand how the MOAC module
impacts the SOD environment. For example, if MOAC is used to allow access to multiple
operating units from a single responsibility, then in an AP review, a user having access to
create vendors in operating unit A, create invoices in operating unit B, and process
payment in operating unit C is not a true SOD violation. Based on the Gate report, this
might be identified as a violation of SOD rules, which is true if a user is able to do all the
above functions in a single operating unit.
o Consider the impact if the sub ledger profile option is enabled.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 55 of 89

G. Application Support Responsibilities and Users


1. Support Responsibilities
1.1. Oracle System Administration
In releases prior to 11.5.10, Oracle would come with one system-administration ID with system-wide
primary responsibility. In 11.5.10, the system support features have been separated.
Responsibility
System Administration

Features
Technology/Infrastructure
management
System diagnostics

System Administrator

Security -- User, responsibility, audit


trail management
Concurrent process management
System-wide
application
configuration capabilities
Workflow management

By default, no auditing is enabled for the system administration / support responsibilities. Please see
the Auditing section of this Practice Aid for further information.

1.2. Application Developer


The Application Developer responsibility is a responsibility that is shipped with Oracle. This
responsibility is used to develop and register new functionality within the Oracle EBS. Additionally,
Application Developer can update system wide configurations.

1.3. Alert Manager


Oracle Alerts are system notifications that inform users of sensitive events occurring within Oracle.
These events are defined by client management. Alerts can send notifications at the time of the event
or simply send a periodic message about a certain type of event. Clients generally leverage Alerts as
key components of their monitoring controls. Users having access to the Alert Manager can modify
any/all Alerts and disable them if needed.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 56 of 89

The Alert Manager can


enable/disable the
Alert.

The Alert Manager can


modify what is being
monitored.

1.4. Workflow Administrator


Workflow is the automatic routing of documents (physical or electronic) to the individuals responsible
for working on them. Workflow also provides the information required to support each step of the
business cycle. The flow of physical documents in an organization is subject to errors and delays.
Workflow sets timers that ensure that documents move along at a prescribed pace and that the
appropriate person processes them in the correct order.
The Oracle Workflow Administrator can build, implement, and run workflows in the production
environment. The Oracle Workflow Administrator responsibility grants the individual the ability to
perform these activities. This powerful access, however, is generally limited to the user's own
workflows. To impact system-wide workflows, the Workflow Administrator role must be assigned to
the user. This access is granted through the Administration tab in Oracle Workflow. Workflow
administrator capabilities are required to assign another individual this role.

The ability to view and update anyone's workflow has significant implications. If an individual had
access to the workflow administrator role, sensitive transactions could be initiated directly in workflow.
The following example identifies how to create a new sales order through workflow: The individual
selects the order entry process workflow and selects the "Run" option.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 57 of 89

After selecting the "Run" icon, the user is then prompted with the required information to launch the
process:

The individual will


supply the required
elements and select
submit to initiate a
new sales order.

In this circumstance, the workflow administrator could initiate a new drop shipment sales order
without having direct access to the order entry forms. This process is the same for any workflowrelated process throughout the application.
In addition to initiating sensitive workflow, the workflow administrators can approve/reject/delete in
any transaction currently in process under workflow via the view diagram form, as noted below.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 58 of 89

The workflow administrator


can reassign workflows to
any active user, or they can
expedite (cancel or approve)
any workflow process.

1.5. Diagnostics Utility


The diagnostics utility is a feature that assists troubleshooting application functionality. This feature is
controlled by two system profile options:

Hide Diagnostics menu entry; and


Utilities: Diagnostics.

Business end users should not have access to this feature for the following reasons:
Form Personalisation is a new feature in Oracle EBS 11.5.10 and is available in the diagnostics
area. Form Personalisation has the capability in Oracle to perform system wide customisation.
This customisation ranges from protecting field-level data on a form to hiding entire forms. This
feature is available in the Diagnostics area. If the client is relying on Personalisation for tuning
controls, then allowing business end users the ability to access this feature will circumvent the
intended control.
Many of our clients also utilise of the custom.pll programming interface to fine tune security and
data protection on a form. This custom code can be disabled through the diagnostics feature.
The "examine" and "properties" capabilities under the diagnostics menu provide an individual with
specific information regarding the nature of the information and data used. In some situations, the
individual can even update data in the application through this feature.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 59 of 89

Gives the users


detail information
about the application
and data

Enable/Disable custom.pll code

Modify Personalisation

1.6. Processing/Program Management


Batch Processes as well as report requests are generated through concurrent request manager. The
Concurrent Manager is a utility within Oracle that allows a user to manage the various requests that
run various jobs and at the same time, still allows the user to have the ability to transact within the
system.

The User ID who requests a concurrent program or report to be run will have their User ID assigned
and tracked within the application.

1.7 Application manager


Oracle Application Manager is a powerful tool that allows user to:
o
Monitor and support business flows within Oracle E-Business Suite
o
Edit or delete workflows
o
Manage concurrent manager
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 60 of 89

The following screen-shot depicts the available administrative functionalities within Application Manager:

Taking the functionality business flow (Business flows consists of workflows), system administrator can
manage the business flow functionality as depicted in the following screen-shots.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 61 of 89

Choose the Order to Cash flow

The workflows appear below the


business flow

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 62 of 89

1.8. Control Considerations


1.8.1. Business Process Variables
o Oracle does not have detailed security around Alerts. The Alert Manager will provide
access to all Alerts. If the client makes extensive use of Oracle Alerts, access to the Alert
Manager should be restricted.
1.8.2. Control Dependencies
o None
1.8.3. Control Limitations
o The Application Developer comes with the Process Navigator Tab enabled. Given the
purpose and access granted, formal change control procedures for this responsibility
should be active in the production environment.
o The seeded Application Developer responsibility also contains the menus needed to
change Key Flexfields (i.e. General Ledger Accounting Flexfield) that creates a
segregation of duties issue. There is a legitimate need for an Application Developer to
have access to Key Flexfield definitions, but usually this access is restricted to a test or
development environment only.
1.8.4. Testing Notes
o An Alert by itself is not a control. The Alert only notifies management to perform some
activity. PwC should consider and test the procedures required of management as a
result of the alert
o Workflow controls should not be limited to the approval hierarchy and distribution list.
Practitioners should consider testing any Workflow-related transactions on a substantive
basis to ensure transactions are processed in accordance with management's control
objectives and policies.
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 63 of 89

o The ability to view and update anyone's workflow has significant implications. If an
individual had access to the workflow administrator role, sensitive transactions could be
initiated directly in workflow.

2. Application Support User IDs


2.1. Guest ID
The Guest ID in Oracle EBS is required for all users. This ID is used during the login / authentication
process to validate the user's credentials. The Guest password is stored as a site-level system profile
option - Guest User Password. The default value for this profile option is GUEST/ORACLE.
Recommended practice is that the password, like all default IDs, is changed after installation.
Disabling this ID will prevent all users from being able to log in to the application. This ID should have
no responsibilities associated with it, or only those required to support authentication for the selfservice applications.

2.2. Default/Seeded User IDs


The following user IDs are shipped with Oracle EBS.

ANONYMOUS
APPSMGR
ASGADM
ASGUEST
AUTOINSTALL
CONCURRENT MANAGER
FEEDER SYSTEM
GUEST
GUESTADMIN
GUESTUSER
IBEGUEST
IBE_ADMIN

IBE_GUEST
IEXADMIN
INITIAL_SETUP
IRC_EMP_GUEST
IRC_EXT_GUEST
MOBILEADM
OP_CUST_CARE_ADMIN
OP_SYSADMIN
PORTAL30
PORTAL30_SSO
SYSADMIN
WIZARD

PwC should review these accounts and ensure that only required user IDs in this are enabled and
that all default passwords are changed. These seeded / default IDs should not be included in a list of
generic accounts reported to the client.

2.3. Control Considerations


2.3.1. Business Process Variables
o
None
2.3.2. Control Dependencies
o
None
2.3.3. Control Limitations
o
None
2.3.4. Testing Notes
o

None

3. APPS Database ID
A common approach to application design for many web-based applications, including ERP`s,
includes the use of global database accounts (or IDs). These IDs are used to own and manage most,
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 64 of 89

if not all, application components in the database. Examples of use by these IDs include connection
pooling (for better performance) and cross-functional access by the application within the database.
Because these IDs own the application components in the database, they are used during
implementations and patch upgrades.
In the Oracle E-Business Suite, the global database ID that owns the application schema is called
"APPS". APPS is unique to Oracle E-Business Suite and is not applicable to any other application.
The APPS ID is stored in the "SYS.DBA_USERS" table in the Oracle database. This table is where
database user IDs are stored and is found in every instance of the Oracle database. Oracle EBusiness suite user IDs such as SYSADMIN are stored in an application specific table called
FND_USERS. The FND_USERS table will only be found in E-Business Suite environments.
Use of the APPS ID in the Oracle EBS results in a shared, all-powerful ID where user accountability is
reduced, logging and monitoring is challenging, and the related password is changed infrequently.
Although technically this ID related to the Oracle database, this issue should be addressed during a
database review performed in conjunction with the Oracle EBS review.

3.1. Risk
The use of a generic, all-powerful database ID, such as APPS, presents a heightened risk that
unauthorized changes to the database may go undetected due to the difficulty in monitoring its
appropriate use. The APPS ID is not an application ID and cannot be used to log in to the application
by an end-user. However, certain features of the Oracle E-Business Suite require the use of the
APPS ID password in order to be utilized.
The APPS ID grants privileged users, such as DBA`s, with direct and ongoing access to key data.
Once the data is in the database, it is subject to additional changes, authorized or not. Without
auditing at the database level, there is also reduced comfort that applications controls and other
security measures are working as intended. The use of the APPS ID increases the following risks:

Unauthorised changes to any application data or object - The APPS ID is the primary schema
owner for Oracle EBS; therefore, it can access/update any data in the database.
Reduced ability to monitor changes made by this ID -- By design, many of the activities performed
in the application have some relationship to APPS. Many of the stored procedures/packages will
not function correctly unless executed by APPS. Additionally, application DBA`s require the use
of APPS to help determine and remediate performance issues. These diagnostics features are
accessed through a restricted menu in the application. The APPS password is generally required
to access these diagnostics. Lastly, the audit trail created by this ID would potentially be too large
to be of use and would have a detrimental effect on application performance.

Note: Many of the inherent functions called by the APPS ID cannot be substituted with other database
administrator IDs such as SYSTEM, SYS, or other custom administrator IDs. However, not every
maintenance procedure needed to be performed by the client requires the use of the APPS ID. For
example, system backups should be able to be performed by other database administer IDs.
Understanding the proper use of the APPS ID is key for the client and for us to gain comfort with
regards to management's culture and company-level controls.
Unlike other ERP packages, the Oracle E-Business Suite environment does not have a formal
change control process embedded into the functionality of the application (including physical
application files and database components). This places increased risk related to the use of the
APPS ID and therefore greater pressure on the need to obtain a reasonable level of comfort on the
appropriate use of APPS.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 65 of 89

3.2. Potential Automated Solutions


The inherent auditing mechanism in the Oracle database (and related Application Programming
Interfaces - APIs such as the "Audit API") can be used to help monitor changes to the database and
is discussed later. However these auditing mechanisms in the application and in database are not
sufficient to allow for effective monitoring of the APPS ID.
Oracle is currently introducing its IT Auditor module for the E-Business suite which will further help
with change control. Oracle is also introducing Database Vault which addresses segregation of duties
within the database. Oracle Database Vault addresses some of the most common database security
problems and internal threats by:
Restricting the DBA and other privileged users from accessing application data
Preventing the Application DBA from manipulating the database and accessing other applications
Provides better control over who, when & where an application can be accessed
Additionally, functionality in other third party tools provides tighter control over Oracle E-Business
Suite change control procedures. Refer to Oracle Metalink at https://metalink.oracle.com/.
To augment basic monitoring procedures over the APPS ID, other features can be implemented to
help ensure that access to the database is controlled. Either approach individually or collectively are
controls we recommend. Through the use of native Oracle security features found within SQLNET
(sqlnet.ora configuration file) and the LISTENER (listener.ora configuration file), Oracle can be
configured to only allow connections from certain locations or IP addresses. Specifically, the
listener.ora file has an optional section where a list of authorized connection sources is listed.
Oracle-native security is not the only way to restrict access to the database. An intrusion detection
system (IDS) including firewalls and other hardware/software could isolate the database server. IDS
security could limit access to pre-determined locations. Additionally, IDS monitoring and reporting
features could also be us.

3.3. Control Considerations


The overall approach for managing this issue (and subsequent testing) is a combination of IT
monitoring controls, restricted access, good company-level controls and good policies and
procedures. Management should also have fraud monitoring controls in place for key employees and
users of the application. Even though ERP transactional data is generally very complex and difficult to
initiate from the database, the possibility does exist that inappropriate business information can be
initiated from the database and processed. Generally, the business process controls mentioned could
provide a significant amount of risk mitigation.
The IT controls that can be implemented include monitoring sensitive access to the database,
monitoring sensitive changes to the database, protecting the audit trail and restricting access to the
database.
3.3.1. Access to APPS Password
Generally, the requirements for using this ID would be similar to those of an emergency or
"fire-call" ID. The exception with the APPS ID is that periodic change of the password is not
suggested since the application itself uses the ID to perform certain actions and procedures.
Changing the APPS password should be a controlled and planned event to ensure that
unplanned system outage does not occur due to password errors. While Oracle does provide
some ability to dynamically change application passwords while the system is still live, we do
not suggest this approach in managing these passwords. Failure during this password
change process could, and probably will, bring down the system. This risk is especially true if
the client makes use of custom routines that require the APPS password. These routines
would need to be modified as well in order to function properly.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 66 of 89

Unless the client has a very strong reason to the contrary (exceptions should be discussed
with the PwC Oracle SME team), the core DBA team are the only individuals who should
have access to this password. These are same individuals who know the SYSTEM and SYS
passwords. Even then, the APPS password should be restricted to a limited number of
individuals in that team. If needed, the core DBA team could implement its own internal firecall system for this ID. Typically, the application end-users should not have access to this
password.
3.3.2. Valid APPS ID Users
Valid use of APPS by individuals should relate only to formal IT activities in support of the
application that require the use of the APPS ID and that cannot be executed by other IDs.
These activities should be limited to implementation/patch maintenance and startup/shutdown
of middle-tier services -- such as the application server itself. Normal database maintenance
activities such as system backup and most statistics can be performed using SYSTEM or
other database administrator IDs with equivalent rights. Another typical type of activity that
requires the APPS ID is the need to run diagnostic scripts and data fixes authorized by
Oracle Support.
3.3.3. Monitoring of APPS
The use of APPS is generally not monitored formally. The reasons are noted above -detailed monitoring activity performed on this ID will probably produce a voluminous audit trail
and have a detrimental effect on system performance. The objective is reasonable (not
complete) assurance that APPS is used appropriately. Some monitoring should occur.
However, reasonable assurance should only require monitoring to a sufficient level that its
use can be tied to formal change request activities or those used to recover normal
operations. This monitoring should also be tied to a stated policy on its use, documented and
acknowledged policies and practices on the repercussions of its use when not used as
approved. These repercussions should be significant enough to have an impact on the
culture.
3.3.4. Database Triggers
When APPS and other highly sensitive database IDs are used, an important element to
consider is whether or not the ID was used (or at least appeared to be used) by the
application. When these IDs are used outside of the application, these situations should be
documented and follow-up procedures should be performed. To support this control, a login
trigger can be developed and implemented to track when database IDs connect to the
database. By excluding the application server locations, an audit trail can be created to
identify when these IDs are used but not by the application. The use of a second trigger, a
logoff trigger, is essential to this audit trail in that the duration of time used by the ID can also
be recorded. The activity in the resulting audit trail should then be able to be matched to the
access request log and the maintenance activities.
Technically, setting up the triggers and audit trail is not complicated. The true cost of
ownership will involve the monitoring and follow-up activities. Management should have a
support department large enough for effective monitoring. The related benefits include a more
complete picture with regards to change control and maintenance activities. Performance
impact (if any) as a result of these triggers is not known and could vary based on client
implementations.
To augment the login/logoff trigger, an additional trigger could be enabled to monitor all
database structure changes. DDL transactions (data definition language) are those activities
that change the structure of the database -- creating, altering and dropping tables, indexes,
triggers, stored procedures, etc. This trigger should be natively available in Oracle. Most all
the activity performed within Oracle E-Business Suite involves transactions related to data not
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 67 of 89

the database structure. Enabling a DDL trigger should not have a significant impact on
system performance and should be able to be effectively used to monitor database changes.
Note: The DDL trigger should capture all structure changes and not be limited just to APPS.
Changes to standard E-Business Suite tables and views should be noticed by the end users
of the system fairly quickly. We should only recommend this control if management is
leveraging some sort of customization in the database to support key controls. Changes to
triggers and stored procedures are custom code that could alter the results of control
activities. E.g., if management had implemented the logon/logoff controls above, they would
want to know if that trigger had been subsequently modified.
The cost of this control would involve protecting the audit trail and independent review. The
benefits of this control would include monitoring of some custom configurations designed and
implemented to support management's key controls.
3.3.5. Detailed Auditing
Detailed auditing of the APPS ID or any other database ID used by the application is not
suggested while the application is live and supporting production activities. Occasionally, our
clients have considered this control in an attempt to better document the actual activities
performed under change control. If detailed auditing is attempted, it should only be performed
while the application is down and under change control. Procedurally, the audit mechanism
for the APPS ID or other sensitive database IDs would have to be enabled prior to its use and
disabled prior to the application going live again.
The cost of this control includes additional procedures pre/post change control to
enable/disable the detailed auditing. The true benefits of this control are probably outweighed
by existing business process controls. Unless management's circumstances are really
unusual, this is a control we would not generally recommend.
3.3.5.1. Protecting the Audit Trail
The objective is to ensure that DBA`s and other individuals with very sensitive access do not
have the ability to alter the audit trail created by the database. The Oracle database supports
two different ways to record audit trail information: 1) outside the database on the operating
system, and 2) within the database.
3.3.5.2. Outside the Database on the operating system
Oracle can write each audit event to a separate file on the operating system. The benefit of
this approach is that large volumes of audit events do not impact database capacity.
However, the audit trail will be owned by the database; therefore, the DBA probably has
access to the audit trail. One cost of this approach is that it does not easily support
streamlined reporting.
If management can prove that it can effectively protect this audit trail from inappropriate
updates and can report against the information, then this is an acceptable approach.
3.3.5.3. Within the Database
The Oracle database can record audit trail within the database. The benefit of this approach
includes a consistent format that can be used for consolidated reporting. The cost of this
approach includes 1) a greater risk of inappropriate audit trail modifications, and 2) increased
database capacity requirements. Again the objective is to protect the audit trail from highlevel access. To support this approach, the following items should be collectively considered:
The use of individual database administrator user IDs and custom database roles.
These custom roles would not allow updates to the audit trail. This approach to assigning
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 68 of 89

access to DBA`s can provide sufficient access to administer the database but prevent
updates to the audit trail.
Formal fire-call / request procedures for the use of default DBA ID such as SYS and
SYSTEM.
As a precaution against default DBA IDs updating the audit trail, enable auditing over
the audit trail. While detailed information might not be available regarding the update,
enabling auditing over the audit trail will at least identify that the audit trail was modified.
Follow-up activities should then be performed to understand why the audit trail was
updated.
The audit trail should be sent to the operating system away from the control of the
DBA. Ideally, the audit trail would be sent through the system logging facility on the
operating system. This approach would further separate the audit trail from the DBA`s.
The frequency by which the audit trail is sent to the operating system should be assessed
against the feasibility of enforcing individual user IDs and custom roles. If the audit trail is
copied out of the database infrequently, greater need is realised to enforce individual
user IDs and custom roles in the database.
Note: Several of our clients have considered this approach. The implemented status of
this approach, however, is not currently known.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 69 of 89

H. System Profile Options


System Profile Options are system parameters that can have a global impact on Oracle EBS. Those
same parameters can also only have limited effect on the system. The overall effect of the parameters on
the system is dependent on which level the parameters are configured -- site, application, responsibility
and user.

1. Site-Level
System Profile Options at the site level have global impact to Oracle EBS. For example, the default
Ledger name is set at the site level. If Oracle responsibilities are not explicitly assigned to Ledger
names, then, by default, they are assigned to the site-level default Ledger name.

1.1. Control Considerations


1.1.1. Business Process Variables
o
None
1.1.2. Control Dependencies
o
None
1.1.3. Control Limitations
o
None
1.1.4. Testing Notes
o
System profile options at the site level can be effectively tested online.
GATE reports can also be used.

2. Application-Level
System Profile Options at the application level only have impact on the application associated with
the particular parameter. For example, sequential numbering could be set to "Partially Used" at the
site level, but set to "Gapless" in Payables. In this situation, "Gapless" sequential numbering will be
used in Payables, but "Partially Used" will be enforced in the other Oracle modules. Application-level
system profile options override site-level system profile options.

2.1. Control Considerations


2.1.1. Business Process Variables
o
None
2.1.2. Control Dependencies
o
None
2.1.3. Control Limitations
o
None
2.1.4. Testing Notes
o
System profile options can be tested online for applications in-scope.
GATE reports can also be used.

3. Responsibility-Level
System Profile Options at the responsibility level only have impact on the responsibility associated
with the particular parameter. Oracle responsibilities are generally associated with a specific Ledger
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 70 of 89

name and operating organization by using responsibility-level system profile options. For example,
even though the site level ledger name and operating organization is set to "Ledger name A and Org
A" respectively, "ABC Responsibility" could be assigned to "Ledger name B and Org B" respectively
at the responsibility level. The responsibility-level assignment will be the one that is enforced.
An important concept with regards to responsibility assignments is that they do not have to
correspond to the Ledger name and operating organization relationships defined in Oracle EBS. For
example, Org 1 and Org 2 might be associated with Ledger name 1. However, "ABC Responsibility"
could be assigned to Org 2 and Ledger name 4 at the responsibility level. Again, this situation would
be enforced even though the Ledger name / Org relationship is not consistent with the overall legal
structure. Responsibility-level system profile options override those system profile options at the site
and application levels. In addition you can assign a responsibility to several organizations. Please
refer also to the chapter about Multiple Organizations Access Control MOAC.

3.1. Control Considerations


3.1.1. Business Process Variables
o
None
3.1.2. Control Dependencies
o
None
3.1.3. Control Limitations
o
None
3.1.4. Testing Notes
o
System profile options at the responsibility level cannot be effectively
tested online unless specific responsibilities are being tested. GATE reports should be
used; otherwise, a custom query made by the client will be required to obtain profile
options set at the responsibility level.

4. User-Level
System Profile Options at the user level only have impact on the user associated with the particular
parameter. The user-level system profile options override system profile options set at the site,
application and responsibility levels. For example, the system profile option "Hide Diagnostics menu
entry" could be set to No at the site level. Unless overridden elsewhere, no one would see the
Diagnostics menu under Help. However, this system profile option could be set to yes for individually
system support personnel.

4.1. Control Considerations


4.1.1. Business Process Variables
o
None
4.1.2. Control Dependencies
o
None
4.1.3. Control Limitations
o
None
4.1.4. Testing Notes
o
System profile options at the user level cannot be effectively tested
online unless specific users are being tested. GATE reports should be used; otherwise, a
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 71 of 89

custom query made by the client will be required to obtain profile options set at the user
level.

5. Key Profile Options


The following section highlights the key system profile options to review for audit and consulting
engagements. The "Relevant" column indicates if the profile option is applicable for audit (A) and
consulting (C) projects.

5.1 Profile options


Profile Option

Setting

APPS_SSO_LINK_T
RUTH_SRC

Applications SSO
Linking Source of
Truth

If new for R12,


what is it?
Applications SSO
Linking Source of
Truth

APPS_SSO_POSTL
OGOUT_HOME_URL

Applications SSO
Post Logout URL

APPS_SSO_OID_ID
ENTITY

Available Options

Relevant

E-Business Suite,
Oracle Internet
Directory

Applications SSO
Post Logout URL

User Defined

Applications SSO
Enable OID
Identity Add
Event

When a user is
created in OID, the
IDENTITY_ADD
event is sent to all
registered
instances.
This event controls
whether an EBusiness Suite
instance should
create the user in
response to
IDENTITY_ADD

Enable, disable

APPS_SSO_AUTO_L
INK_USER

Applications SSO
Auto Link User

If a user
authenticated by
SSO has no
corresponding user
in E-Business
Suite, it will look for
a local user with
the same user
name. If found, it
will be permanently
linked

Enable, disable

TBD

APPS_SSO_ALLOW
_MULTIPLE_ACCOU
NTS

Applications SSO
Allow Multiple
Accounts

At user level, it
enables a user to
have multiple EBusiness Suite
accounts linked to
a single SSO user
name.

Enable, disable

TBD

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 72 of 89

Profile Option

Setting

If new for R12,


what is it?
Selection of which
account is active is
done via the
Preferences page.
At site level, it
indicates the
default for users
without this specific
setting.

Available Options

Relevant

FND_EXPORT_ALL_
BLOCK_DATA

FND Export All


Block Data

The profile control


what data is
exported from a
form's block.

Yes, No

TBD

FND_FIXED_SEC_K
EY

FND: Fixed Key

The fixed security


key to be used in
Framework if the
profile FND Fixed
Key Enabled is set
to Y for the user.
The key should be
a Hexadecimal
string of size 64.

User Defined

FND_FIXED_KEY_E
NABLED

FND: Fixed Key


Enabled

This profile
determines if a
fixed key will be
used for security
purposes in
Framework.

Yes, No

FND_CACHE_PORT
_RANGE

FND_CACHE_P
ORT_RANGE

Opening up a
range of ports so
that machine can
talk across DMZ

User Defined

OAM_DSCRAM_ALL
OWED

OAM: Data
Scrambling
Allowed

Profile option to
allow data
scrambling

User Defined

OAM_DSCRAM_ENA
BLED

OAM: Data
Scrambling
Enabled

Profile to enable or
disable data
scrambling

User Defined

OAM_WS_AUDIT_E
NABLED

OAM_WS_AUDI
T_ENABLED

Enable or Disable
Web Service
Auditing

User Defined

SIGNON_PASSWOR
D_CASE

Signon Password
Case

Enables or
Disables Password

Enabled, Disabled

A&C

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 73 of 89

Profile Option

Setting

If new for R12,


what is it?
Case Sensitivity

Available Options

Relevant

OAM_ENABLE_SYS
TEM_ALERT

System Alert
Enable Level

System Alert
Enable Level

All, Critical and Error,


Critical, None

SIGNON_PASSWOR
D_CASE

Signon Password
Case

Enables or
Disables Password
Case Sensitivity

Insensitive, Sensitive

A&C

SIGNON_PASSWOR
D_CUSTOM

Signon Password
Custom

Profile option that


specifies the full
name of the class
containing custom
password validation
logic.

User Defined

A&C

SIGNON_PASSWOR
D_FAILURE_LIMIT

Signon Password
Failure Limit

A positive integer
indicating the
maximum number
of logon attempts
before the user's
account is disabled.

User Defined

A&C

SIGNON_PASSWOR
D_HARD_TO_GUES
S

Signon Password
Hard To Guess

Profile that gets set


to "true" if hard-toguess password
validation rules
should be enforced
for new passwords.

Yes, No

A&C

SIGNON_PASSWOR
D_LENGTH

Signon Password
Length

Minimum length of
Applications user
password

User Defined

A&C

SIGNON_PASSWOR
D_NO_REUSE

Signon Password
No Reuse

Profile to specify
the number of days
a user must wait
before being
allowed to reuse a
password.

Yes, No

A&C

SIGNONAUDIT:LEVE
L

Sign-On: Audit
Level

Level at which to
audit foundation
usage

NONE, USER,
RESPONSIBILITY,
FORM

A&C

SIGNONAUDIT:NOTI
FY

Sign-On:
Notification

Notify User
Concurrent
Program Failures
and Invalid Printers

Yes, No

A&C

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 74 of 89

Profile Option

Setting

FND_DIAGNOSTICS

FND: Diagnostics

FND_HIDE_DIAGNO
STICS

Hide Diagnostics
menu entry

UNIQUE:SEQ_NUMB
ERS

If new for R12,


what is it?
Enables
Diagnostics Global
Button

Available Options

Relevant

Yes, No

A&C

Hides the Help:


Diagnostics Menu
entry

Yes, No

A&C

Sequential
Numbering

Sequential
Numbering

Always Used, Not


Used, Partially Used

A&C

CONC_REPORT_AC
CESS_ LEVEL

Concurrent:
Report Access
Level

Provides controlled
access of
log/output files of
requests to group
of users based on
the current
responsibility of the
user based on this
profile option value

Responsibility, User

PRINTER

Printer

Output Printer

Registered Printers e.g.


( noprint, LabelPDF)

A&C

FA_WF_GENERATE
_CCIDS

FA WF
GENERATE

FA: use workflow


account generation
notification for new
assets.

Yes, No

A&C

The standard
setting is 7 days.
After this time has
expired, Journal
Approval notifies
the preparer that no
approver response
has been received.

Days

Oracle User
Management is
now integrated with
Oracle Internal
Controls Manager
(ICM) for the
prevention,
detection,
enforcement, and
resolution of
separation-ofduties constraints
during the

Yes, No

A&C

Workflow activity
settings: Request
Approval From
Approver timeout

UMX: Enable ICM


Validation"

Enabled/disable
access to
override violation
is restricted or
not allowed at all

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 75 of 89

Profile Option

Setting

If new for R12,


what is it?
assignment of roles
by administrators to
users.

Available Options

Relevant

MO: Security Profile

(Global or just
Security Profile)

Required for
MOAC: To enable
MOAC, assign this
profile option to an
application
responsibility. This
responsibility will
then allow the
assigned users the
access to multiple
operating units. In
Release 12, a
Security Profile is
created in the HR
module. Multiple
operating units are
then assigned to
the profile. The
Security Profile is
then assigned to a
responsibility using
the profile option
MO: Security
Profile

Yes, No

A&C

MO: Default
Operating Unit

Operating unit

(Optional) This
profile option
defines the default
operating unit for
users when they
perform activities in
the sub-ledgers.

Yes, No

A&C

This profile option


needs to be set to
Yes in order to
enable data access
set security in the
sub-ledger. If this is
not set regardless
of the data access
set that is assigned
to the responsibility
or even if the
responsibility is
restricted to a
specific ledger

Yes, No

A&C

SLA: Enable Data


Access Set Security
in Sub ledger

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 76 of 89

Profile Option

Setting

If new for R12,


what is it?
using the GL
Ledger Name
profile option, the
user will be able to
create and post any
journal in any
ledger through the
sub-ledger.

Available Options

Relevant

Note: audit trail profile options are not considered here.

5.2. Other settings to be considered


5.2.1 Set workflow notification mailer SEND_ACCESS_KEY to N
When SEND_ACCESS_KEY is set to Y, the workflow notification email bypasses the EBS
sign-on process; email notifications contain an access key. The key allows the user to access
the Notification Details web page directly without authenticating. Set SEND_ACCESS_KEY to
N to prevent inclusion of the key with the Notification Detail link. When set to N, an
unauthenticated user who clicks on the notification link must sign on before accessing the
Notification Details web page.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 77 of 89

I. Segregation of Duties Concepts


Segregation of Duties (SoD) within Oracle E-Business Suite (EBS) is challenging. Many layers of
configurations, access and other elements in the application come together to both restrict and increase
the exposure to security weaknesses.
Most practitioners only consider SoD in relation to forms and functions. However, these Oracle features
are augmented by other configurations as indicated below. These additional configurations should be
considered for additional testing separate from, and in conjunction with, a SoD analysis.

Segregation of duties and restricted access is a multidimensional challenge within Oracle EBS

Note: From release 11.5.10, a new feature


called Personalisation is an additional
element that affects SOD. This feature can
be used to improve security on forms.

Segregation of Duties is defined as segregating access to multiple sensitive functions that, when
combined, present a significant risk of fraud or theft. The fundamental types of activities that should be
separated from each other are as follows:

Initiation -- Entering the transaction


Authorising -- Posting the transaction
Standing Data -- maintaining master data such as the vendor
master file
Custody of Assets -- Physical custody of assets
Recon/Review -- Reconciling/Reviewing the accounting activity
over certain transactions
Sensitive Access -- Application and Business setups that
support the business.

Application setups are those configurations in the application that have a very broad effect on how
accounting is performed and reported. These configurations should be finalized after implementation and
changed infrequently, if at all. Examples of application setups include Sets of Books definitions, legal
structures and flexfield definitions. Changes to application setups should follow a very formal change
control process much like an IT change control. These changes should be tested and approved prior to
migration into production. The technical support group should be the individuals with access to these
types of setups.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 78 of 89

Business setups, on the other hand, are those application configurations that might change over the
course of the accounting period as a normal course of business. An example of a business setup would
be opening/closing GL periods. Periods must be opened and closed to support accounting activity;
however, a business process owner has access to this feature and will make the change outside of a
formal change control process.
For SOD testing and process specific SOD principles, refer to each module's Practice Aid.

1.3. Control Considerations


1.3.1. Business Process Variables
o
None
1.3.2. Control Dependencies
o
The Custom.pll library is a standard Oracle Forms PL/SQL library that is
supplied by the Oracle Applications. This is Oracles built-in feature that allows the customer
to enhance the standard functionality of the Applications by implementing site-specific
business rules. Every Oracle Forms -based eBusiness screen, and any custom form
developed using the Oracle Application development standards, will access the CUSTOM
library. This allows customers to create business rules that effect the entire organization.
Customers may use this functionality to hide certain tabs from users (i.e. Process Tab) or
enforce even more granular controls in forms and functions access. PwC should inquire if the
client is using Custom.PLL to further control user access during SOD testing and validation.
1.3.3. Control Limitations
o
Oracle is installed with default responsibilities that help the client enter
and post transactions. These responsibilities were built by Oracle without any consideration
of Segregation of Duties principles.
1.3.4. Testing Notes
o

Personalisation is not currently analysed by Oracle GATE.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 79 of 89

J. Restricted Access/Segregation of Duties


When conducting an Oracle restricted access / segregation of duties review, there are three main access
considerations:
Application Setups
Standing Data
Segregation of Duties

1. Application Setups
Application Setups are defined as configurations that change the behaviour of the application. These
setups are generally only configured upon installation, upgrades, or major business events. Changes
in business process setups could cause system failure and/or data inconsistencies. Therefore,
access to these setups should be restricted to the IT department or similar technical role.
In addition, because of the potential impact on key financial controls associated with these setups,
any changes to these should be implemented via the clients stated change management process &
controls. Please note that the definition of what constitutes application setups will vary from client to
client, and practitioners should discuss these concepts with clients prior to commencing any Oracle
work.

2. Standing Data
Standing Data are defined as either setup that affect the processing of transactions or is used in the
processing of transactions that could have a financial statement impact. These setups are generally
configured upon installation, upgrades, or major business events. However, they may also need to be
changed periodically to reflect ongoing changes to the business environment. Changes in standing
data could cause financial processing difficulties and/or changes to standard transaction accounting
procedures. Therefore, access to these setups should be limited to a select few business process or
IT owners who do not have transactional access.
Changes to standing data setups should be approved prior to implementation due to their potential
impact on key financial controls and/or processes. Please note that the definition of what constitutes
standing data will vary from client to client, and practitioners should discuss these concepts with
clients prior to commencing any Oracle work.

3. Segregation of Duties
Segregation of Duties is defined as segregating access to two or more sensitive functions that, when
combined, could present a risk of material misstatement, management override, fraud or theft.

3.1. Designing SoD


Segregation of Duties and Restricted access design could be complex and is dependent upon each
client's environment. Clients should acknowledge the inherent accounting and unique business risks
that require certain activities to be performed by different individuals. In either circumstance, the rules
and related documentation developed should be associated with the client's significant financial risks.
Segregation of Duties and Restricted access design could include a balance between separating all
conflicting activities and mitigating all segregation of duties violations. This decision making process
should include formal elements of SoD analysis. When designing SoD principles, the following should
be kept in mind:
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 80 of 89

Envision the ideal environment, regardless of head count. However, risk and likelihood should
be considered.
Smaller areas / business units may not be able to implement proper SoD rules due to resource
constraints.
All high-risk financial systems should be considered, not just Oracle.
When SOD is impossible, mitigating / compensating controls should be identified

Generally, the following SoD principles should be adhered to:


Users with transactional access are restricted from standing data and application setup.
Cross module (currency, ledger) and/or hidden access (process tab) should typically not exist
Users should not be able to create and approve their own transactions.
Custody of assets is separate from accounting transactions.
IT support should not violate the SoD rules. Support procedures should be developed that will
allow for the effective remediation of technical issues while giving the business process owners a
stable, controlled, monitored accounting environment.

3.2. Documentation of Rules


Management should have a formal set of documents identifying the high segregation of duties and
restricted access risks and conflicts that could exist for each business cycle. This set of
documentation should then include the relevant segregation of duties and restricted access controls
that the client implemented to mitigate these risks. These controls could include a balance between
segregation of duties, restricted access and/or other business mitigating controls.
Ideally, the client has developed a matrix of business processes (including Oracle functionality) that
identifies the SoD and restricted access rules for a business process. An example of this matrix is
identified below. The X's in the matrix identify the SoD conflict between the x and y axis of the matrix.
The H's identify the agreed-upon sensitive business transactions that should also be tested with
regards to restricted access.
Sample SoD matrix

3.3. SOD Monitoring


Once rules are established, the client can then determine the more effective cost of the control to
mitigate the segregation of duties risk or to rely on the separation of conflicting activities. Small
environments could leverage a manual approach to SoD management. Large environments will
almost always require technology to management SoD effectively. Typically SoD management is
driven and managed by the technology group. Unless the business process owners sponsor and
drive the project, SoD management is often much less effective.
3.3.1. Manual Monitoring
If the client chooses to sustain SoD on paper, then the following may be used:
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 81 of 89

o
Access Authorisation: Testing the authorisation sign-off form is a
common test for IT general control reviews. In this, evidence that existing user access
was compared to requested access should be documented. Access authorisation makes
an assumption that management understands the risk of granting the additional access
and the functions associated with each responsibility
o
SoD Maintenance: If the client's responsibility design is good, then the
client might have a higher-level SoD matrix based on Oracle responsibilities. This
responsibility-level SoD matrix would help management more quickly identify potential
SoD issues before granting additional access.
3.3.2. Automated Monitoring
If the client chooses technology to help sustain their SoD environment, then the client should
maintain testing over the design and implementation of the solution and document their daily
use of the solution. On-going maintenance of the technology solution should follow the
client's formal change management process and controls.

3.4. Control Considerations


3.4.1. Business Process Variables
o
The challenge to our clients is that they either do not have the necessary
time and staffing resources to identify and document the segregation of duties rules
applicable to the company or they underestimate the commitment required.
o
Not only should specific SoD issues be addressed, but clients should
look to identify the root cause of these issues.
o
RBAC (Role Based Access Control, described further in the system
administration practice aid) is currently only applicable for self-service applications
(iTime, iExpense, iProcurement, etc).
o
Each client's Segregation of Duties principles must be considered in light of
the client's specific business processes and risks.
3.4.2. Control Dependencies
o
Activities might be influenced by different functionalities as RBAC and the
sub functionality data entry via sub ledgers, MOAC and the hybrid usage of roles, proxy
users and delegated admin responsibilities. Also this is a very broad statement; the
practitioner should consider the mentioned functionalities, when assessing the SOD.
3.4.3. Control Limitations
o
The majority of Oracle seeded responsibilities contain SoD conflicts.
o
Clients tend to build their responsibilities based on functionality and may
make copies of the default Oracle responsibilities, with minor modifications. It's highly
likely that these revised responsibilities have SoD conflicts.
3.4.4. Testing Notes
o
For general guidance on Access and Segregation of Duties control
considerations in the context of a financial audit or an audit of internal controls over
financial reporting, refer to PwC Audit 4164 and 4164.01.
o
For a suggested list of detailed SoD principles and their associated risks,
refer to PwC GATE. GATE's standard reports contain baseline, generic rules that are
industry agnostic and should be tailored/customized for each client's environment.
o
PwC should recognise how the client manages SoD and make adjustments
to the testing strategy accordingly.
o
In complex environments such as Oracle EBS, practitioners should consider
going beyond the access approval form and consider the overarching process
management uses when deciding to approve access.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 82 of 89

o
Processes Tab Access: "AZN" menus are those menus that are associated
with the Process Navigator Tab. When testing for segregation of duties, the reports
generated from the tool will identify the menus associated with the issue.
o
Without understanding the menu being used and the implications with the
"AZN" menu, the segregation of duties analysis will appear to contain many false
positives. Practitioners should be aware of the AZN menu and help the client understand
where the excessive or conflicting access exists.
o
As many concurrent processes have the similar financial impact as the direct
entry of transactions (AutoInvoice, Automatic Journal Posting, Revenue Recognition),
they should be included in SoD analysis.
o
PwC should also expect false positives in the SoD analysis. False positives
are results in the SoD analysis that indicate where issues exist when they do not or are
simply less pervasive.
o
PwC should confirm the legitimacy of the SoD rules and test results prior to
raising issues with the client.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 83 of 89

K. Relevant Modules
1. iSetup
iSetup is a data management product that helps in automating migration and monitoring of EBS setup
data. iSetup helps in the migration of data between different instances of Oracle.
iSetup is covered in this document, as this module might influence the setup of Oracle EBS and can
be used for analyzing the overall setup of Oracle EBS. For detailed analytics refer to the iSetup User
Guide.

1.1. Usage of iSetup


iSetup is a two-part application:
o
iSetup Configurator runs on the web and provides an interactive questionnaire to
capture business requirements and configuration decisions.
o
iSetup Migrator is the load functionality that populates the application setup tables
with the detailed parameter values.
The following graph depicts the process of using iSetup to support the creation and extraction of the
transformation files, which then can be transferred to any output.

Clients could use this for migrating data between:


Production instance to another production instance
Test or development environment to the production environment

1.2. Control Considerations


2.1.1. Business Process Variables
o
None
2.1.2. Control Dependencies
o
None
2.1.3. Control Limitations
o
None
2.1.4. Testing Notes
o
The reports, either standalone for a single instance, or comparison
between multiple instances can be used to retrieve and compare setup data.
PricewaterhouseCoopers-For internal use only
2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 84 of 89

o
The history of executed migrations can be used for analytics of the
change management process.

2. AME
Oracle Approvals Management (AME) is a self-service Web application that enables client to define
business rules governing the process for approving transactions in Oracle applications.
AME is covered in this document, as the usage of AME might impact the analytics of approval
processes and controls based on approvals. For detailed analytics refer to the Oracle AME user
guide. Oracle AME is also integrated with Oracle user management.

1.1. Usage of AME


The purpose of Oracle Approvals Management (AME) is to define approval rules that determine the
approval processes for Oracle applications. The following graphic illustrates the typical approval
process used in an organization.

An approval rule is a business rule that helps determine a transaction's approval process such as
who gets to approve certain transactions, dollar amount limits, and notification routing. Rules are
constructed from conditions and actions.
For example an approval rule can be as follows:
If the transaction's total cost is less than 1,000 USD, and the transaction is for travel expenses, then
get approvals from the immediate supervisor of the person submitting the transaction. Otherwise get
approval from the company travel manger.
Oracle Approvals Management enables business users to specify the approval rules for an
application without having to write code or customize the application. Once the rules are defined for
an application, the application communicates directly with AME to manage the approvals for the
application's transactions. Client can define rules to be specific to one application or shared between
different applications. As AME recalculates the chain of approvals after each approval, a transaction
is assured to be approved under the latest conditions, regardless of organizational changes, changes

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 85 of 89

to transaction values, rule changes, or currency conversions. AME has built-in testing features that
enable you to confirm the behavior of new or edited business rules before live execution.

1.2. Control Considerations


2.1.1. Business Process Variables
o
Many clients might rely on manual approvals or sign-offs sheets as their
key controls over account procedures. From an efficiency, effectiveness perspective,
PwC practioners should be on the look out for areas of process improvement where a
manual approval process can be automated in Oracle.
2.1.2. Control Dependencies
o
None
2.1.3. Control Limitations
o
None
2.1.4. Testing Notes
o
The use of AME gives auditors the ability to test the approval process
systematically and gain comfort over established key controls.

L. Forms that accept SQL entry


To improve flexibility, some forms allow users to enter SQL statements. These forms are typically used
during the initial setup of the system. The table below lists the Forms that allow the user to edit code, add
code or otherwise affect executable code.
Function Internal Name

Function Display
Name
Define Alert

Form Internal
Name
ALRALERT

Alerts

FND_FNDCPMCP_SYS

Concurrent Programs
(System Administrator
Mode)

FNDCPMCP

Define Concurrent Program

FND_FNDCPMPE

Concurrent Program
Executables

FNDCPMPE

Define Concurrent Program


Executable

FND_FNDFFMDC

Descriptive Flexfield
Segments

FNDFFMDC

Define Descriptive Flexfield


Segments

FND_FNDFFMVS

Flexfield Value Sets

FNDFFMVS

Define Value Set

FND_FNDPOMPO

Profile Options

FNDPOMPO

Define User Profile Option

FND_FNDSCAPP

Applications

FNDSCAPP

Register Applications

FND_FNDSCDDG

Data Groups

FNDSCDDG

Define Data Group

ALR_ALRALERT

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Form Display Name

Page 86 of 89

Function Internal Name


FND_FNDSCMOU

Function Display
Name
ORACLE Usernames

Form Internal
Name
FNDSCMOU

Register ORACLE IDs

PSB_PSBSTPTY

Attribute Mapping Details

PSBSTPTY

Attribute Mapping Details

MSDCSDFN

Define Data Stream

MSDCSDFN

Define Data Stream

MSDCSDFA

Custom Stream
Advanced Setup

MSDCSDFA

Custom Stream Advanced Setup

MSD_MSDAUDIT

Audit Statements

MSDAUDIT

Audit Statements

JTFRSDGR

Define Dynamic
Resource Groups

JTFRSDGR

Define Dynamic Resource


Groups

JTFBRWKB

Business Rule
Workbench

JTFBRWKB

Business Rule Workbench

ONT_OEXPCFVT

Validation Templates

OEXPCFVT

Define Validation Templates

ONT_OEXDEFWK,
QP_OEXDEFWK

Defaulting Rules,
Attribute Mapping

OEXDEFWK

Defaulting Rules

JTFTKOBT

Objects Meta-data

JTFTKOBT

Foundation Objects

JTF_GRID_ADMIN

Spreadtable Metadata
Administration

JTFGRDMD

Spreadtable Metadata
Administration

JTFGDIAG

SpreadTable Diagnostics

JTFGDIAG

SpreadTable Diagnostic Form

JTFGANTT

JTFGANTT

JTFGANTT

JTFGANTT

WMS_WMSRULEF

Define WMS Rules

WMSRULEF

Define WMS Rules

QP_QPXPRFOR

Create Pricing Formulas

QPXPRFOR

Define Pricing Formulas

QP_QPXPTMAP

New Attribute Mapping

QPXPTMAP

Attribute Mapping

GMAWFPCL_F

Workflow Process
Configuration Framework

GMAWFPCL

Workflow Process Configuration


Framework

GMAWFCOL_F

Workflow Activity
Approval Configuration
Framework

GMAWFCOL

Workflow Activity Approval


Configuration Framework

AME_WEB_APPROVALS

Approvals Management

TBD

TBD

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Form Display Name

Page 87 of 89

Function Internal Name

Function Display
Name

Form Internal
Name

Form Display Name

PERWSAPI

PL/SQL tester

PERWSAPI

PL/SQL tester

FFXWSMNG

Write Formula

FFXWSMNG

Write Formula

FFXWSDFF

Define Function

FFXWSDFF

Define Function

FFXWSBQR

Create Quickpaint Inquiry

FFXWSBQR

Create QuickPaint Inquiry

PAYWSDAS

Define Assignment Set

PAYWSDAS

Define Assignment Set

PAYWSDYG

Dynamic Trigger
Maintenance

PAYWSDYG

Dynamic Trigger Maintenance

PERWSSCP

Define Security Profile

PERWSSCP

Define Security Profile

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 88 of 89

M. Glossary
1. Key Oracle Functionality
A number of terms that are used within the Oracle System Administration module are listed below
with an associated definition.
Term

Description

Alert

A mechanism that checks your database for a specific exception condition. An alert is
characterised by the SQL SELECT statement it contains. A SQL SELECT statement
tells the application what database exception to identify as well as what output to
produce for that exception.

Alert Action

An action the alert is to perform. An alert action can depend on the output from the
alert. An action can include sending an electronic mail message to a mail ID, running
an Oracle Applications program, running a program or script from your operating
system, or running a SQL script to modify information in your database.

Audit Trail

Audit Trail tracks which rows in a database table(s) were updated at what time and
which user was logged in using the form(s). Several updates can be tracked,
establishing a trail of audit data that documents the database table changes.

Concurrent
Manager

A mechanism that runs concurrent programs. A manager operates during the time and
days defined by a work shift. A manager can run any concurrent program, or be
specialised to.run only certain kinds of programs.

Concurrent
Program

A program that runs concurrently (at the same time) as other programs. Concurrent
programs run as background processes, while you continue to work at your terminal.

Concurrent
Request

A command to start a concurrent program. An example of a concurrent request is a


command to generate and print a report.

Data Group

A data group is a group list of Oracle Applications and the Oracle ID each application is
assigned to. An Oracle ID grants access privileges to tables in an Oracle database.

Menu

A hierarchical arrangement of application functions (forms) that is displayed within the


main navigate window

Request
Security
Groups

Defines the concurrent programs and reports, including requests and request sets that
might be run by an application user under a particular responsibility.

PricewaterhouseCoopers-For internal use only


2007 PricewaterhouseCoopers. All rights reserved.

Internal use only -- U. S. Firm use only

Page 89 of 89

You might also like