11g Release 7 (11.1.7)
Part Number E16689-07
Home
Contents
Book
List
Contact
Us
|
Oracle® Fusion Applications Security Guide 11g Release 7 (11.1.7) Part Number E16689-07 |
Home |
Contents |
Book List |
Contact Us |
 Previous |
 Next |
This chapter contains the following:
Segregation of Duties: Explained
Defining Segregation of Duties Policies: Points To Consider
Managing Segregation of Duties Risks and Violations: Critical Choices
Segregation of duties (SOD) separates activities such as approving, recording, processing, and reconciling results so an enterprise can more easily prevent or detect unintentional errors and willful fraud. SOD policies, called access control policies in Application Access Controls Governor (AACG), exert both preventive and detective effects.
SOD policies constrain duties across roles so that unethical, illegal, or damaging activities are less likely. SOD policies express constraints among roles. Duty role definitions respect segregation of duties policies.
You manage, remediate, and enforce access controls to ensure effective SOD using the Application Access Controls Governor (AACG) product in the Oracle Enterprise Governance, Risk and Compliance (GRC) suite.
AACG applies the SOD policies of the Oracle Fusion Applications security reference implementation using the AACG Oracle Fusion Adapter.
AACG is integrated with Oracle Identity Management (OIM) in Oracle Fusion Applications to prevent SOD control violations before they occur by ensuring SOD compliant user access provisioning. SOD constraints respect provisioning workflows. For example, when provisioning a Payables role to a user, the SOD policy that ensures no user is entitled to create both an invoice and a payment prevents the conflicting roles from being provisioned. AACG validates the request to provision a user with roles against SOD policies and provides a remediating response such as approval or rejections if a violation is raised.
Use AACG to for the following.
Define SOD controls at any level of access such as in the definition of an entitlement or role.
Simulate what-if SOD scenarios to understand the effect of proposed SOD control changes.
Use the library of built-in SOD controls provided as a security guideline.
SOD policies express incompatible entitlement or incompatible access points into an application. In GRC, an access point is the lowest level access for a particular application. In GRC, entitlement is a grouping of access points. As a security guideline, group the lowest level access points or define the SOD policy at the access level causing the least amount of change. Business activities are enabled at access points. In Oracle Fusion Applications, the hierarchy of access points in descending levels is users, roles, and entitlement.
Note
AACG entitlements are logical groupings of security objects that represent Oracle Fusion Application access points such as roles or entitlement.
Note
In AACG, segregation of duties policies are called access controls.
Oracle Fusion Applications does not predefine business logic for dealing with SOD conflicts. Oracle Fusion Applications does define a set of states where role requests are suspended pending resolution of SOD violations the role request introduces. In most cases, Oracle Fusion Applications invokes OIM to handle role requests. Enterprises define SOD resolution rules when defining SOD policy.
The risk tolerance of your enterprise determines what duties must be segregated and how to address violations.
AACG assists in remediation of violations with a guided simulation that identifies corrective action. You determine the exact effects of role and entitlement changes prior to putting them into production, and adjust controls as needed.
For information on managing segregation of duties, see the Oracle Application Access Controls Governor Implementation Guide and Oracle Application Access Controls Governor User's Guide.
Segregation of duties (SOD) policies express incompatibilities enforced to control access in defined contexts.
In Oracle Fusion Applications, SOD policies protect against the following incompatibilities.
Privilege X is incompatible with privilege Y
Role A is incompatible with role B
Any privileges in role A are incompatible with any privileges in role B.
Privilege X is incompatible with any privileges in role B.
The following examples of SOD policies illustrate incompatible entitlement.
No user should have access to Bank Account Management and Supplier Payments duties.
No user should have access to Update Supplier Bank Account and Approve Supplier Invoice entitlement.
You can extend SOD policies to control access to specific data contexts.
For example, no single individual must be able to source a supplier in a business unit and approve a supplier invoice in the same business unit.
SOD policies may include exclusion conditions to narrow the SOD scope and reduce false positive violations, or inclusion conditions to broaden the scope.
Conditions apply to access points globally, to policies, or to access paths defined by policies. Access path conditions can exclude a user from a role, an Oracle Fusion Applications entitlement from a role, or a permission from an Oracle Fusion Applications entitlement.
The following global exclusion conditions are predefine in Oracle Fusion Applications and available when creating SOD policies.
User Status
User Name
Enterprise Role
Action
Business Unit
Within Same Business Unit
Oracle Fusion Applications enforces SOD policies under the following circumstances.
When granting entitlement to a role
When provisioning a role to a user
For information on managing segregation of duties, see Oracle Application Access Controls Governor Implementation Guide and Oracle Application Access Controls Governor User's Guide.
Note
SOD policies are not enforced at the time of role definition.
A single SOD policy can include entitlement from multiple instances of a single enterprise resource planning environment. For example, one SOD policy is enforced in implementation, test, and production instances of Oracle Fusion Applications.
You assess and balance the cost of duty segregation against reduction of risk based on the requirements of your enterprise.
The types of people who resolve SOD conflicts include the following.
Administrator of an external program such as the Procurement Administrator for the supplier portal or the Partner Manager for the PRM Program
Senior executive spanning multiple organizations in an enterprise with opposing interests
Risk management professional implementing an Oracle Enterprise Governance, Risk and Compliance (GRC) initiative
Predefines a set of conditions and informs access provisioning staff to approve requests and prove the exception based on certain conditions
Allows defining rules to route SOD violations for approval
You view and respond to risks and violations in the Application Access Controls Governor (AACG).
You may wish to override an SOD violation. For example, the Accounts Payable Supervisor includes incompatible duties to create both invoices and payments. When you provision this job role to a user, you may waive the violation in the AACG. You may waive the violation for the currently provisioned user, for the SOD policy that raised the violation, or for the SOD policy within a particular data set, such as a business unit.
The risk tolerance of your enterprise guides how you respond to conflicts. For example, a user may be provisioned with both the role of Order Manager and Shipping Agent. The Order Manger role entitles the user to enter orders, which could result in exploitation when filling shipping quotas. You can remove the entitlement to enter orders that the Order Manger job role inherits from the Orchestration Order Scheduling Duty role. Or you could segregate the shipping and order entry duties by defining an SOD policy that allows a user to have either job role but not both.
False positives can be SOD policy violations that are not actually violations, or are violations within your risk tolerance and therefore do not require corrective action.
You can reduce false positives by the following methods.
Define exclusion conditions that can be applied to individual or groups of policies.
Define logically complex SOD policies that enforce more exacting specifications.
Determine whether conflicts should be prevented, monitored, or subjected to approval during provisioning.
Conflict analysis detects a user's multiple paths to one or more conflicting access points.
For example, a user may be able to reach a single access point through one or more roles, or by one entitlement leading to another through submenus to a function that represents a risk. The resulting conflict path shows if the conflict is generated by inappropriate role provisioning or configuration of applications. The audit shows the paths from any number of users to any number of access points involved in conflicts, which lets you visualize the root cause and remediate effectively.
AACG assigns one or more users to review all paths involved in a given conflict so that the entire conflict can be addressed in a coherent way.
AACG lets you accept or waive a violation. Your reasons may include that you accept the risk or will define compensating controls.
A waiver may apply to the current user, constraint, or constraint within a dimension such as the business unit.
The risk tolerance of the enterprise determines whether a segregation of duties conflict must be removed from the security reference implementation.
The following approaches resolve conflicts.
Change the segregation of duties policy.
Ensure a job role does not contain incompatible duties.
Define data security policies that restrict authorized access by incompatible duties.
Changing a segregation of duties policy may not be possible in most cases. For example, a policy that segregates creation of payables invoice from making payables payments should be preserved, even if the Accounts Payables Manager job role includes a duty role for each activity. To prevent an accounts payables manager from being authorized to perform both duties, or from being authorized to make payables payments to self and direct reports, the Accounts Payables Manager job role must be changed. The security implementation can be changed to include two job roles that segregate the incompatible duties. Added data security policy grants can restrict the access to at risk data.
For information on managing segregation of duties, see the Oracle Application Access Controls Governor Implementation Guide and Oracle Application Access Controls Governor User's Guide.
