Professional Documents
Culture Documents
Oracle
System Administration
Release 12
Page 1 of 89
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
K. RELEVANT MODULES...............................................................84
1. iSetup................................................................................................................................................84
2. AME..................................................................................................................................................85
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.
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.
Page 4 of 89
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.
Page 5 of 89
Page 6 of 89
Optional
Optional
Oracle
Database
Server
Page 7 of 89
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.
Page 8 of 89
The following picture depicts the structure of the Oracle EBS file system:
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
12
2007
Latest release.
Functionality Changes
Practice Aid
and Work
Program
Applicability
No
OASIS/ GATE
No
OASIS
-Enhanced performance
-Web based
Yes
GATE
Yes
GATE
Yes
GATE
Yes
GATE
Compatibility
OASIS
Page 9 of 89
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.
Page 10 of 89
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.
Page 11 of 89
Description
Active
Responsibilities
and
Users
(Application
Object Library)
Active Users
All the usernames that are both currently active and have at least one active
responsibilities
CP SQL*Plus
Expire
FND_USER
Passwords
Workflow
Directory
Services
User/Role
Validation
(Application
Object Library)
Page 12 of 89
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.
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 Inventory
Oracle Payroll
Page 14 of 89
Owner
Oracle Service
Name
Territory
Oracle Service Item
Training Resources
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
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.
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.
Page 16 of 89
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.
Flexfield Segments
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.
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.
Page 20 of 89
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.
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.
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.
Application
User
Responsibility
Form
None / blank
User
Responsibility
Form
Page 23 of 89
Level
Responsibility
None / blank
User
Responsibility
Form
None / blank
User
Responsibility
Form
Form
Page 24 of 89
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.
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.
None
Page 26 of 89
Page 27 of 89
Responsibility
Form
Function
Submenu Access
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.
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:
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:
Page 31 of 89
menu.
Page 32 of 89
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.
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
Page 35 of 89
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:
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.
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
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:
Page 40 of 89
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
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.
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.
Page 43 of 89
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".
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.
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
Sign on Password
Hard to Guess
System
Profile Option
not set
Sign on Password
Length
System
Profile Option
Sign on Password No
Reuse
System
Profile Option
not set
Password Expiration
User Record
not set
Password case
sensitivity
Profile option
disabled
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
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.
Page 48 of 89
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.
Page 49 of 89
System 1
Users
Responsibilities
p
ers
rou
Us
sG
ce s
Ac
Us
Ac
ers
ce
ss
Gro
up
IdM
Oracle ERP
System 2
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.
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.
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.
Page 53 of 89
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.
Page 55 of 89
Features
Technology/Infrastructure
management
System diagnostics
System Administrator
By default, no auditing is enabled for the system administration / support responsibilities. Please see
the Auditing section of this Practice Aid for further information.
Page 56 of 89
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.
Page 57 of 89
After selecting the "Run" icon, the user is then prompted with the required information to launch the
process:
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.
Page 58 of 89
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.
Page 59 of 89
Modify Personalisation
The User ID who requests a concurrent program or report to be run will have their User ID assigned
and tracked within the application.
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.
Page 61 of 89
Page 62 of 89
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.
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.
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.
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.
Page 65 of 89
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.
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.
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.
Page 69 of 89
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.
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.
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.
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.
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.
Page 71 of 89
custom query made by the client will be required to obtain profile options set at the user
level.
Setting
APPS_SSO_LINK_T
RUTH_SRC
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
Page 72 of 89
Profile Option
Setting
Available Options
Relevant
FND_EXPORT_ALL_
BLOCK_DATA
Yes, No
TBD
FND_FIXED_SEC_K
EY
User Defined
FND_FIXED_KEY_E
NABLED
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
Page 73 of 89
Profile Option
Setting
Available Options
Relevant
OAM_ENABLE_SYS
TEM_ALERT
System Alert
Enable Level
System Alert
Enable Level
SIGNON_PASSWOR
D_CASE
Signon Password
Case
Enables or
Disables Password
Case Sensitivity
Insensitive, Sensitive
A&C
SIGNON_PASSWOR
D_CUSTOM
Signon Password
Custom
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
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
Page 74 of 89
Profile Option
Setting
FND_DIAGNOSTICS
FND: Diagnostics
FND_HIDE_DIAGNO
STICS
Hide Diagnostics
menu entry
UNIQUE:SEQ_NUMB
ERS
Available Options
Relevant
Yes, No
A&C
Yes, No
A&C
Sequential
Numbering
Sequential
Numbering
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
A&C
FA_WF_GENERATE
_CCIDS
FA WF
GENERATE
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
Enabled/disable
access to
override violation
is restricted or
not allowed at all
Page 75 of 89
Profile Option
Setting
Available Options
Relevant
(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
Yes, No
A&C
Page 76 of 89
Profile Option
Setting
Available Options
Relevant
Page 77 of 89
Segregation of duties and restricted access is a multidimensional challenge within Oracle EBS
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:
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.
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.
Page 79 of 89
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.
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
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.
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.
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.
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.
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
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.
Function Display
Name
Define Alert
Form Internal
Name
ALRALERT
Alerts
FND_FNDCPMCP_SYS
Concurrent Programs
(System Administrator
Mode)
FNDCPMCP
FND_FNDCPMPE
Concurrent Program
Executables
FNDCPMPE
FND_FNDFFMDC
Descriptive Flexfield
Segments
FNDFFMDC
FND_FNDFFMVS
FNDFFMVS
FND_FNDPOMPO
Profile Options
FNDPOMPO
FND_FNDSCAPP
Applications
FNDSCAPP
Register Applications
FND_FNDSCDDG
Data Groups
FNDSCDDG
ALR_ALRALERT
Page 86 of 89
Function Display
Name
ORACLE Usernames
Form Internal
Name
FNDSCMOU
PSB_PSBSTPTY
PSBSTPTY
MSDCSDFN
MSDCSDFN
MSDCSDFA
Custom Stream
Advanced Setup
MSDCSDFA
MSD_MSDAUDIT
Audit Statements
MSDAUDIT
Audit Statements
JTFRSDGR
Define Dynamic
Resource Groups
JTFRSDGR
JTFBRWKB
Business Rule
Workbench
JTFBRWKB
ONT_OEXPCFVT
Validation Templates
OEXPCFVT
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
JTFGANTT
JTFGANTT
JTFGANTT
JTFGANTT
WMS_WMSRULEF
WMSRULEF
QP_QPXPRFOR
QPXPRFOR
QP_QPXPTMAP
QPXPTMAP
Attribute Mapping
GMAWFPCL_F
Workflow Process
Configuration Framework
GMAWFPCL
GMAWFCOL_F
Workflow Activity
Approval Configuration
Framework
GMAWFCOL
AME_WEB_APPROVALS
Approvals Management
TBD
TBD
Page 87 of 89
Function Display
Name
Form Internal
Name
PERWSAPI
PL/SQL tester
PERWSAPI
PL/SQL tester
FFXWSMNG
Write Formula
FFXWSMNG
Write Formula
FFXWSDFF
Define Function
FFXWSDFF
Define Function
FFXWSBQR
FFXWSBQR
PAYWSDAS
PAYWSDAS
PAYWSDYG
Dynamic Trigger
Maintenance
PAYWSDYG
PERWSSCP
PERWSSCP
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
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
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.
Page 89 of 89