Oracle R12 SA Practice Final_comments_v1

Practice Aid

OracleSystem Administration

Release 12

PricewaterhouseCoopers-For internal use only© 2007 PricewaterhouseCoopers. All rights reserved. of 90

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

Oracle System Administration Practice AidTable of Contents

A. INTRODUCTION............................................................................................31. Engagement Tools.............................................................................................................................. 3

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

C. ORACLE APPLICATION HIGHLIGHTS.............................................71. Application Structure........................................................................................................................... 72. Oracle Application Release History.....................................................................................................93. Overview of System Administration...................................................................................................10

D. FLEXFIELDS.............................................................................141. Flexfield Types.................................................................................................................................. 142. Key Flexfield Components................................................................................................................163. Descriptive Flexfield Components.....................................................................................................21

E. AUDITING................................................................................231. Oracle Auditing Methods...................................................................................................................232. Non-Audit based Change Control......................................................................................................25

F. END USER ACCESS...................................................................261. Responsibility and Security Group Management...............................................................................262. User Management............................................................................................................................. 383. Password Management..................................................................................................................... 474. Identity Management......................................................................................................................... 505. Multi organization access control......................................................................................................53

G. APPLICATION SUPPORT RESPONSIBILITIES AND USERS..............571. Support Responsibilities.................................................................................................................... 572. Application Support User IDs............................................................................................................653. APPS Database ID............................................................................................................................ 65

H. SYSTEM PROFILE OPTIONS.......................................................711. Site-Level.......................................................................................................................................... 712. Application-Level............................................................................................................................... 713. Responsibility-Level.......................................................................................................................... 714. User-Level......................................................................................................................................... 725. Key Profile Options............................................................................................................................ 73

I. SEGREGATION OF DUTIES CONCEPTS.........................................79

J. RESTRICTED ACCESS/SEGREGATION OF DUTIES..........................811. Application Setups............................................................................................................................. 812. Standing Data.................................................................................................................................... 813. Segregation of Duties........................................................................................................................ 81

K. RELEVANT MODULES................................................................851. iSetup................................................................................................................................................ 852.AME................................................................................................................................................... 86

L. FORMS THAT ACCEPT SQL ENTRY..............................................87

M. GLOSSARY..............................................................................901. Key Oracle Functionality................................................................................................................... 90



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 ToolsThe 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 Oracleo 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; ando Do not present all possible key controls and do not represent the minimum nor maximum

level of key controls that must exist. o May have particular functionality or controls referenced as "key". This term indicates that

this control / functionality might be important to the client's control environment. However, the identification of a key control for a client's environment will vary based on the client's unique risk circumstances, control environment and / or the client's use of the application.

This Practice Aid and its associated tools are based on a standard installation of the ERP package. Clients often customize their applications. Since each ERP implementation is unique, our work should be based on an understanding of the client's actual systems and processes, as implemented, not on a generic/sample process or system configuration.

Because inherent functionality and controls can be affected by system customizations, practitioners should discuss any customizations and the approach to testing inherent functionality with engagement management.

Each practice aid is specifically written for Oracle Release 12. Use with any other versions should be done with careful consideration, as there are differences between each Oracle release.

1.1. Practice Aid PwC's Oracle Practice Aids are documents designed to give a user a broad understanding of Oracle's associated applications, their functionality, and control considerations. These documents are not intended to provide comprehensive general guidance on this process in non-Oracle environments. 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 ApproachThe 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 SetupsIn 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 DataWithin 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. TransactionsThis 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 DutiesThis 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.



http://www.oracle.com/technology/index.html

1.2. Work ProgramThe Work Program outlines the typical automated controls within the Oracle application. For each control, this document provides a typical control description, business risk, control objective, financial statement assertions, information processing objectives, Oracle Application navigation path, validation procedures, and expected results. Each processes' work program is specifically designed for a particular release of the Oracle Application.

For the purposes of an audit of financial statements, an audit of internal controls over financial reports or an integrated audit, teams should consider those controls which have been classified as Financial in nature. The work program is currently available through the Knowledge Gateway in the US (accessible through Knowledge Curve) or Guardian (http://guardian.pwcinternal.com) in other territories.

1.3. GATEOracle 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.



http://guardian.pwcinternal.com/

B. Oracle Engagement Considerations Practitioners may want to consider the following items during an audit of financial statements, an audit of internal controls over financial reporting, or a consulting non-attest review of the Oracle application.

1) Determine which version of the software your client is using. Check the version against the compatibility table in the "Application Highlights" section of this Practice Aid, to ensure the appropriate Practice Aid is utilized.

2) Inquire of the client's business owners and system administrator if any customizations to the standard software have been made. Request a list of these customizations to assess the effect.

3) Confirm the number of instances (separate Oracle databases environments) that the client maintains.

4) Confirm the number of Ledgers, Operating Units and Modules in scope within each Oracle instance.

5) Interview the systems administrator or other suitable IT personnel to gain knowledge and understanding of the system design (linkage with external applications, databases and network).

6) Ascertain the approximate size of the user population and number of responsibilities.7) Approach the security manager and request that a user is created for the practitioner. This role/

group should enable the practitioner to have read-only access to all menus and programs in the in-scope Oracle application.

8) Discuss the relevant business processes with the client, ensuring an understanding of the application version, functionality, and reports (customized or normal) that the client relies upon.

9) A fresh copy of the Practice Aid and its related Work Program(s) should be downloaded for each new engagement to ensure the most up-to-date version is used for tailoring.

10) Based upon the knowledge gained regarding the client's environment, tailor the Work Program to match the client's business processes and specific risk profile.

11) When documenting any test results and resulting risks, consider both the mitigating/compensating controls, and manual processes that may impact an automated environment.

12) If needed, contact the key contacts shown in the Contacts section of this for additional guidance regarding complex technical situations that may arise during the engagement.



C. Oracle Application Highlights

1. Application StructureThe Oracle E-Business Suite (EBS) Enterprise Resource Planning (ERP) system is an integrated software solution that runs off an Oracle database instance. An ERP consists of applications or “modules”. Most modules hold transactional data for each business process area (financials, supply chain management, customer relationship management, manufacturing, human resources, etc.). Some modules are used for system-wide support. Each module is linked to each other via the database; therefore, information is seamlessly integrated.

Users access functions either via a forms-based model, or in the case of Self-Service modules, a web-based model via the End User Tier mentioned in further detail below.

The Oracle EBS system is a three-tier system that consists of the End Users Desktop, Application Servers and Database Servers.

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

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



1.2.1. Web Server (Oracle Portal)The Portal manages access to Oracle ‘Forms’ (note that this is the definition Oracle uses to describe screens or windows displayed on the monitor).

1.2.2. Forms ServerThe forms server stores the format of the Oracle forms. This is also where the application and some administrative functions reside (i.e. entering and posting of journal entries). The forms server interfaces directly to the Database tier.

1.2.3. Concurrent ProcessingThe Concurrent Processing's primary purpose is to load balance the system and enhance performance. Concurrent processing is managed through a scheduling system that controls when updates occur. Along with the scheduling system, concurrent processing can prioritize activities based on transaction importance. It is also used to provide batch processing capability.Reports and other requests are executed by this server, which interfaces directly to the Database tier.

1.2.4. Administration ServerThis server interfaces directly to the Database tier and provides operational support such as backup, recovery, startup and shutdown. In addition, it provides statistical information on system use and performance.

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

Since the Oracle DBMS contains all Oracle-related financially-significant data, the Oracle DBMS is considered the highest risk of the three tiers.

1.4. File System

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

The base configuration directories APPL_TOP and ORACLE_HOME can be read-only to support change control. With instance-specific data files separated into dedicated directories, upgrades and migrations should be more easily controlled. Common application files are not touched for instance-specific modifications.

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



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

2. Oracle Application Release HistoryVersion Rele

ase date

Market Prevalence Functionality Changes Practice Aid and Work Program Applicability

OASIS/ GATE

Compatibility

10.7 1998 -Rare. -Limited support by Oracle corporation.

-Limited system audit capabilities-Full character based

No OASIS

11.0.3 1999 -Limited. -Full support by Oracle.

-Corrected Y2K deficiencies-Included client / server environment-Introduced GUI Interface

No OASIS

