Segregation of Duties:

1
Segregation of Duties Beyond Provisioning to
Real-Time Access Management
Mark Stebelton, CPA Sr. Product Manager January
17, 2007
Confidential Proprietary
2
Overview
The current notion of Segregation of Duties (SOD)
is insufficient to meet its original intent and
remain a viable option in todays environment of
more efficient and effective business process
requirements. In reality a more holistic
approach to address overall access management is
necessary. This holistic approach is also known
as corporate governance.
3
Agenda

• SOD Definition
• Access Control Lifecycle
• Detection
• Prevention
• SOD A Fallacy in Reality
• A Holistic Approach

4
Segregation of Duties
A significant compliance challenge for companies
large and small
5
Segregation of Duties

• Objective of SOD - help reduce to a reasonable
  level the risk that

• Material Misstatements occur in the Financial
  Statements and

6
Segregation of Duties

• Objective of SOD - help reduce to a reasonable
  level the risk that

• Fraudulent, Malicious or Erroneous Code or Data
  Changes are made in IT

The Cowboy Coder
7
Segregation of Duties

• Definition of SOD
• Wikipedia...is the concept of having more than
  one person required to complete a task
• ISACAA basic control that prevents or detects
  errors and irregularities by assigning
  responsibility for initiating transactions,
  recording transactions and custody of assets to
  separate individuals
• Note ISACA Information Systems Audit and
  Control Association

8
Segregation of Duties

• SOD Classifications (Audit Examination
  Categories)
• Authorization reviewing and approving
  transactions or operations
• Custody having access to or control over any
  physical asset such as cash, checks, equipment,
  supplies, or materials
• Record Keeping creating and maintaining records
  of revenues, expenditures, inventories, and
  personnel transactions
• Reconciliation verifying the processing or
  recording of transactions to ensure that all
  transactions are valid, properly authorized and
  properly recorded on a timely basis. This
  includes following up on any differences or
  discrepancies identified.

9
Segregation of Duties Challenges

• In an ideal system, no one individual has access
  to two or more critical phases of a given
  transaction.

• Initially the questions that are asked are
• How do I know what conflicts exist?
• How do I clean them up?
• How do I maintain the environment?

10
Segregation of Duties Challenges

• Manual methods are labor-intensive, incomplete
  and error-prone. (Read costly and risky)
• Automated methods have been limited
• Monitoring (aka Detective) Identify SoD
  violations after the fact and report on them.
• Remediation still required
• Provisioning (aka Preventive) Intercept the user
  provisioning process and disallow the user from
  having conflicting responsibilities.
• Complete SoD is impossible
• Application SoD is too high-level
  (breakdown by responsibility and function)

11
Access Control Lifecycle
Manage SOD Controls

• Define SOD conflict business rules
• Ex. Enter Receipt Function vs Sales Order
  Function

Conflict Analysis

• SOD analysis engine that understands
  applications detailed access architecture
• Ex. Oracles function level, exclusions

Detection
Remediation (Clean-up)

• Faster, easier remediation and analysis via
  pre-packaged reports and what-if simulation
• Ex. Conflict impact of removing a function from
  a menu

• Real-time enforcement of SOD controls during user
  provisioning
• Ex. Hold access requests until conflict approval
  requests are addressed

Prevention Provisioning
Prevention
Compensating Controls

• Flexibility to handle exceptions through
  compensating process and transaction analysis
  controls
• Ex. Reason codes, emergency access/auditing and
  form controls

12
Access Control Lifecycle

• Detection Attributes
• Occurs AFTER access has been allowed These are
  conflicts that currently exist
• Identification of conflicts based on defined
  business rules requiring approval action
• Cleanup managed based on organizational needs,
  compensating controls, etc.
• Compensating controls needed where conflicts are
  required
• Risk exists with pre-cleanup access

13
Access Control Lifecycle
Manage SOD Controls

• Define SOD conflict business rules
• Ex. Enter Receipt Function vs Sales Order
  Function

Conflict Analysis

• SOD analysis engine that understands
  applications detailed access architecture
• Ex. Oracles function level, exclusions

Detection
Remediation (Clean-up)

• Faster, easier remediation and analysis via
  pre-packaged reports and what-if simulation
• Ex. Conflict impact of removing a function from
  a menu

• Real-time enforcement of SOD controls during user
  provisioning
• Ex. Hold access requests until conflict approval
  requests are addressed

