We will start out with the most important and fundamental question in delivering security for Oracle ERP Cloud: what to do with out of the box seeded roles.
There are three types of roles: seeded roles, hybrid roles, and fully customized roles.
Seeded roles are roles that have been provided by Oracle – loaded as part of the installation of the software. They get their name because they are seeded with the application. The majority of new ERP Cloud implementations are exclusively using seeded roles to get the implementation functioning correctly for the "go live".
Seeded roles inherit other roles. However, seeded roles are primary made up of Duty roles. Duty roles can be thought of as process roles as they include groupings of privileges related to subprocesses within a business process. For example, one duty role would have the privileges necessary to enter invoices in the payables module. A different duty role would have the privileges necessary to process payments in the payables module. These two duty roles may role up to a Payables Specialist job role.
So, to go into more detail – there are seeded job roles and seeded duty roles. Each Job role is made up of one or more Duty roles as illustrated above. Each Job role can also have privileges directly assigned to it.
When Oracle patches a client's system (quarterly), they can add or remove privileges within a Duty role and can add or remove privileges within a job role. In this same way, they can add or remove Duty roles within a Job role.
When building a custom Job role, you can simply customize the Job role, but leverage the seeded Duty roles, as is, or you could also customize the Duty roles and use the custom Duty roles in the build of the custom Job role. This is what we'd refer to as a hybrid role. It is a custom Job role with at least one or more seeded Duty roles. This means that when a patch is applied to the system, privileges could be added or removed from the Job role because the seeded Duty role could have privileges added or removed. If privileges were to be added to multiple Duty roles with the patch, and some of those Duty roles are now custom, they would not allow for the updates. A partial update would then take place. This can cause serious issues to hybrid roles.
A fully customized role would be a Job role that doesn't leverage any seeded Duty roles. If a role is custom and all Duty roles within that Job role are customized, a patch would not impact the role design.
To recap the different types of roles:
Remember that Oracle will patch the Seeded roles and Duty Rules four times a year. Also remember that many Duty roles have privileges that should not be used due to Sensitive access risks (one or more privilege will need to be removed) or one or more privilege that will cause an SoD conflict within that role or between that role and another role.
An organization has a choice to make as it relates to role design. It can either:
Pros: roles will inherit all changes
Cons: changes may introduce new sensitive access risk and segregation of duties conflicts. Most seeded roles also inherently have sensitive access risks and segregation of duties conflicts.
Pros: roles will inherit some changes. This could be good from an operational perspective because the user(s) have access to that role will gain new privileges (new abilities being provided by Oracle), if applicable.
Cons: roles may inherit a privilege that will not be identified as having risk leading to a Sensitive Access risk or to cause an SoD conflict. A partial update could take place causing the role to "break" and some functionality may be lost due to the missing pieces.
Pros: a patch will NOT impact the abilities of the role. No new privileges will be added unless the role is specifically modified to add the privilege. This is the least risky approach from a GRC perspective. This will enable companies the ability to fully test the new functionality in a development environment to ensure the process works as is expected and wanted. They can then add the functionality to the custom job role exactly where it is required and desired. Training can take place to ensure it is used properly. There will be no surprises to functionality showing up unexpectantly.
Cons: new privileges that are added to that module will not be made available to those being assigned this custom role. For the functionality to be made available, it needs to be added to the Duty roles or directly to the Job role.
The most commonly implemented approach taken by management when the risks are made clear is to go with fully customized roles. This approach would allow management to defer having to made changes to roles every quarter since none of the fully customized roles would be patched.
There are two caveats to this:
Therefore, every organization goes live with, is a combination of Seeded, Hybrid roles, and maybe a few fully customized roles.
Unfortunately, Oracle doesn't provide a thorough way to easily and completely identify the impact of the patches during the quarterly patching process. Even if they did, management often only has two weeks from the time the patch is applied in a non-production environment until it is applied to the production environment. That is NOT enough time to do a full impact analysis and to identify what changes are needed to the roles to keep their organization in compliance with the objectives they have identified related to SoD conflicts and Sensitive Access risks.
Thus, when faced with the facts, management typically agrees to move to fully customized roles. In doing so, they accept the following:
Most companies realize that staying with seeded roles introduces too much risk and move to custom roles. When moving to custom roles, t(here is no 'stick your head in the sand and do nothing' option. Management MUST do a patch impact analysis at some point. By fully customizing the roles, they can delay the patch impact analysis to once per year. By using seeded roles or hybrid roles, they must do a patch impact analysis each quarter. There is no right answer. Whatever choice management makes, they must put a governance process in place to manage the operational, fraud, security, and compliance risks.
Contact me at firstname.lastname@example.org for questions or comments on this. A copy of the above can be downloaded per the attachment.
The Oracle Applications & Technology Users Group (OATUG), formerly the Oracle Applications Users Group (OAUG), is the world’s largest education, networking and advocacy forum for Oracle Applications & Technology users.
email@example.com Oracle Applications & Technology Users Group 3525 Piedmont Rd NE Bldg 5, Ste 300 Atlanta, GA 30305-1509 USA (404) 240-0897
Copyright 2020 Oracle Applications & Technology Users Group. | All Rights Reserved. | OATUG PoliciesAll material, files, logos, and trademarks within this site are properties of their respective organizations.