11i Environment11.5.5, 11.5.6

2000 -Limited Use-Supported by Oracle

-Enhanced performance-Web based

Yes GATE

11.5.7, 11.5.8, 11.5.9

2002 (5.7)

-11.5.7 & 5.9 in broad use-11.5.8 use limited (buggy)

-Expansion in Web based and workflow functionality

Yes GATE

11.5.10 2005 Broad use -Significant changes in System Administration module, including limited introduction of Role Based Access Control.

Yes GATE

12 2007 Latest release. -Significant changes in System Administration module, General Ledger, and infrastructure.

Yes GATE



3. Overview of System AdministrationThe Application Object Library (AOL) module is the gateway to all functionality in Oracle applications. The following key functions are performed within the AOL module:

Flexfields Auditing and Change Control User Management System Profile Options System Reports

NOTE: Internally at PwC, we refer to the AOL and System Administration module together as System Administration (SA).

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

3.2. Auditing and Change ControlAuditing can be enabled to monitor changes made either through the application or directly to the database rows. In addition, the application can be enabled to monitor successful and unsuccessful user logons and the responsibilities, terminals, or forms accessed by a user are noted.

Change control monitors who requested the change, the expected results from the change, the testing procedures and their outcomes, and the final approval by management to implement the change in production. A record of change control includes who, what, when, where and why. Please see the Auditing section of this Practice Aid for further discussion.

The iSetup functionality available from 11i can support the change management process. It enables administrators to extract, transform and migrate setup data in a controlled way and compare setup data with available standard reports.

3.3. User Management In addition to the AOL module, the System Administration module is used to store the Oracle responsibility (user profile) definitions. There are various objects/settings assigned to a responsibility within the application that allow a User ID the ability to perform activities within Oracle (i.e. data groups, menus, functions and request security groups). The application comes with a number of default responsibilities, but a company can customize responsibilities to suit their business needs and restrict access to various tasks as appropriate.

Responsibilities can be defined to allow access to the following areas: Specific applications/modules. Ledger name/Legal entity. Restricted list of windows. Restricted list of functions. Reports in specific application.

A diagram outlining the relationship between users, responsibilities, functions and modules is below:



There is no default user access that is granted just by being given an account in Oracle EBS. The security administrator (through the System Administrator responsibility) must assign a User ID with responsibilities for the user to be granted abilities to perform tasks/functions within Oracle.

Due to the newly introduced functionality multi-organizational access control (MOAC) functionality, users can access multiple operating unit (OU) data either within or across business groups from a single responsibility. Using MOAC, multiple operating units are assigned to a security profile. This security profile is then assigned either to responsibilities or directly to users. A typical usage would be responsibility in a shared service centre, which serves different operating units. For further details on MOAC please refer to the section on Multiple Organization Access Control.

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



User 1 User 2

GL Controller AR InquiryAP Payment Supervisor

Oracle Role (available in 11.5.10)

Oracle Responsibility

Oracle End Users

Oracle Forms / Functions

GL Forms / Functions

AR Forms / Functions

AP Forms / Functions

Oracle General Ledger

Oracle Accounts Payables

Oracle Accounts

Receivables

Oracle Modules

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

Reports Description

Active Responsibilities and Users (Application Object Library)

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

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

CP SQL*Plus Expire FND_USER Passwords

Concurrent Request to Force All Applications Users To Change their Password

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

Validates the user/role information in Workflow Directory Services



Sample report: Active Responsibilities and Users Report



D. FlexfieldsFlexfields 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 TypesThere 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. sub-fields) for which data entry and validation procedures may be easily completed without programming.

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

Owner NameOracle Assets Asset Key Flexfield

Category FlexfieldLocation Flexfield

Oracle General Ledger Accounting Flexfield (changes within the Flexfield)Oracle Human Resources Grade Flexfield

Job FlexfieldPersonal Analysis Flexfield

Oracle InventoryPosition FlexfieldSoft Coded KeyFlexfieldAccount AliasesItem CatalogsItem Categories

Oracle PayrollSalesOrdersStock LocatorsSystem ItemsBank DetailsCost AllocationPeople Group

Oracle Receivables (Penaki)Oracle Service

Sales Tax LocationTerritory



Owner NameOracle Service Item

Oracle Training Administration 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.

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

1.2. Descriptive FlexfieldsSimilarly, descriptive flexfields provide a flexible way for Oracle to provide configurable "expansion space" or additional fields in forms. A descriptive flexfield appears on the form i.e. screen as a two-character-wide text field with square brackets [ ] as its prompt, or as context-sensitive fields that appear only when needed.

The following screenshot illustrates a descriptive flexfield called “Reconciliation Headers” used to capture additional data that would not normally be required in a journal entry window.



Code Combination

SegmentsSegment Values for Account Segment

http://www.oracle.com/technology/index.html

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

1.3. Control ConsiderationsRefer to each module's practice aid for control considerations pertinent to that's module's specific flexfields.

2. Key Flexfield Components2.1. Flexfield Structure

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



Each Key flexfield can be set with the following configurations.

2.1.1. Freeze Flexfield DefinitionsOnce the structure's setup has been completed (or modified), the flexfield definition must be frozen and saved. These actions cause flexfields to compile automatically in order to improve on-line performance.

2.1.2. Enabling Flexfield StructuresThe Enabled check box is checked so that structures may be used in key flexfields. Structures cannot be deleted from this window because they are referenced elsewhere in the system, but they can be disabled at any time. A structure must be enabled before it can be used.

2.1.3. Segment SeparatorThis character is used to separate flexfield segment values or descriptions whenever the application displays concatenated segment values or descriptions. The available values are

2.1.4. Cross-validation rulesThe Cross-Validate Segments check box is selected if clients want to cross-validate multiple segments using cross-validation rules. Cross-validation rules are used to define valid combinations using the Cross-Validation Rules window. This box is unchecked if clients want to disable any existing cross-validation rules. For a detailed discussion of cross-validation rules in the context of the General Ledger key accounting flexfield, refer to the General Ledger practice aid. The cross-validation concepts discussed there apply to other key flexfields.

2.1.5. Freeze Rollup GroupsUsed to indicate whether rollup group definitions are to be frozen. If this is enabled, users are prevented from modifying rollup groups using the Segment Values form. Refer to the General Ledger practice aid for more information on rollup groups.

2.1.6. Allow Dynamic InsertsDynamic Inserts are used for General Ledger Key Flexfield to allow dynamic insertion of new valid account code combinations into the GL code combinations table. For more information on Dynamic Insertion, please refer to the General Ledger Practice Aid.

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



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

2.3. Flexfield SegmentsA segment is a single sub-field within a flexfield. They can also be thought of as "containers" for segment values. Flexfield Segments can have two components, the segment definition and a segment qualifier.

2.3.1. Flexfield Segment DefinitionFor a key flexfield, a segment's definition usually describes a particular characteristic of the entity identified by the flexfield. In the accounting flexfield each segment is separated by a hyphen and represents a different characteristic, in the screenshot below the different segments are Company, Department, Account, Sub-Account, and Product.



Flexfield Segments

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 QualifiersA 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.



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

2.4. Flexfield Segment Values There are 3 key concepts to consider regarding Flexfield Segment Values: Definition of Segment Values Segment Value Qualifiers Segment Value Combinations

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



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

It is easy to confuse the two types of qualifiers. A flexfield qualifier is used by the whole flexfield to tag its pieces i.e. segments, and a segment qualifier is used to tag its values and is only applicable to the Oracle General Ledger accounting flexfield.

Because the GL Accounting Flexfield is the only Oracle Applications key flexfield that uses the parent, rollup group, hierarchy level and segment qualifier information illustrated above, clients need only enter this information for values that are associated with the Accounting Flexfield. For more information on such account hierarchies, refer to the General Ledger practice aid.


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



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 context–sensitive, that you can decide to use in a descriptive flexfield structure. A global segment is a segment that always appears in the descriptive flexfield pop–up window, regardless of context (any other information in your form). A context–sensitive 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.




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

1. Oracle Auditing Methods1.1. Activity Based Auditing

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

Level Profile Option Value Audit Trail ImpactSite None No global auditing is enabled to track when users sign-

on to the system.

User Global auditing is enabled to track when users sign-on to the system. The size of the audit trail is dependent on the active user population.