Prevention Provisioning
Prevention
Compensating Controls

• Flexibility to handle exceptions through
  compensating process and transaction analysis
  controls
• Ex. Reason codes, emergency access/auditing and
  form controls

14
Access Control Lifecycle

• Simplified Prevention Flow

15
Access Control Lifecycle

• Prevention Attributes
• Occurs PRIOR to access allowed. This doesnt
  mean a conflict wont be allowed.
• Real-time management of access
• Access requests compared to pre-established
  business rules and subject to approval
• Authorizations (Approvals/Rejections) managed
  based on organizational needs, compensating
  controls, etc.
• Least amount of risk

16
SOD A Fallacy in Reality

• Why is pure SOD a fallacy?

• Underlying attribute is RESTRICTION
• Separation of 4 classifications (Authorization,
  Custody, Recordkeeping and Reconciliation)
• Requirements are too EXPENSIVE
• Increased personnel requirements (and related
  costs)
• HR Hiring, training, etc.
• Operations Office space, parking, etc.
• IT User management, SOD analysis and Management
• Application is too INEFFICIENT
• Hand-off coordination
• Knowledge transfer

17
Interim Recap

• Objectives of SOD are VALID
• Current Approaches to SOD include detective and
  preventive measures
• These measures alone are NOT a viable, long-term
  solution

So Whats the Answer?
18
A Holistic Approach

• What is Application Governance?

Controlling what users can do
Managing how they do it
Reviewing what they have done
Access Controls
Process Controls
Monitor Controls
19
A Holistic Approach

• Application Governance Components

20
A Holistic Approach
Process/Change Controls

• What they do
• Enforce policies for interacting with forms,
  fields or configuration setups
• Disable or hide key data elements
• Restrict updates to specific values, formats or
  off-limits
• Identify and process exceptions
• Route for approval
• Require specific documentation or handling codes
• Why theyre needed
• Standard application security is not granular
  enough and doesnt consider the context of the
  transaction

21
A Holistic Approach

• Process control options
• Hide fields and buttons prevent updating
• Disable checkboxes, change field names, or change
  date formats
• Validate data and require consistency force data
  to upper case
• Require approval cycles based on conditions
  (e.g., a threshold is exceeded)
• Call out to a sub-application for special
  processing (e.g., generation of a unique ID)
• Examples
• Require approvals for Credit Memos over 5,000
• Prevent updating of Credit Limits for customers
  that are currently on a credit hold
• Restrict ability to change key setups and require
  change routing approvals

22
A Holistic Approach

• Access Monitoring (Emergency Access)
• Provision of access that is
• Allowed for support purposes
• Short-Term in nature (time based)
• One-time or recurring
• In possible conflict of SOD business rules
• At either the Application or Database level
• Mitigating Controls
• Approval requirements
• Audit capture of activities for review

23
A Holistic Approach

• Transaction Analysis
• Argument of True Risk
• Not that resources COULD commit fraud or errors
• But that resources DID commit fraud or errors
• Analysis based on defined variables
• Ex. Purchase invoices exist by same creator of
  supplier (SOD conflict)
• Ex. Invoice creator different from approver but
  combination exceeds statistical value (pattern
  analysis)
• Compensating control when SOD potential exists

24
Example Posting a Bad Debt
Require approval if near close
POST Bad-Debt Approval
Post
Financial Controller
Entry
Financial Supervisor
Enforce SOD
ENTER Bad-Debt Account
Post
Post
Entry
Financial Clerk
Only certain accounts
Limit on entry amount
25
The Access Management Spectrum
Transaction-level Prevention
Access-level Prevention
Transaction-level Detection
Access-level Detection
Conflict Matrix
Exception- Based Reporting
Simulation
Responsibility Refactoring
Embedded Access Controls
Workflow/ Approvals
Compensating Controls
Access
Policy
Assessment
Remediation
Real-time Prevention
Monitoring

Implementation Process
26
Summary

• SOD exists to reduce risk of material
  misstatements, fraud and error
• SOD in purest sense is not realistic
• Too restrictive
• Too expensive
• Too inefficient
• Best Approach is Holistic (Application
  Governance)
• Prevent current and future conflicts when
  possible
• Detect existing conflicts and analyze
  appropriateness
• Manage application activities with form, field
  and configuration controls
• Monitor Emergency Access
• Analyze transactions