Segregation of
Duties: Explained

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.

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.

Managing Segregation of Duties

SOD policies express incompatible entitlement or incompatible
access points into an application. In GRCC, an access point is the
lowest level access for a particular application. In GRCC, 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.

Remediating Segregation of Duties Policy Violations

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.

Defining Segregation
of Duties Policies: Points To Consider

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.

Data Contexts

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.

Exclusion and Inclusion Conditions

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

Enforcement

Oracle Fusion Applications enforces SOD policies under
the following circumstances.

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.

Managing Segregation
of Duties Risks and Violations: Critical Choices

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

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

False positives can be SOD policy violations
that aren't actually violations or violations that are 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.

Determine whether conflicts should
be prevented, monitored, or made subject to approval during provisioning.

Path Level Detection

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.

Waiving or Accepting Violations

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.

Resolving Conflicts

The risk tolerance of the enterprise determines
whether a segregation of duties conflict must be removed from the security
reference implementation.

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.

Role Provisioning and Segregation of Duties: How They Work Together

Segregation of duties (SOD)
checks occur when roles are assigned to users. The checks are based on Oracle Application
Access Controls Governor (AACG) policies. The Oracle Identity Management
(OIM) integration includes predefined routing rules for remediation
in the Manage IT Security business process.

External users such as suppliers or partners need
to be provisioned
with roles to facilitate access to parent company interfaces
and data. The process by which such provisioning requests are approved
in Oracle Fusion Applications helps explain the request flows and
possible outcomes.

Note

In Oracle Identity Management (OIM), external users
means users who are not specific to applications, such as enterprise roles or the absence of entitlement to access an application.

Tables

A supplier or partner requests admission to a program
using an implementation of the Supplier Portal Submission. The submission
is captured in one or both of the following tables in advance of approving
or rejecting the supplier or partner.

Oracle Fusion Trading Community Model

Interface Staging

Oracle Fusion Applications collects the employee names
for the supplier or partner company at the time the company submits
its request to join the program so that all employees accessing Oracle
Fusion Applications on behalf of the supplier or partner are provisioned.

AACG in the Oracle Governance, Risk and Compliance
Controls (GRCC) suite is certified to synchronize with the policy
and identity stores for all pillars or partitions of Oracle Fusion
Applications and integrated with the Oracle Fusion Applications security
approach to roll up entitlements (by means of duty roles) to the roles that are provisioned
to internal users. SOD policies can be defined and enforced at any
level of authorization. For external users, SOD policies use attribute
information stored in the Trading Community Model tables.

OIM and the SPML Client

Enterprise business logic may qualify the requester
and initiate a role provisioning request by invoking the Services
Provisioning Markup Language (SPML) client module, as may occur during
onboarding of internal users with Human Capital Management (HCM),
in which case the SPML client submits an asynchronous SPML call to
OIM. Or OIM handles the role request by presenting roles for selection
based on associated policies.

OIM recognizes the role provisioning request and initiates
a call to AACG.

OIM apprises the SPML client of the current state
of the role provisioning request as SOD_CHECK_IN_PROGRESS.

OIM stores the SOD check result as part of OIM audit
data.

OIM apprises SPML client of the current state of the
SPML request. The provisioning is either still in progress with segregation
of duties being checked, or conflicts were found. If conflicts exist,
AACG rejects the request and notifies the application.

Status

Conflicts

Current State

SOD_CHECK_IN_PROGRESS

Unknown

Request sent to AACG and waiting for response

SOD_REMEDIATION_IN_PROGRESS

Conflict found

AACG detected violations and remediation is in progress

SOD_CHECK_APPROVED

No conflict found

No SOD violations found

SOD_CHECK_REJECTED

Conflict found

AACG detected violations that cannot be remediated

SOD_REMEDIATION_APPROVED

Conflict found

AACG detected violations that are approved

SOD_REMEDIATION_REJECTED

Conflict found

AACG detected violations that are rejected by approver

In the absence of an SOD exception, OIM provisions
all relevant users.

Note

When a partner user is provisioned, all employees
of the partner enterprise are provisioned. SOD checks occur when an
external user requests to join a program, because SOD policies operate
across Oracle Fusion Applications, not at the individual level. Supplier
or partner company user requests are not approved if there is an SOD
conflict against the supplier company.

OIM provides AACG with the details of SOD exception
approval workflow. AACG audits the outcome for use in future detective
controls and audit processes.

Oracle Application Access Controls Governor

AACG may respond with the following.

Roles may be provisioned to the external
user or its employees because no SOD conflict is found

SOD conflict is found and request
is denied because the relevant SOD policy is to be strictly enforced
and no exception approval should be allowed

SOD conflict is found and the exception
to the policy is allowed, so the request goes through additional processing,
such as an approval process.

Supplier or Partner Relationship Management responds
to an SOD exception by updating Trading Community Model tables with
the current state. An enterprise may elect to implement a landing
pad that offers external users a means of addressing the SOD problem
by providing more information or withdrawing the request.

SOD violation checking occurs during role implementation
and provisioning, and can be turned on or off if AACG is provisioned
and enabled as part of the Oracle Fusion Applications deployment.

Segregation of Duties Exception Resolution or Approval
Workflow

Depending upon status, OIM kicks off an auditable
SOD exception resolution workflow. Resolution can be conditional based
on approval or requirements such as contracts being met.

If one of the paths for exception resolution is to
get an approval, then the SOD exception resolution drives the approval
using AMX. Standard AMX rules, not business rules, resolve the approval
for the SOD exception, including the following.

Organizational hierarchies

Multiple mandatory and optional approvers

Rerouting and approval delegation

The approver resolution uses AMX Rules Designer to
access various user attributes and organizational hierarchies managed
in Oracle Fusion Applications repositories. This information is typically
not available in OIM or the LDAP identity store repository. Enterprises
can define additional approval rules using AMX Thin Client.

The SOD Exception Approver gets a notification through
supported channels that a new request is awaiting approval. The approver
signs in to the global SOA federated worklist application that aggregates
all pending worklist items for the user from all Oracle Fusion applications
and logical partitions or pillars of applications. The SOD exception
approval tasks show up in the same list.

The SOD exception approval task shows the details
of the SPML request and SOD Provisioning results in a page rendered
by OIM. The approver may take one of the following actions.

Approve the request as it is

Reject the request

If the approver approves the request, OIM sends an
SOD_REMEDIATION_APPROVED status to the SPML client.

If the approver rejects the request, OIM sends an
SOD_REMEDIATION_REJECTED status to the SPML client. The provisioning
request is considered completed with a failure outcome and the external
users is notified. Oracle Fusion Applications updates the Trading
Community Model tables with the rejected status

Remediation Task Assignments

The SOD remediation tasks are assigned based on the
role being requested.

If the role requested is Chief Financial
Officer, the SOD remediation task is assigned to the IT Security Manager
role.

If the SOD violation results from
a policy where the SOD control tag is the Information Technology Management
business process and the control priority is 1, the SOD remediation
task is assigned to Application Administrator role.

In all other scenarios, the SOD remediation
task is assigned to the Controller role.

For more information about configuring audit policies,
see the Oracle Fusion Applications Administrator's Guide.