Responsibility Global auditing is enabled to not only identify when users sign-on to the system but also the responsibilities selected. At a minimum, the audit trail will be twice the size of the audit trail created by selecting the value user.

Form Global auditing is enabled that identifies the forms / screens the user accesses while signed on in the system. The size of the audit trail created by this setting (site/form) will be significant.

Application None / blank No auditing is specifically enabled to track when users sign-on to the system. Oracle will default to the site-level value.

User Auditing for the specific application is enabled to identify which users access that application through any responsibility.

Responsibility Auditing for the specific application is enabled to identify which users and responsibilities access the application.

Form Auditing is enabled that identifies the forms / screens the user accesses within the application. The size of the audit trail created by this setting (site/form) will vary



Level Profile Option Value Audit Trail Impactbased on the application selected and the amount of activity in that application.

Responsibility None / blank No auditing is specifically enabled to track when responsibilities are accessed. Oracle will default to the application and site-level values.

User Auditing for the specified responsibility is enabled to identify which users access that responsibility.

Responsibility At the responsibility level, this setting appears to be redundant with the User value.

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

Form None / blank No auditing is specifically enabled to track when a specified form is accessed. Oracle will default to the responsibility, application and site-level values.

User Auditing is enabled that identifies which user access a specified form.

Responsibility Auditing is enabled that identifies which responsibility via any user accesses a specified form.

Form At the form level, this setting appears to be redundant with the Responsibility value.

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

1.3. Control Considerations

1.3.1. Business Process Variableso Oracle's auditing functionality is generally not enabled at clients because it consumes

significant computing resources.o A balance between monitoring too much and too little should be established. Clients who

have set Sign-On: Audit Level at the site level with a value of Form is recording voluminous information that probably is not providing the audit or control benefit intended. Clients using this setting have not performed a risk-based assessment to determine the sensitive areas, users and responsibilities within EBS that should be monitored.

o For the most efficient auditing, a risk-based approach should be used to identify the high risk transactions and/or users.



1.3.2. Control Dependencieso None

1.3.3. Control Limitationso None

1.3.4. Testing Noteso PwC staff reviewing Oracle-based auditing should consider the client's requirements for

monitoring. Oracle-based auditing should compliment those requirements.o Additionally, PwC staff should consider the relationship between activity-based auditing

and the data-based auditing that the client has enabled, if any.

2. Non-Audit based Change ControlWithout the auditing feature turned on, Oracle only maintains a minimal audit trail. When auditing is not enabled, only the record creation date, record creator and the record's last modification date are recorded. Oracle does not automatically store any changes made between the creation of the record and the last update, and Oracle does not record what data was changed during the last update (only that the form was changed).

Because change control is not maintained within the application, it can only be controlled manually or via a third-party application. Since a comprehensive list of changes to the application is not available within the application; clients often use a third party tool to track versions and movement of the code. Tools and controls used to support a change control environment could include: Application versioning using tools such as PVCS from Serena, or Oracle Enterprise Manager Change request / ticket management using tools such as Remedy from BMC. Operating system security controlling access to production files and folders. Server change monitoring tool such as Tripwire from Tripwire, Inc.

Oracle EBS: This audit trail only includes a time/date stamp and the user responsible for the last update to the record. This audit trail will show a history of changes or the elements that were changed, only when the last update occurred and who performed that update. Please see the Auditing section in this Practice Aid for further information.

Related topics are the new file structure and the usage of iSetup. iSetup is a data management product that helps in automating migration and monitoring of EBS setup data. iSetup helps in the migration of data between different instances of the EBS functionality. However iSetup might not be used widely in the marketplace, especially for this purpose.

iSetup is a two-part application:

iSetup Configurator runs on the web and provides an interactive questionnaire to capture an organization's business requirements and configurations.

iSetup Migrator is the load functionality that populates the application setup tables with the requested parameter values.

Configuration/Functionality Changes with iSetup

iSetup Migrator: Hierarchical Selection SetsHierarchical Selection Sets capture functional dependencies between items scheduled for migration. iSetup is able to remember and enforce these dependencies when migrating configurations / data.



Upload ExtractsNew functionality includes the ability to upload an iSetup Extract from the user’s desktop. Once uploaded successfully, the extract can be re- used for reporting or the load process.

Comparison ReportingiSetup now allows user to compare the snapshot files. These snapshot files can be data from a single instance across a timeline or from two different instances. Users can view the generated report online or download the report in PDF, RTF or Excel format.


2.1.1. Business Process Variableso None



2.1.4. Testing Noteso None

F. End User Access

1. Responsibility and Security Group Management

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

The following illustration identifies and briefly describes the elements required to create a responsibility.



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

Request Group --Name - selected request security group associated with the responsibilityApplication - The module used in conjunction with the specified request security group.Menu -- selected main

menu for the responsibility.

Menu Exclusions, Excluded Items, Securing Attributes -- additional configurable elements that further restrict the responsibility's access

Responsibility Name -- Unique User-created name for the responsibilityApplication -- selected application (module) in which the responsibility residesResponsibility Key -- User-created

*Effective Dates -- range of dates between which the responsibility is active.

From a functional perspective, this would be indicated by:

1.1. Forms and FunctionsMenu Functions, or functions, are the lowest level of access. A function is a part of an application's functionality that is registered under a unique name for the purpose of assigning it to, or excluding it from, a responsibility. From an end-user perspective, the function is the window (or screen) in which data is entered into the application.

Within Oracle There are two types of functions: form functions, and non-form functions. For clarity, Oracle refers to a form function as a form, and a non-form function as a sub function, even though within the database, both are just instances of functions.

Within PwC's GATE tool, a form function is called a form, and the non-form function (or sub function) is called a function. Together, these two values form the navigation path to the screen in which data is entered. For example, invoices can be entered into the Invoices (form)>Invoices (function) screen or via Invoices (form)>Invoice Batches (function).

Forms and Functions are defined within the System Administration module with the following characteristics.

1.1.1. Descriptiono Function: Users do not see this unique function name. However, this may be used when

calling your function programmatically. Also known as the "database name".o User Function Name: This name appears in the end users Navigator window. This name

is also used when assigning functions to menus. Within PwC's GATE tool, this name is called the "function".



Responsibility

Function

Form

Submenu Access

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 DescriptionFORM 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.

SUBFUNCTION Sub functions are added to menus (without prompts) to provide security functionality for forms or other functions.

JSP Functions used for some products in the Oracle Self-Service Web Applications. These are typically JSP functions.

WWW or WWK Functions used for some products in the Oracle Self-Service Web Applications. These are typically PL/SQL functions.

WWR or WWL Functions used for some products in the Oracle Self-Service Web Applications. WWJ OA Framework JSP portlet. SERVLET Servlet functions used for some products in the Oracle Self-Service Web



Form Type DescriptionApplications.

DBPORTLET Database provider portlet. WEBPORTLET Web provider portlet.

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 DescriptionResponsibility The function is controlled by the user's responsibility (RESP_ID/RESP_APPL_ID

(includes ORG_ID)). Organization The function is controlled by the user's organization (ORG_ID). Security Group The function is controlled by the user's security group (service bureau mode) None 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. MenusA 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: Sequence: Specifies where a menu entry appears relative to other menu entries in a

menu. A menu entry with a lower sequence number appears before a menu entry with a higher sequence number.



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

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

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

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

Grant: If enabled, this function is automatically enabled for the user. If this is not checked then the function must be enabled using additional data security rules.

Note: Oracle uses the term "submenu" to define any menu that is assigned to another menu. However, there is no technical distinction between a menu and submenu. However, a submenu must be defined before it can be called by another menu.

Custom menus can be created using predefined forms (i.e., form functions) and their associated menus of sub functions. However, Oracle does not recommend that a form be disassociated from its developer-defined menus of sub functions.

Outlined below is a graphic illustration of how menus are compiled:

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

The AP_APXINWKB Menu is assigned to the AP_INVOICES_ENTRY_GUI12 Menu.



The AP_INVOICES_ENTRY_GUI12Menu is assigned to the AP_INVOICES_GUI12 menu.

The AP_INVOICES_GUI12 menu is assigned to the AP_NAVIGATE_GUI12 menu.



