Segregation of Duties: Beyond Provisioning to Real-Time Access Management

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 today’s 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” • ISACA…”A 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 application’s detailed access architecture • Ex. Oracle’s 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 application’s detailed access architecture • Ex. Oracle’s 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 doesn’t mean a conflict won’t 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 What’s 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. Detection • Prevention • Process Controls • Access Monitoring (Emergency Access) • Transaction Analysis 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 they’re needed • Standard application security is not granular enough and doesn’t 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. Approve entries over threshold Flag pending reportable events Bad Debt Ledger Monitor all entries over time period  Reportable Event Risk OK 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. Operational Efficiency The Access Management Spectrum Transaction-level Prevention Access-level Prevention Transaction-level Detection Access-level Detection Conflict Matrix Exception- Based Reporting Responsibility Refactoring Simulation 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