by Cameron Larner
President
Absolute Technologies, Inc.

Ever since the passage of Sarbanes-Oxley legislation, auditor scrutiny of ERP system user access controls at publicly traded enterprises has been evolving, as has corporate compliance.  Though adoption has been slow, by now most public companies have either manual or software automated solutions in place to address the risks associated with unauthorized, unintentional, overly broad and fraudulent access, generally falling under the moniker of “Segregation of Duties” or “SoD” compliance.

E-Business Suite User Access Models

In the Oracle E-Business Suite ecosystem, in order to address SoD compliance requirements, organizations typically must unravel the complex web of user access rights associated with E-Business Suite. Today, this requires a deep understanding of at least the traditional user access model known as responsibility-based security (or function-based security), and at most, the newer Oracle User Management based model, often characterized as Role Based Access Control or “RBAC”, which includes additional features like delegated administration and self-service access provisioning and approvals.

The RBAC user access model was designed to add value to the original responsibility model, providing a framework that is both more efficiently maintained and utilized, as well as more adept at effectively facilitating SoD compliance. But is it worth the extra effort to implement?

The answer to that, of course, depends on several factors, which I’ll explore further on. But first, I’ll describe the architectural elements of each user access model, starting with the traditional responsibility-based security model.

The Traditional Model

The Responsibility model, incorporated within the Application Object Library module, is characterized by the assignment of one or more responsibilities directly to a designated user.

Each responsibility is generally designed to provide one of several levels of access to the functional (via functions) capabilities provided by a single application module. For example, E-Business Suite is configured with several default responsibilities for the General Ledger module, each offering different degrees of accessibility that are loosely aligned with a user’s hypothetical job or role, such as User, Supervisor, Controller, Super User, and Budget User, etc. Such “role” based responsibilities do provide a limited level of segregation of duties, depending on the module, but vary significantly and often don’t meet today’s standards of best practices.

At the configuration level, responsibilities are associated with navigation menus and sub-menus which in turn provide access to functions. Each menu entry is associated with a function or a sub-menu, or both. The menu entry also designates authorization to the function in the form of a grant. Functions are the programmatic units which present application functionality to the user on their computer screen, often referred to as forms, pages, screens or windows. Some functions, known as executable, directly call executable programs that open such screens, while others, known as non-executable or sub-functions, merely act to grant the capability to access functionality within related (“target”) executable functions. (In other words, the target executable function’s program was written to detect the assignment of the sub-function and take a pre-determined action.) For example, the Receivables module provides an executable function called “Transactions” and four related sub-functions called, “Invoice: View”, “Invoice: Enter”, “Invoice: Update” and “Invoice: Delete”. Access to the Transactions executable alone provides the user with access to an empty form, with no access to view or modify data. In order to view any data, the user must be assigned the “View” sub-function. Consequently, to modify any data, the user must be assigned one or more of the remaining three sub-functions.

Although executable functions usually provide full access to the assigned user, many have been designed to work in conjunction with sub-functions. Thus, the Responsibility model employs both a navigational element to an executable and a permission element (directly or indirectly through sub-functions) to user access, though often both are co-mingled in the assignment of a single executable function.

The Function Security Layer

One or more responsibilities may be assigned to a user. Each assignment grants the user access to the top menu associated with that responsibility. Consequently, the user has “access” to each of the functions subordinate to the top menu. As stated above, “functions” generally give the user menu driven navigable access to forms or html pages, and “sub-functions” activate or deactivate functionality within a target function. For example, the Enter GL Journals function, when coupled with the Post Journals sub-function, presents a “Post” journal entries button to the user that is otherwise grayed-out and inaccessible. Note, however, that not all functions have corresponding sub-functions. 

Note that the Post button, along with several others are available to the user (not grayed out), but others are grayed out, indicating they are not accessible. In some cases, such buttons are not displayed on the screen at all if the required sub-function is not assigned to the user’s menu.

Responsibility Level Exclusions

The function-security layer is augmented with another feature, called Menu and Function Exclusions (aka responsibility level exclusions) , which provides a critical tool to effectively manage SoD controls. Exclusions allow the administrator to “prune” the menu hierarchy associated with a responsibility by designating one or more menus or functions to exclude from access, thereby facilitating user access controls management without having to modifying the underlying menu structure, which is often shared by many responsibilities.

In the diagram below, those figures shaded in red have been excluded, and those in gray have inherited the exclusion, and thus are equally inaccessible to the user of the designated responsibility. Note, however, that the menu itself, and its properties remains intact. In this manner, a single menu can be utilized to service several responsibilities with differing access objectives.

MOAC Data Security

For those enterprises which have defied more than one organization within their E-Business Suite instance, a form of data security called multi org access controls (MOAC) can be employed. Specifically, using designated profile options across the organizational categories of Business Groups, GL Ledgers, and Operating Units, an access administrator may associate a responsibility with a single organization, thus restricting user access solely to the designated organization’s data while logged into a given responsibility.

Furthermore, starting with late releases of R11, EBS also provided enhanced functionality in this area in which “Security Profiles” could be defined and assigned multiple organizations such that a single responsibility could provide a user access to more than one organization.

Rise of the Clones – A Maintenance Note

Though many E-Business Suite modules contain seeded responsibilities that appear to provide a segregation of duties, as noted above, auditors have found that most require significant modification to mitigate the risks associated with the broad access generally provided. Thus, they have generally advised customers to avoid use of the seeded responsibilities in favor of clones that may be modified to align with SoD best practices.
Specifically, responsibility level menu and function exclusions can be employed to scale back functional access in cloned responsibilities to meet SoD requirements.

This “clone and modify” method avoids the risk that an Oracle patch might later introduce new issues or undo changes to modified seeded responsibilities that survive undetected.

Coming Up Next

My next post in this series will cover the Oracle User Management user access model.

Cameron Larner
President
Absolute Technologies, Inc.