The AP_NAVIGATE_GUI12 menu is assigned to the Payables Manager Responsibility.



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

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

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

1.4. Process Navigator TabThe first tab on an Oracle EBS form is the Functions tab. This feature contains the menus and navigation paths to the various forms and functions granted to the responsibility. The Functions tab is where users (end users and support personnel) spend a majority of their time.

The Process Navigator Tab within Oracle is a little-used feature that presents a heightened risk of segregation of duties and sensitive access violations by indirectly granting access not intended for specified users and not intentionally designed into their responsibilities. This Oracle feature is intended to give the user an overview of a business process and walk them through each step. This feature also allows support individuals a better view of the transaction and where problems might exist during troubleshooting exercises.



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

Example 2: Application Developer access to vendor management, invoice and payment 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.

The 1099 Reporting process assigned to Application Developer by default gives the user the ability to:

create vendors, process invoices, andprocess payments.

Launching these specific nodes of the process will display the appropriate forms to enter the transaction.

1.5. Control Considerations1.5.1. Business Process Variables

o Clients should have a defined process for developing and updating responsibilities. A balance between flexibility and segregation of duties should be established. Responsibility design focused solely on responsibility functionality and flexibility will introduce conflicting and excessive access. Responsibility design focused solely on segregation of duties might increase the cost of performing transactions. This increased cost is due to the additional time introduced into the business process to separate conflicting activities.

o Clients should not use seeded or default responsibilities in the production environment. The responsibilities shipped with Oracle provide excessive and conflicting access to users. Clients tend to copy seeded or default responsibilities in order to develop new ones. The risk introduced in this method of creating responsibilities is that weaknesses in one responsibility will be re-introduced in the new responsibility. For example, the Process Navigator Tab is enabled for many seeded or default responsibilities and will be enabled in new responsibilities unless the client actively manages this feature. Please refer to the Process Navigator Tab section in this Practice Aid for further discussion on this Oracle feature.

o An additional argument for not using seeded responsibilities (and even forms) is to support upgradeability. Upgrades and patches to Oracle EBS will frequently overwrite seeded functionality. This process "resets" seeded responsibilities and menus to their original configuration. Clients that modify the seeded responsibilities and menus for increased security will lose these customisations and will increase their risk of unauthorised activity being performed in Oracle EBS.

o The presence of the Process Navigator Tab does not necessarily represent a control deficiency in the client's environment. Better control practice is that the Process Navigator Tab is not enabled in any responsibility. Processes available to the responsibility can be added and removed.


1.5.3. Control Limitationso Because some concurrent processes (auto post journals, revenue recognition)

manipulate financial data, access to concurrent processes (reports) should be assigned to complement the online access granted to responsibilities. Clients should not use the "All Reports" request security group, as it contains all reports and processes, of which access could pose an increased risk of excessive access and segregation of duties violations.

o The functionality of a responsibility is independent of the naming convention of that responsibility. Responsibilities named 'view' or 'inquiry could actually update and initiate transactions. Clients should follow an appropriate naming convention so that effective responsibility management can be supported.

1.5.4. Testing Notes - o To test Security Groups using GATE: Run the GATE Responsibility Report

"Responsibilities by Request Groups" to identify the various request security groups defined and to which responsibilities they are assigned. Additionally, run the report "Reports within Request Groups" to identify which reports are associated with each request security group. A specific report focusing on the "All Reports" request security group is also available -- "All Reports Request Group"



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 Management2.1. Defining Users

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

2.1.1. User Name (required)This is a freeform text field in which the clients can enter a value. Oftentimes companies use standard a naming convention to link the Oracle user name to the individual (jsmith, etc). This is the user name the end users will enter when accessing the Oracle application.

