Towards a Framework for Segregation of Duties

1. University of Waterloo Centre for Information Systems Assurance 5th Symposium on Information Systems Assurance Towards a Framework for Segregation of Duties Akhilesh Chandra, The University of Akron Megan Beard, Deloitte & Touche USA LLP Toronto, Canada: October 11-13, 2007

2. SOD is not a new concept • But few developments have made it necessary to revisit the concept…

3. SOD is a common element across • control frameworks (e.g., COSO, COBIT, ERM etc.), and • corporate governance (e.g., SOX) frameworks • Revisiting SOD stems also from the features of the current business model: • Integrated business processes, • Extended, collaborative supply chain

4. SOD as a preventive control mechanism is probably the most effective and economic alternative • Therefore, both theory and practice can benefit from models of effective SOD that companies can adapt to their control environment and business practices

5. To protect information resources, an effective SOD model should: • Balance security and availability needs • Lend to automation for: • Design and implementation • Verification and assurance • Quickly adapting to changes These features should help to achieve the three goals of security and control: confidentiality, integrity, and availability

6. SOD based on business roles users play in organizations provide a stable and effective means to achieve these goals.

7. Role based SO

8. Role based SOD • Access granted to information resources based on roles performed by users • Controls are tied and mapped to roles • A cross functional team evaluates existing roles and associated tasks to accommodate changes in business processes and practices

9. Steps… • Identify a set of tasks necessary to complete a business function. • Map tasks to the application system functionality. • Group tasks by business cycles. • Within each cycle, define roles by the necessary function and access for each information resource.

10. Business function is decomposed into series of interrelated tasks Business functions … Task1 Task2 Task3 Task4 Task5 Task6 Task7 Task8 Task9 Taskn Sequential process

11. Identify tasks that need to be segregated based on risk-vulnerability analysis SOD Evaluator

12. Tasks are grouped by business cycles Business functions … Task1 Task2 Task3 Task4 Task5 Task6 Task7 Task8 Task9 Taskn Revenue cycle Inventory cycle Financial cycle

13. Roles are defined within each cycle Financial cycle Task6 Task7 Task8 Task9 Role 1 Role 2

14. Illustration of role based SOD model – single application Roles Users assigned Business Cycles Revenue Cycle Expenditure Cycle Financial Cycle Production Cycle HR Cycle Application Systems R/3

15. Illustration of role based SOD model – multiple applications Roles Users assigned Business Cycles Revenue Cycle Expenditure Cycle Financial Cycle Production Cycle HR Cycle … Application Systems Legacy R/3 11i

16. Roles Roles Roles Inheritance Users assigned Roles Roles Roles Roles Role hierarchy Business Cycles Revenue Cycle Expenditure Cycle Financial Cycle Production Cycle HR Cycle … Application Systems Legacy R/3 11i

17. Some specific features • The model lends to automation. • Changes are made at the root level. • Hierarchical modeling of roles can allow inheritance of privileges based on business rules • Invariant to best-of-breed ERP business models

18. ‘x’ indicates segregation of duties conflicts. Adapted from ISACA Guidelines

19. Few examples

20. Expenditure cycle Related Accounts: Operating Expense, Payables, Accrued Expense, Prepaid Expense

21. Revenue Cycle Related Accounts: Sales, Receivables, Allowance for Doubtful Accounts

22. Fixed Assets Related Accounts :Property, Depreciation Expense

23. A Primary challenge… • is the time intensive nature of implementing role based access controls. • But this is the investment on preventive controls that is more cost effective than the alternative (corrective or detective)

24. Comparison with alternative models • Discretionary controls • On a need-to-know basis • Users can potentially transfer privileges to others • Enhanced risk when users have ability to set their own access privileges

25. Mandatory controls • Access based on distinct level of authorization • Control problems in security data with lower level classification • As security clearance broadens, users begin to gain access that may not correspond with their responsibilities

26. Role based • Role is a generic concept • More stable • Relatively invariant to frequent changes in business or systems

27. Implications • Reduced cost of regulatory compliance (e.g. section 404 of SOX) • Especially for SMEs that are relatively more burdened • Reduced cost of audit • Increased operational efficiency • Continuous monitoring (e.g., section 409 of SOX)