2.1.2. Password and Password Expiration (required)The password entered in the password field is a temporary password which will expire upon first use. Once the user logs into the application for the first time, they will be required to enter a new "permanent" password. In addition, a user can be set up with a password expiration date that is used with the "permanent" password. (For more information regarding passwords, refer to the Password



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 AttributesSecuring 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. MOACThe 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.



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

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

2.2 Proxy usersFunctionality for management of the Proxy Users has been introduced covering the following functions:

o Setting up Proxy Userso Delegating Proxy User Privilegeso Acting as a Proxy Usero Running the Proxy User Report

2.2.1 UsageThere are a number of business scenarios in which users of Oracle EBS need to grant delegates the ability to act on their behalf (act as proxy users for them) when performing



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 behalfSimilarly, 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:



2.3 Role Based Access (RBAC)In Oracle EBS 11.5.10 (and earlier with patch FND.H installed), the concept of roles is introduced. Roles are a grouping of access rights at a level higher than responsibilities. Responsibilities cannot be assigned to responsibilities; however, roles can be assigned to roles, and responsibilities can be assigned to roles. Roles provide the client tools to better align access to the functional job responsibilities of their employees.

2.3.1. RBAC FunctionalityThe user's ability to view, edit and perform certain actions on an object is determined by the user's role on that object. Roles are granted to users by the owner of the object, or by someone who has the privilege to add people. A role is a collection of privileges. Roles are a convenient way to group privileges into a bundle that can later on be assigned to users. Roles are object-type specific. For example, the role Item Reviewer contains the privileges View Item and View Item People List. The user can give this role to various people on individual item instances, and they can in turn view item and view item people list.

RBAC is a layer that builds upon the data and function security models of previous releases



Delegated Administration

Administration

Administrative

procedures

Core

security

Function Security

Security

Data SecurityRole based access control

Provisioning servicesSelf service & approvals

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



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 AdministrationDelegated 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 Privilegeso Role Administration Privilegeso 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.



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

2.4. User management toolThe functionality was established in the version 11.5.10, but was not mentioned in the Practice aid.

2.4.1. Self-Service Account RequestsCommonly referred to as Self-Service Registration, self-service account requests provide a method for individuals to request a new user account. Consider a case where customers may need to register before they can purchase an item from an online store.

Once the registration process has been completed, the customer obtains both a user account and the necessary role(s) for accessing some portion of the web site in which they registered. This release of Oracle User Management provides sample Self-Service registration UIs for internal employees, and for new, external individuals. Organizations can copy these sample Self-Service registration and extend them based on their own requirements. In addition, organizations that wish to support other types of users, or capture additional information specific to their applications, are able to extend or create their own registration UIs and business logic.

Oracle User Management provides support for displaying different registration links on the login page based on the application tier login page that provides access. The registration link can contain additional parameters that are not known at design time, such as the country code. These additional parameters can be used later during the registration process. Using country code as an example, a registration process could route the approval requests to the most appropriate approver. Therefore, all those who request an account from Norway could be routed to a Norwegian account approver.

2.4.2. Request for additional accessUsers can request additional access through the Oracle User Management Access Request Tool (ART), available in the Global Preferences menu. Requests for additional access use the same Oracle User Management infrastructure and processing logic as Self Service Account Requests.

2.4.3. User Name Policies



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 VerificationOracle 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 Go back to the role assignment page and remove the assignment that is causing the violation.

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


2.5.1. Business Process Variables



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 user’s profile, but they can be end-dated to have the user’s 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 Dependencieso 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 Limitationso 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 Noteso 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.



3. Password ManagementOracle EBS provides multiple configurations to support the client's corporate security policy. The Oracle E-Business suite password configurations are as follows:

Configuration Name Type of configuration

Default Setting

Description

Sign on Password Custom

System Profile Option

not set If the client has more advanced password restrictions, custom Java classes can be used to implement these restrictions. The Sign on Password Custom profile option must be set to be the full name of the java class.

Sign on Password Failure Limit


not set This parameter setting identifies the number of failed login attempts after which an EBS login is disabled. The default is unlimited failures. Note: This profile option became available in Release 11.5.7 or via patch 2061872.

Sign on Password Hard to Guess


not set The profile option Sign on Password Hard to Guess is used to help ensure that the password is "hard to guess." A password is considered hard-to-guess if it follows these rules: The password contains at least one letter

and at least one number. The password does not contain the

username. The password does not contain repeating

characters.

Sign on Password Length


5 The minimum length of Oracle EBS user passwords can be set using the profile option Sign on Password Length.

Sign on Password No Reuse


not set The minimum number of days that a user must wait before being allowed to reuse a password can be set with the Sign on Password No Reuse profile option.

Password Expiration User Record not set Days - the number of days between password changesAccesses - the number of successful logins until the next password change

Password case sensitivity

Profile option disabled Passwords are either case sensitive or not case sensitive

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 the password to be reset, when it is actually the user name that has been forgotten, or vice versa. This type of occurrence leads to even more time being lost.



A new feature reduces the time spent in such administrative activities by implementing a login help mechanism that is easily accessed from the EBS Login Page. A user simply clicks on the "Login Assistance" link located below the Login and Cancel buttons.

On the screen that appears, you can either:o Go to the Forgot Password section, enter the correct user name and then click on the

"Forgot Password" button. You will then be emailed details of how to reset your password.

o Go to the Forgot User Name section, enter the email address associated with the account, and click on the Forgot User Name button. The user name will then be emailed to the address specified.

For security, the relevant data is stored securely in workflow tables, and the URLs employed have both an expiration time and a single-use limitation.

The identity verification process required in previous Applications releases is no longer needed. Instead, a link to a secure page is sent to the email address of the user name defined in the system. From this secure page, the user can change password immediately.

Most of these configurations are profile options, set at the site level. However, the password expiration is set for individual users. Refer to the controls consideration section for details on how this may affect the review of the Oracle environment.


3.1.1. Business Process Variableso Not all password configurations are required to be used. Strong company security

policies will generally require password controls that are met by using all of the password configuration settings in Oracle with the exception of "Signon Password Custom". This password option has the potential of replacing one or more of the other password options. If this configuration is used, a good understanding of its features is suggested.

o Password expiration parameter is associated with each user record; therefore, consistency for enforcing password changes is not supported in Oracle. This flexibility does allow the client to risk rate different users and require more or less frequent password changes based on the user's functional job responsibilities For example, an inquiry clerk ID might not have any password changes enforced; but an HR manager having access to sensitive employee records might be required to change the password every 30 days. Regardless of the client's approach, the approach for implementing password parameters should be consistent.

3.2.2. Control Dependencieso If Single Sign On (SSO) functionality is enabled, this will influence the password

management in the Oracle EBS.

3.2.3. Control Limitationso Oracle has a known weakness with regards to the strength of the encrypted passwords.

The process that Oracle uses to encrypt the passwords can be reverse-engineered resulting in the original clear-text password being disclosed. A compromise of any database account will compromise the APPS ID or any other sensitive database account. Clients tend to clone their production environment so that they may conduct application development and testing. If passwords are not changed when the production instance is cloned, individuals may be able to obtain PROD passwords within the test and development environments. If the system passwords are the same in a non-production environment as they are in production, then a compromise in one of these lower security



environments will significantly increase the risk of a compromise in the production environments.

o Usage of SSO limits the existing Oracle EBS password management. Where a SSO solution is used, the Oracle EBS password related profile options setting might be overridden by the password setting in the SSO application.

3.2.4. Testing Noteso The password weaknesses and control considerations discussed in this section are

applicable to the EBS but are found in the Oracle database. This issue should be addressed during a database review performed in conjunction with the Oracle EBS review.

o The goal is to limit access to the FND_USER table and the encrypted passwords, just as should be done with DBA_USERS. This can be accomplished by: Verifying the account APPLSYSPUB does not have SELECT privileges on

APPS.FND_USER_VIEW. Ensuring the client has changed the passwords for all Oracle Applications 11i seeded

accounts (SYSADMIN, GUEST, WIZARD, APPSMGR, etc.) even though these accounts may be already disabled.

Ensuring all seeded / default accounts, except for SYSADMIN and GUEST, are disabled.

Ensuring the client has created all new user accounts with strong and unique passwords.

Ensuring the client has limited access to the APPLSYS.FND_USER and APPLSYS.FND_ORACLE_USERID tables by all non-DBA accounts including any query-only accounts. Often an APPSREAD or similar database account is created for support purposes or end-user query use. These accounts tend to be created with SELECT ANY TABLE system privilege, which allows them access to FND_USER.

Ensuring the passwords for Oracle EBS accounts are unique across each of the environments used in change control.

4. Identity Management4.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.



4.2. Identity management within Oracle EBS

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



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 Roleso Defining Role Administration Privileges for Roleso 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.



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 identityUser 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 OIDIn 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 ApplicationsWhen 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

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





4.3.4. Testing Noteso When IdMs are in use, the practitioner should understand to what degree the IdM

solution affects the Oracle Applications and the user provisioning process.o When IdM is used, controls testing related to user management procedures should focus

more on the use of the IdM. When IdMs are in use, the practitioner should understand to what degree the IdM solution affects the Oracle Applications and the user provisioning process (e.g. the provisioning of non existing users in OEBS to most likely users).

o When IdM is used, the practitioner should understand, where the authentication starts, either via the Oracle EBS or via the OID application.

o Controls testing should also include change control and testing around the IdM as it relates to integrating with Oracle. In addition, controls testing should address gaps that might exist between the management of users in the IdM and in Oracle. For example, if users are created in the IdM and automatically sent to Oracle, is access to user provisioning in Oracle sufficiently restricted to prevent an Oracle System Administrator from creating a new user outside of the IdM? Depending on how the IdM is structured, the risk in this situation is that the IdM would never have knowledge of the new user.

o Each new or changed user ID should have a completed authorisation request form. This user ID authorisation form should clearly indicate the specific Oracle access (e.g., which Responsibility) should be granted.

o The risks vary depending on how the IdM is architected.

5. Multi organization access controlOracle Release 12 introduced for the first time the concept of Multiple Organization Access Control (MOAC). Using the new MOAC functionality, users can access multiple operating unit (OU) data either within or across business groups from a single responsibility. Using MOAC, multiple operating units are assigned to a security profile. This security profile is then assigned either to responsibilities or directly to users. Examples of MOAC's impact on Oracle Payables are provided below.

o Enter invoices or batches of invoices for one operating unit, and then seamlessly enter invoices for another operating unit

o Select invoices across operating units for payment processing within a single pay run.

This functionality can be leveraged in shared service environments to improve efficiency of data processing.



5.1. FunctionalityIn 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 Profileo MO: Default Operating Unito 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.



5.2 Profile options

MO: Security Profile This profile option needs to be set in order for the MOAC model to work. If a company wants to allow access across operating units from a single responsibility, the MO: Security Profile option needs to be defined. Within the MO: Security Profile option, there is also a Global profile option which allows a single responsibility to access across business groups (i.e. the highest level of organization in the hierarchy).

The use of the Global Security Profile is currently not recommended. (e.g., this setting would allow a user in the US Company to access the UK Company’s information.

MO: Default Operating Unit This profile options sets the default value of a specific operating unit for a given responsibility. However, if the MO: Security Profile is also defined, this default value can be changed / overridden by the user. The MO: Security Profile will allow the user to choose from a drop-down list of operating units so the default value is not enforced.

MO: Operating UnitThis profile option existed in 11i and prior. This profile option is used to establish and enforce a one-to-one relationship between responsibility and operating unit. The MO: Security Profile option should NOT be enabled for this scenario. If both MO: Security Profile and MO: Operating Unit profile options are defined for the responsibility or user, the system will grant access based on the rules defined in the MO: Security Profile option.

SLA: Enable data access set security in Sub-ledgerSee comment above

ExceptionIf a company is using journal tax functionality in GL, then the MO: Operating Unit profile option must be defined for the GL responsibility, however, this does not prevent the use of MO: Security Profile option. For access purposes, the MO: Security Profile option will still take precedence over the MO: Operating Unit.


5.3.1. Business Process Variableso Take the time to understand the reason why a client might be using the MOAC model to

grant a single responsibility access to multiple operating units. Additional considerations must be made if MO: Global Security Profile is used instead of just MO: Security Profile, as this option allows a responsibility to access data across business groups. This could be compared to a scenario where a user in the US subsidiary can access data in the UK subsidiary, which presents an even greater risk to data and transaction security. The client's IT operations should reflect a shared service environment to truly leverage the benefits of using MOAC. If there remains separate delegation within shared service (i.e. employees are assigned to handle data for a specific region), then client should consider using the traditional 11i multi-org model where a responsibility is restricted to a single operating unit.

5.3.2. Control Dependencieso Consider this functionality in relation with other enhancements like ROBAC and proxy

user.



o 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 Limitationso N/A

5.3.4. Testing Noteso 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.



G. Application Support Responsibilities and Users

1. Support Responsibilities1.1. Oracle System Administration

In releases prior to 11.5.10, Oracle would come with one system-administration ID with system-wide primary responsibility. In 11.5.10, the system support features have been separated.

Responsibility FeaturesSystem Administration Technology/Infrastructure

management System diagnostics

System Administrator Security -- User, responsibility, audit trail management

Concurrent process management System-wide application

configuration capabilities Workflow management

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

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

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



The Alert Manager can enable/disable the Alert.

The Alert Manager can modify what is being monitored.

1.4. Workflow AdministratorWorkflow is the automatic routing of documents (physical or electronic) to the individuals responsible for working on them. Workflow also provides the information required to support each step of the business cycle. The flow of physical documents in an organization is subject to errors and delays. Workflow sets timers that ensure that documents move along at a prescribed pace and that the appropriate person processes them in the correct order.

The Oracle Workflow Administrator can build, implement, and run workflows in the production environment. The Oracle Workflow Administrator responsibility grants the individual the ability to perform these activities. This powerful access, however, is generally limited to the user's own workflows. To impact system-wide workflows, the Workflow Administrator role must be assigned to the user. This access is granted through the Administration tab in Oracle Workflow. Workflow administrator capabilities are required to assign another individual this role.

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

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 workflow-related 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.

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



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

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

Hide Diagnostics menu entry; and Utilities: Diagnostics.

Business end users should not have access to this feature for the following reasons: Form Personalisation is a new feature in Oracle EBS 11.5.10 and is available in the diagnostics

area. Form Personalisation has the capability in Oracle to perform system wide customisation. This customisation ranges from protecting field-level data on a form to hiding entire forms. This feature is available in the Diagnostics area. If the client is relying on Personalisation for tuning controls, then allowing business end users the ability to access this feature will circumvent the intended control.

Many of our clients also utilise of the custom.pll programming interface to fine tune security and data protection on a form. This custom code can be disabled through the diagnostics feature.

The "examine" and "properties" capabilities under the diagnostics menu provide an individual with specific information regarding the nature of the information and data used. In some situations, the individual can even update data in the application through this feature.

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



Enable/Disable custom.pll code

Modify Personalisation

Gives the users detail information about the application and data

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

1.7 Application manager Oracle Application Manager is a powerful tool that allows user to: o Monitor and support business flows within Oracle E-Business Suiteo Edit or delete workflowso Manage concurrent manager

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.



Choose the Order to Cash flow



The workflows appear below the business flow


1.8.1. Business Process Variableso Oracle does not have detailed security around Alerts. The Alert Manager will provide

access to all Alerts. If the client makes extensive use of Oracle Alerts, access to the Alert Manager should be restricted.


1.8.3. Control Limitationso The Application Developer comes with the Process Navigator Tab enabled. Given the

purpose and access granted, formal change control procedures for this responsibility should be active in the production environment.

o The seeded Application Developer responsibility also contains the menus needed to change Key Flexfields (i.e. General Ledger Accounting Flexfield) that creates a segregation of duties issue. There is a legitimate need for an Application Developer to have access to Key Flexfield definitions, but usually this access is restricted to a test or development environment only.

1.8.4. Testing Noteso An Alert by itself is not a control. The Alert only notifies management to perform some

activity. PwC should consider and test the procedures required of management as a result of the alert

o Workflow controls should not be limited to the approval hierarchy and distribution list. Practitioners should consider testing any Workflow-related transactions on a substantive basis to ensure transactions are processed in accordance with management's control objectives and policies.



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

2. Application Support User IDs 2.1. Guest ID

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

2.2. Default/Seeded User IDsThe following user IDs are shipped with Oracle EBS.

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

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

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





2.3.4. Testing Noteso None

3. APPS Database IDA 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, 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 E-Business 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. RiskThe 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.

3.2. Potential Automated SolutionsThe inherent auditing mechanism in the Oracle database (and related Application Programming Interfaces - APIs such as the "Audit API") can be used to help monitor changes to the database and



is discussed later. However these auditing mechanisms in the application and in database are not sufficient to allow for effective monitoring of the APPS ID.

Oracle is currently introducing its IT Auditor module for the E-Business suite which will further help with change control. Oracle is also introducing Database Vault which addresses segregation of duties within the database. Oracle Database Vault addresses some of the most common database security problems and internal threats by: Restricting the DBA and other privileged users from accessing application data Preventing the Application DBA from manipulating the database and accessing other applications Provides better control over who, when & where an application can be accessedAdditionally, functionality in other third party tools provides tighter control over Oracle E-Business Suite change control procedures. Refer to Oracle Metalink at https://metalink.oracle.com/.

To augment basic monitoring procedures over the APPS ID, other features can be implemented to help ensure that access to the database is controlled. Either approach individually or collectively are controls we recommend. Through the use of native Oracle security features found within SQLNET (sqlnet.ora configuration file) and the LISTENER (listener.ora configuration file), Oracle can be configured to only allow connections from certain locations or IP addresses. Specifically, the listener.ora file has an optional section where a list of authorized connection sources is listed.

Oracle-native security is not the only way to restrict access to the database. An intrusion detection system (IDS) including firewalls and other hardware/software could isolate the database server. IDS security could limit access to pre-determined locations. Additionally, IDS monitoring and reporting features could also be us.

3.3. Control ConsiderationsThe overall approach for managing this issue (and subsequent testing) is a combination of IT monitoring controls, restricted access, good company-level controls and good policies and procedures. Management should also have fraud monitoring controls in place for key employees and users of the application. Even though ERP transactional data is generally very complex and difficult to initiate from the database, the possibility does exist that inappropriate business information can be initiated from the database and processed. Generally, the business process controls mentioned could provide a significant amount of risk mitigation.

The IT controls that can be implemented include monitoring sensitive access to the database, monitoring sensitive changes to the database, protecting the audit trail and restricting access to the database.

3.3.1. Access to APPS Password Generally, the requirements for using this ID would be similar to those of an emergency or "fire-call" ID. The exception with the APPS ID is that periodic change of the password is not suggested since the application itself uses the ID to perform certain actions and procedures. Changing the APPS password should be a controlled and planned event to ensure that unplanned system outage does not occur due to password errors. While Oracle does provide some ability to dynamically change application passwords while the system is still live, we do not suggest this approach in managing these passwords. Failure during this password change process could, and probably will, bring down the system. This risk is especially true if the client makes use of custom routines that require the APPS password. These routines would need to be modified as well in order to function properly.

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 fire-call 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 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 high-level 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 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.



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

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





1.1.4. Testing Noteso System profile options at the site level can be effectively tested online. GATE reports can

also be used.

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





2.1.4. Testing Noteso System profile options can be tested online for applications in-scope. GATE reports can

also be used.



3. Responsibility-Level System Profile Options at the responsibility level only have impact on the responsibility associated with the particular parameter. Oracle responsibilities are generally associated with a specific Ledger name and operating organization by using responsibility-level system profile options. For example, even though the site level ledger name and operating organization is set to "Ledger name A and Org A" respectively, "ABC Responsibility" could be assigned to "Ledger name B and Org B" respectively at the responsibility level. The responsibility-level assignment will be the one that is enforced.

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





3.1.4. Testing Noteso System profile options at the responsibility level cannot be effectively tested online unless

specific responsibilities are being tested. GATE reports should be used; otherwise, a custom query made by the client will be required to obtain profile options set at the responsibility level.

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







4.1.4. Testing Noteso System profile options at the user level cannot be effectively tested online unless specific

users are being tested. GATE reports should be used; otherwise, a custom query made by the client will be required to obtain profile options set at the user level.

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

5.1 Profile options

Profile Option Setting If new for R12, what is it?

Available Options Relevant

APPS_SSO_LINK_TRUTH_SRC

Applications SSO Linking Source of Truth

Applications SSO Linking Source of Truth

E-Business Suite, Oracle Internet Directory

C

APPS_SSO_POSTLOGOUT_HOME_URL

Applications SSO Post Logout URL

Applications SSO Post Logout URL

User Defined C

APPS_SSO_OID_IDENTITY

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 E-Business Suite instance should create the user in response to IDENTITY_ADD

Enable, disable C

APPS_SSO_AUTO_LINK_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_ACCOUNTS

Applications SSO Allow Multiple Accounts

At user level, it enables a user to have multiple E-Business Suite accounts linked to

Enable, disable TBD





a single SSO user name.Selection of which account is active is done via the Preferences page.At site level, it indicates the default for users without this specific setting.

FND_EXPORT_ALL_BLOCK_DATA

FND Export All Block Data

The profile control what data is exported from a form's block.

Yes, No TBD

FND_FIXED_SEC_KEY

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

User Defined C

FND_FIXED_KEY_ENABLED

FND: Fixed Key Enabled

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

Yes, No C

FND_CACHE_PORT_RANGE

FND_CACHE_PORT_RANGE

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

User Defined C

OAM_DSCRAM_ALLOWED

OAM: Data Scrambling Allowed

Profile option to allow data scrambling

User Defined C

OAM_DSCRAM_ENABLED

OAM: Data Scrambling Enabled

Profile to enable or disable data scrambling

User Defined C

OAM_WS_AUDIT_ENABLED

OAM_WS_AUDIT_ENABLED

Enable or Disable Web Service Auditing

User Defined C





SIGNON_PASSWORD_CASE

Signon Password Case

Enables or Disables Password Case Sensitivity

Enabled, Disabled A&C

OAM_ENABLE_SYSTEM_ALERT

System Alert Enable Level

System Alert Enable Level

All, Critical and Error, Critical, None

C

SIGNON_PASSWORD_CASE

Signon Password Case

Enables or Disables Password Case Sensitivity

Insensitive, Sensitive A&C

SIGNON_PASSWORD_CUSTOM

Signon Password Custom

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

User Defined A&C

SIGNON_PASSWORD_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_PASSWORD_HARD_TO_GUESS

Signon Password Hard To Guess

Profile that gets set to "true" if hard-to-guess password validation rules should be enforced for new passwords.

Yes, No A&C

SIGNON_PASSWORD_LENGTH

Signon Password Length

Minimum length of Applications user password

User Defined A&C

SIGNON_PASSWORD_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:LEVEL

Sign-On: Audit Level

Level at which to audit foundation usage

NONE, USER, RESPONSIBILITY, FORM

A&C

SIGNONAUDIT:NOTIFY

Sign-On: Notification

Notify User Concurrent Program Failures and Invalid Printers

Yes, No A&C





FND_DIAGNOSTICS FND: Diagnostics Enables Diagnostics Global Button

Yes, No A&C

FND_HIDE_DIAGNOSTICS

Hide Diagnostics menu entry

Hides the Help: Diagnostics Menu entry

Yes, No A&C

UNIQUE:SEQ_NUMBERS

Sequential Numbering

Sequential Numbering

Always Used, Not Used, Partially Used

A&C

CONC_REPORT_ACCESS_ 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 C

PRINTER Printer Output Printer Registered Printers e.g. ( noprint, LabelPDF)

A&C

FA_WF_GENERATE_CCIDS

FA WF GENERATE

FA: use workflow account generation notification for new assets.

Yes, No A&C

Workflow activity settings: Request Approval From Approver timeout

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

Days C

UMX: Enable ICM Validation"

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

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

Yes, No A&C





during the assignment of roles by administrators to users.

MO: Security Profile (Global or just Security Profile)

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

Yes, No A&C

MO: Default Operating Unit

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

Yes, No A&C

SLA: Enable Data Access Set Security in Sub ledger

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

Yes, No A&C





specific ledger using the “GL Ledger Name” profile option, the user will be able to create and post any journal in any ledger through the sub-ledger.

Note: audit trail profile options are not considered here.

5.2. Other settings to be considered

5.2.1 Set workflow notification mailer SEND_ACCESS_KEY to N

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



I. Segregation of Duties ConceptsSegregation of Duties (SoD) within Oracle E-Business Suite (EBS) is challenging. Many layers of configurations, access and other elements in the application come together to both restrict and increase the exposure to security weaknesses.

Most practitioners only consider SoD in relation to forms and functions. However, these Oracle features are augmented by other configurations as indicated below. These additional configurations should be considered for additional testing separate from, and in conjunction with, a SoD analysis.

Segregation of Duties 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.



Initiation -- Entering the transactionAuthorising -- Posting the transactionStanding Data -- maintaining master data such as the vendor master fileCustody of Assets -- Physical custody of assetsRecon/Review -- Reconciling/Reviewing the accounting activity over certain transactionsSensitive Access -- Application and Business setups that support the business.

Segregation of duties and restricted access is a multi-dimensional challenge within Oracle EBS

Note: From release 11.5.10, a new feature called Personalisation is an additional element that affects SOD. This feature can be used to improve security on forms.

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

For SOD testing and process specific SOD principles, refer to each module's Practice Aid.



1.3.2. Control Dependencieso The Custom.pll library is a standard Oracle Forms PL/SQL library that is

supplied by the Oracle Applications. This is Oracle’s built-in feature that allows the customer to enhance the standard functionality of the Applications by implementing site-specific business rules. Every Oracle Forms -based eBusiness screen, and any custom form developed using the Oracle Application development standards, will access the CUSTOM library. This allows customers to create business rules that effect the entire organization. Customers may use this functionality to hide certain tabs from users (i.e. Process Tab) or enforce even more granular controls in forms and functions access. PwC should inquire if the client is using Custom.PLL to further control user access during SOD testing and validation.

1.3.3. Control Limitationso Oracle is installed with default responsibilities that help the client enter and post transactions.

These responsibilities were built by Oracle without any consideration of Segregation of Duties principles.

1.3.4. Testing Noteso Personalisation is not currently analysed by Oracle GATE.



J. Restricted Access/Segregation of Duties

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

1. Application SetupsApplication 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 client’s 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 DutiesSegregation of Duties is defined as segregating access to two or more sensitive functions that, when combined, could present a risk of material misstatement, management override, fraud or theft.

3.1. Designing SoDSegregation of Duties and Restricted access design could be complex and is dependent upon each client's environment. Clients should acknowledge the inherent accounting and unique business risks that require certain activities to be performed by different individuals. In either circumstance, the rules and related documentation developed should be associated with the client's significant financial risks.

Segregation of Duties and Restricted access design could include a balance between separating all conflicting activities and mitigating all segregation of duties violations. This decision making process should include formal elements of SoD analysis. When designing SoD principles, the following should be kept in mind:



Envision the “ideal” environment, regardless of head count. However, risk and likelihood should be considered.

Smaller areas / business units may not be able to implement proper SoD rules due to resource constraints.

All high-risk financial systems should be considered, not just Oracle. When SOD is impossible, mitigating / compensating controls should be identified

Generally, the following SoD principles should be adhered to: Users with transactional access are restricted from standing data and application setup. Cross module (currency, ledger) and/or hidden access (process tab) should typically not exist Users should not be able to create and approve their own transactions. Custody of assets is separate from accounting transactions. IT support should not violate the SoD rules. Support procedures should be developed that will

allow for the effective remediation of technical issues while giving the business process owners a stable, controlled, monitored accounting environment.

3.2. Documentation of RulesManagement should have a formal set of documents identifying the high segregation of duties and restricted access risks and conflicts that could exist for each business cycle. This set of documentation should then include the relevant segregation of duties and restricted access controls that the client implemented to mitigate these risks. These controls could include a balance between segregation of duties, restricted access and/or other business mitigating controls.

Ideally, the client has developed a matrix of business processes (including Oracle functionality) that identifies the SoD and restricted access rules for a business process. An example of this matrix is identified below. The X's in the matrix identify the SoD conflict between the x and y axis of the matrix. The H's identify the agreed-upon sensitive business transactions that should also be tested with regards to restricted access.

3.3. SOD MonitoringOnce rules are established, the client can then determine the more effective cost of the control to mitigate the segregation of duties risk or to rely on the separation of conflicting activities. Small environments could leverage a manual approach to SoD management. Large environments will almost always require technology to management SoD effectively. Typically SoD management is driven and managed by the technology group. Unless the business process owners sponsor and drive the project, SoD management is often much less effective.

3.3.1. Manual MonitoringIf the client chooses to sustain SoD on paper, then the following may be used:



Sample SoD matrix

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 MonitoringIf the client chooses technology to help sustain their SoD environment, then the client should maintain testing over the design and implementation of the solution and document their daily use of the solution. On-going maintenance of the technology solution should follow the client's formal change management process and controls.

3.4. Control Considerations3.4.1. Business Process Variables

o The challenge to our clients is that they either do not have the necessary time and staffing resources to identify and document the segregation of duties rules applicable to the company or they underestimate the commitment required.

o Not only should specific SoD issues be addressed, but clients should look to identify the root cause of these issues.

o RBAC (Role Based Access Control, described further in the system administration practice aid) is currently only applicable for self-service applications (iTime, iExpense, iProcurement, etc).

o Each client's Segregation of Duties principles must be considered in light of the client's specific business processes and risks.

3.4.2. Control Dependencieso Activities might be influenced by different functionalities as RBAC and the sub

functionality data entry via sub ledgers, MOAC and the hybrid usage of roles, proxy users and delegated admin responsibilities. Also this is a very broad statement; the practitioner should consider the mentioned functionalities, when assessing the SOD.

3.4.3. Control Limitationso The majority of Oracle seeded responsibilities contain SoD conflicts.o Clients tend to build their responsibilities based on functionality and may make copies of

the default Oracle responsibilities, with minor modifications. It's highly likely that these revised responsibilities have SoD conflicts.

3.4.4. Testing Noteso For general guidance on Access and Segregation of Duties control considerations in the

context of a financial audit or an audit of internal controls over financial reporting, refer to PwC Audit 4164 and 4164.01.

o For a suggested list of detailed SoD principles and their associated risks, refer to PwC GATE. GATE's standard reports contain baseline, generic rules that are industry agnostic and should be tailored/customized for each client's environment.

o PwC should recognise how the client manages SoD and make adjustments to the testing strategy accordingly.

o In complex environments such as Oracle EBS, practitioners should consider going beyond the access approval form and consider the overarching process management uses when deciding to approve access.



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.



K. Relevant Modules

1. iSetupiSetup is a data management product that helps in automating migration and monitoring of EBS setup data. iSetup helps in the migration of data between different instances of Oracle.

iSetup is covered in this document, as this module might influence the setup of Oracle EBS and can be used for analyzing the overall setup of Oracle EBS. For detailed analytics refer to the iSetup User Guide.

1.1. Usage of iSetup

iSetup is a two-part application:

o iSetup Configurator runs on the web and provides an interactive questionnaire to capture business requirements and configuration decisions.

o iSetup Migrator is the load functionality that populates the application setup tables with the detailed parameter values.

The following graph depicts the process of using iSetup to support the creation and extraction of the transformation files, which then can be transferred to any output.

Clients could use this for migrating data between: Production instance to another production instance Test or development environment to the production environment





2.1.4. Testing Noteso The reports, either standalone for a single instance, or comparison between multiple

instances can be used to retrieve and compare setup data.



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

2. AMEOracle Approvals Management (AME) is a self-service Web application that enables client to define business rules governing the process for approving transactions in Oracle applications.

AME is covered in this document, as the usage of AME might impact the analytics of approval processes and controls based on approvals. For detailed analytics refer to the Oracle AME user guide. Oracle AME is also integrated with Oracle user management.

1.1. Usage of AME

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

An approval rule is a business rule that helps determine a transaction's approval process such as who gets to approve certain transactions, dollar amount limits, and notification routing. Rules are constructed from conditions and actions.

For example an approval rule can be as follows:

If the transaction's total cost is less than 1,000 USD, and the transaction is for travel expenses, then get approvals from the immediate supervisor of the person submitting the transaction. Otherwise get approval from the company travel manger.

Oracle Approvals Management enables business users to specify the approval rules for an application without having to write code or customize the application. Once the rules are defined for an application, the application communicates directly with AME to manage the approvals for the application's transactions. Client can define rules to be specific to one application or shared between different applications. As AME recalculates the chain of approvals after each approval, a transaction is assured to be approved under the latest conditions, regardless of organizational changes, changes



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.


2.1.1. Business Process Variableso Many clients might rely on manual approvals or sign-offs sheets as their key controls over

account procedures. From an efficiency, effectiveness perspective, PwC practioners should be on the look out for areas of process improvement where a manual approval process can be automated in Oracle.



2.1.4. Testing Noteso The use of AME gives auditors the ability to test the approval process systematically and

gain comfort over established key controls.

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

Function – Internal Name Function – Display Name

Form – Internal Name

Form – Display Name

ALR_ALRALERT Define Alert ALRALERT Alerts

FND_FNDCPMCP_SYS Concurrent Programs (System Administrator Mode)

FNDCPMCP Define Concurrent Program

FND_FNDCPMPE Concurrent Program Executables

FNDCPMPE Define Concurrent Program Executable

FND_FNDFFMDC Descriptive Flexfield Segments

FNDFFMDC Define Descriptive Flexfield Segments

FND_FNDFFMVS Flexfield Value Sets FNDFFMVS Define Value Set

FND_FNDPOMPO Profile Options FNDPOMPO Define User Profile Option

FND_FNDSCAPP Applications FNDSCAPP Register Applications

FND_FNDSCDDG Data Groups FNDSCDDG Define Data Group






FND_FNDSCMOU ORACLE Usernames FNDSCMOU Register ORACLE IDs

PSB_PSBSTPTY Attribute Mapping Details PSBSTPTY Attribute Mapping Details

MSDCSDFN Define Data Stream MSDCSDFN Define Data Stream

MSDCSDFA Custom Stream Advanced Setup

MSDCSDFA Custom Stream Advanced Setup

MSD_MSDAUDIT Audit Statements MSDAUDIT Audit Statements

JTFRSDGR Define Dynamic Resource Groups

JTFRSDGR Define Dynamic Resource Groups

JTFBRWKB Business Rule Workbench

JTFBRWKB Business Rule Workbench

ONT_OEXPCFVT Validation Templates OEXPCFVT Define Validation Templates

ONT_OEXDEFWK,QP_OEXDEFWK

Defaulting Rules,Attribute Mapping

OEXDEFWK Defaulting Rules

JTFTKOBT Objects Meta-data JTFTKOBT Foundation Objects

JTF_GRID_ADMIN Spreadtable Metadata Administration

JTFGRDMD Spreadtable Metadata Administration

JTFGDIAG SpreadTable Diagnostics JTFGDIAG SpreadTable Diagnostic Form

JTFGANTT JTFGANTT JTFGANTT JTFGANTT

WMS_WMSRULEF Define WMS Rules WMSRULEF Define WMS Rules

QP_QPXPRFOR Create Pricing Formulas QPXPRFOR Define Pricing Formulas

QP_QPXPTMAP New Attribute Mapping QPXPTMAP Attribute Mapping

GMAWFPCL_F Workflow Process Configuration Framework

GMAWFPCL Workflow Process Configuration Framework

GMAWFCOL_F Workflow Activity Approval Configuration Framework

GMAWFCOL Workflow Activity Approval Configuration Framework

AME_WEB_APPROVALS Approvals Management TBD TBD






PERWSAPI PL/SQL tester PERWSAPI PL/SQL tester

FFXWSMNG Write Formula FFXWSMNG Write Formula

FFXWSDFF Define Function FFXWSDFF Define Function

FFXWSBQR Create Quickpaint Inquiry FFXWSBQR Create QuickPaint Inquiry

PAYWSDAS Define Assignment Set PAYWSDAS Define Assignment Set

PAYWSDYG Dynamic Trigger Maintenance

PAYWSDYG Dynamic Trigger Maintenance

PERWSSCP Define Security Profile PERWSSCP Define Security Profile



M. Glossary

1. Key Oracle Functionality

A number of terms that are used within the Oracle System Administration module are listed below with an associated definition.

Term Description

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

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

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

Concurrent Manager

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

Concurrent Program

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

Concurrent Request

A command to start a concurrent program. An example of a concurrent request is a command to generate and print a report.

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

Menu A hierarchical arrangement of application functions (forms) that is displayed within the main navigate window

Request Security Groups

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



Oracle R12 SA Practice Final_comments_v1

Documents

Transcript of Oracle R12 SA Practice Final_comments_v1