segregation of duties in sap @ isaca pune presentation on 18.4.2015
TRANSCRIPT
1
Segregation of Duties in ERP (With special reference to SAP)
ISACA Pune Chapter office Monthly Lecture Meeting – 18.4.2015
Views expressed over here is totally personal in nature
2
What we will discuss today
• SOD Definition• Why SOD Matters• Need for SOD conflict Review• Global Scenario• SOD Examples wrt. to special reference to Procure to Pay Process• Key Considerations• Key Aspects• Mitigation through Role Based Authorization and using of GRC 10 suite• Q&A
3
Segregation of Duties (SOD) Definition
Segregation of duties (SOD) provides the assurance that no
individual has the physical and system access, to control all
phases of a business process or transaction; from authorization
of custody to record keeping. Thus in a way, it advocates Maker
– Checker concept at various levels.
An individual should not have responsibility for more than one of these three transactions components: authorizing transactions (approval), recording transactions (accounting), and handling the related asset (custody).
For example, person who can authorize purchase orders (Purchasing) should not be capable of processing payments (Accounts Payable).
4
Why SOD Matters
Internal Controls and Compliance
Part of management process, to keep an entity on course, in achieving its control activities.
Provide reasonable assurance that entity objective’s are being met by:
Effectiveness and efficiency of operations
Reliability of financial reporting under SOX, Companies Act
Compliance with regulations like SOX , Companies Act, ISO 27001 etc.
5
What’s Driving the Need?
7%
18%
21%
21%
33%
0% 5% 10% 15% 20% 25% 30% 35%
Other
Reduction in Costs
Defendable Environment
Automation and Repeatability
Risk of Non-Compliance
Source: AMR Research
6
Top Ten IT Control Deficiencies*
1. Unidentified or unresolved Segregation of Duties
2. Inadequate access controls supporting financial Applications / Portal
3. Inadequate Database access controls supporting Financial Applications
4. Development staff can run business transactions in production
5. Large number of users with access to “super user” transactions
6. Former employees or consultants continue to have system access
7. Posting periods not restricted within GL application
8. Custom programs, tables and interfaces are not secured
9. Procedures for manual processes do not exist or are not followed
10. System documentation does not match actual process
* Source: Ken Vander Wal, Partner, National Quality Leader, E&YISACA Sarbanes Conference , 4/6/04
GLOBAL SCENARIO
7
SOX 404 Compliance Gaps Remain…
Formal Review and Approvals: 23%
Segregation of Duties: 19%
Lack of Process-related
Documentation34%
No gaps identified: 8%
Other 16%
Source: Jefferson Wells International & The Institute of Internal Auditors
GLOBAL SCENARIO
8
Segregation of Duties (SOD) Examples
Function 1 Function 2 Business Risk Enter PO Receive PO Prevent buying and receiving items for user's personal use
Define Supplier Pay Invoice Prevent a user from setting up and paying a fictitious vendor for personal gain
Enter AP Invoice PO Returns Prevent goods from being received, invoiced and then returned Fixed Asset Physical Inventory
Asset Retirement Assets could be misappropriated and then summarily written off
Enter SO Manage Price Lists
A user could manipulate prices for the benefit of a customer or themselves
Enter Customer Ship SO A user could enter and ship an order to themselves Enter Credit Limits Enter SO Manipulated credit policies could increase risk or benefit
customers Misc. Inventory Txn Inventory Counts Adjust inventory balances to meet count results
Inventory Transaction Ship SO Shipping users should not be able to move inventory
10
Key Considerations
• How to define SOD controls?
• How to deploy and enforce Controls?
• What mechanisms should be provided to the process owners for preventing SOD conflicts?
• How to clean up existing SOD conflicts?
11
SOD Control Definitions: Use a Framework!
COSO: Committee of Sponsoring Organizations. In 1985, the Treadway Commission, formed to study US financial reporting systems now released COSO 2013 framework
• SOX follows COSO framework for regulatory & risk management• Standardizes the definition of internal controls – Referenced in Section 404 • Provides a framework for risk management and regulatory compliance• Requires risk assessments, a control-based environment, control-based activities, information and
communication procedures, and a monitoring mechanism for the control environment• Effective Fraud Management mechanism and use of IT tools
COBIT: Developed by IT Governance Institute as a standard for good IT security and control practices that provides effective governance
• COBIT was issued by the IT Governance Institute and is increasingly internationally accepted as good practice for control over information, IT and related risks
• Contains framework for control and measurability of IT by providing tools to assess and measure the enterprise’s IT capability for the COBIT IT processes
• Advocates “Need To Know Need To Do” Principle to resolve SOD issues.
12
No individual or related individuals should have complete control over a major phase of a process.
Workflows proceed from one person to another so that, without duplication, the work of the second acts as a recorded verification of the propriety of work of the first.
The person authorizing the use of an asset should not be responsible for its custody or derive any real or conceived benefits from the use of the asset.
Record keeping and bookkeeping activities should be separated from handling and / or custody of assets.
The Key Aspects of SOD
14
1. Manual identification of conflicts for remediation.
2. Heavily reliant on System Admin group for changes going forward.
3. Not proactive process.
4. Violations during future IT Audits will be costly as you try to prove that conflicts didn’t have material impact on financial statements
5. Very manual.
Problems with this Manual Approach
15
MAIN OBJECTIVE IS TO ACHIEVE
SOD
AT INDIVIDUAL / SAP USER LEVEL
Take off to SAP Role Based Authorization
16
SOD - Ongoing Dilemma !!!!
Auditors
Management
Security & Controls Team
I need SAP_ALL
Why don’t you let me do my job?
I need XK01 now! ASAP!!!
Users
Violating so many controls? This is ugly …
Why can’t you ever get your
act together??DO YOU
WANT ME TO GO TO JAIL?
17
SOD Management Process through Administrative Way
Go by arithmetical formula considering following assumptions you are in SAP ERP and having EULA
SAP or ERP Licenses deployed =900 Educated End User = 1500Work Station = 1200
1. First action to bridge the gap between A and B. You can increase 300 work stations by deploying SAP . Then bridge the gap between B and C and also provide SAP licenses to additional 300 end users / workstations. By bridging the gap you are now getting additional 600 SAP users.
2. Get the benefit of this and distribute the roles or t-codes to entire 1500 SAP end users instead of earlier 900. Now check how much SOD conflicts you can be ruled out.
3. Thumb rule is more you get the actual SAP users on board, you can simply distribute the t-codes based job profile or even role assignment to reduce SOD conflict at maximum.
AA BB CC
18
SOD Management Process through Automation
Risk RecognitionRule Building and
ValidationAnalysis Remediation Mitigation
Continuous Compliance
Risk Recognition
• Identify or approve conflicts exceptions
• Classify Risk – High, Medium, Low
• Identify new risks and conditions for monitoring in the future
Rule Building and Validation
• Reference Best practice Rules for Your environment
• Validate rules
• Customize Rules & Test
• Verify against Test User / Role cases
Analysis
• Run Analytical
• Size cleanup efforts
• Analyze Roles
• Analyze Users
• Modify Rules based on analysis
• Set Alerts to distinguish executed risks
Remediation
• Determine alternatives for eliminating risks
• Present Analysis and select corrective actions
• Document approval of corrective actions
• Modify / create Roles or User Assignments
Mitigation
• Design alternative controls to mitigate risk
• Educate management on conflicts approval and monitoring
• Document a process for monitoring mitigation controls
• Implement controls
Continuous Compliance
• Communicate changes in Roles and user assignments
• Simulate changes to roles and users
• Implement Alerts to monitor for new selected risks and mitigating control testing
19
SOD Cleanup: Don’t Underestimate
• SOD Detection != SOD Resolution
• Manual cleanup is labor-intensive
• Consider simulation tools for responsibility and menu changes
• Mitigating/Compensating controls are generally preferable to 100%
disablement
• Synchronize changes to access with an ERP version upgrade if possible
20
Detection Tool GRC 10 Compliance Suite
• Automated SAP Security Audit and Segregation of Duties (SOD) Analysis product
• Real-time risk assessment solution• Simulation and remediation• Mitigation Controls• Embedded in SAP• Preventive as well as detective• Summary and drill-down reports
It is a Compliance Calibrator
22
ObjectiveObjective• Institutionalise role based authorization across all process and modules of SAP
Benefits out this project are two fold.Benefits out this project are two fold.
1. .
In terms of Productivity In terms of Controls
Once roles are created properly it is easier for Role owner and HOD to allot the roles to users based on job profile which will reduce TAT of whole process and bring customer delight
Avert risk stemming from excess authorizations due to existing profile copy
No need for filling technical details like org values and t-codes at user level which resulted in significant TAT time
Mitigate risk of Cross location and Cross module access
Elimination of high numbers of user based roles which is very difficult to maintain now
Mitigate risk emanating from SOD conflicts
One time activity and once roles are created it will be easier for BPO and TCS team to sustain current pressure and significant reduction in time
Streamlining and standardisation of the existing authorisation system to have better control
24
Strategy
1. Designing the authorisations will be based on the organisational internal structure and the business processes. It will be designed to achieve appropriate Segregation of Duties and better internal controls.
2. The methodology involves Role based authorisation which will list the activities to be performed by the users. These roles will have one common organisational level profile and one functional profile which will define the transactions for the role.
3. The role designing phase would require both, system administrators, functional consultants and the business users to ensure the user authorisations reflect the organisational needs.
25
User
Transaction Based Role Organizational Value Based Role
Transaction Based Role :Transaction Role will consist of only transactions and reports. SAP Display Transaction and Reports.
•SAP Display Transaction and Reports.•SAP Create, Change, Delete transactions.
Organization Value Based Role :It comprises of organizational values such as Company Code, Plant, Sales Organization, Purchasing Organization, Shipping Point, etc… as required.
Composite Role :Transaction and Organizational roles are grouped in Composite roles. Only composite roles will be assigned to users.Each Composite role contains the necessary authorizations needed to perform the designated transactions based on the need to do and need to know
Role Design
26
Roles and ResponsibilitiesFunctional Consultants
Redesigning the Business Process documents for access control matrix in consultation with the key users. Identification of the transaction codes and grouping of them as per the roles. Prepare questionnaire for the key users for access requirement.
Key Users Identify and Validate the business activity access required for the users depending upon their roles.
HOD (Authorized to authorize the access requirement of the users). Approval of the access required for the user.
Key Users and HOD’s contribution is mainly on providing Organizational Chart and Job Description (for every role).
Role Owner:1. Validate the ACM with proper txns codes with corresponding org values 2. User Assignment - Correct mapping of user with respective roles 3. Removing SOD if found at role level and users assignment level4. Taking justification and valid decision in allotting critical t-codes and mvt. types5. Giving the names of users and ids which are missed by project team based on his
understanding of user’s function irrespective of naming convention.
28
Key Challenges1. Building Roles w/o SOD even if not detected by Compliance Calibrator
2. Dealing with critical T codes
3. Dealing with 800+ customized Z programs which includes create / change t-codes
4. To build SOD rules for customized T codes wherever necessary
5. Dealing with SE16 table browser where access was not restricted to specific tables – so it necessary to build SE16N view roles based on specific table access
6. No SOD rule set defined for Critical Movement type or HR Info type level
7. Filling up of an ACM with accurate data:
Plant Code , Pur Org, Pur Doc Type, Mvt type, S-loc , Excise Grp, Excise Series ,Release Grp and Release Code etc
8. Removal of Generic business User IDs
9. Total support and patience at the time of Testing of Roles and after Go-Live
10. Creation on Firefighter ids and its usage modularity
11. Maintenance of roles after post migration stage
29
Possible Concerns related to SOD conflict resolution
Ways to resolve SOD conflicts through Roles Based Authorization
• Split the Roles and attach them with individual SAP transaction codes
•Remove authorization for SAP transaction codes that lead to SOD conflicts
Suppose Txn1(MI02) - Change Physical Inventory Document and Txn2 (MI04) -Enter Inventory Count with Document rest with one person. Then split the roles into 2 (R1 and R2) and attach Txn1 to R1 and Txn2 to R2
Above exercises result in
• Increase in Manpower
• Redefining roles and responsibilities which may lead to increase in manpower / training cost
30
Role Maintenance
• TML has identified around 250 Role Owners.
• Every Role has a Role owner.
• Any change in the role is approved and validated by the role owner.
• Standard FORMS have been developed to make any changes to the ROLE which should be Authorised by ROLE OWNER.
• Around 2500 roles have been created.
• All USERS under FI/SD & MM Modules are role based
Role Owners
31
Fire Fighters
• Fire Fighter tool of GRC 10 has been implemented to grant Authorisation access to the users in case of emergency.
• The Owner and the Controller for each Fire Fighter Id is configured in SAP• On the request from the USER, the owner of the Fire Fighter Assigns the Fire
Fighter to the user. The Fire Fighter Id has all the required TCODES to perform the activity
• A Log is maintained in the system and the owner and controller reviews and authorizes the log at the given frequency. The log gives all the details on usage of Fire Fighter i.e. The date, time, reasons, TCODES for which the Fire Fighter ID was used.
Role Maintenance
32
Risk Terminator
• Risk Terminator tool of GRC 10 has been implemented to validate granting of access to the users for Critical TCODES
• Around 180 Critical TCODES in Basis and 181 Critical TCODES in Business have been identified and updated in Risk Terminator. In addition to above we have 35 separate HR critical t-code maintained for SAP HR module.
• While granting access to the said TCODES, the Basis team takes an approval from Business Security and IT Security and Compliance Team.
Role Maintenance
33
Precautions
1. Don’t mix up display t-codes with create / change t-code within the role
2. Use proper naming convention for roles based on function
3. Avoid using * in org values in critical fields
4. Restrict the usage of critical t-code and movement types at super users level
5. Judicious use of Fire IDs and its review of log
6. Ongoing challenge is to maintain number of roles at optimal level - Use Rule Book for maintenance team for new role creation and amendment of existing roles
34
Summary
• Define granular, function-level conflicts using a conflict matrix
• Use Compliance Calibrator software ( GRC 10 Suite or Oracle’s ICM) to detect
SOD conflict
• Use controls automation software to deploy and enforce these controls
within your ERP
• Address the change management aspects of the solution
It is important to note that
Protection of unity in chain of command I.e there should not be too many checkers for one maker. The definition of role should be functional not
individual.
Removal of excess authorization should not lead to misuse of passwords. Increase of SAP users is key to success of optimum SOD
36
Jayjit's 22 years of professional journey covers IS auditing , SOX compliance and Management consulting. Considered to be a specialist in SOX Compliance function with deep understanding of Forensic and IS audit. He has an uncanny habit of blending controls to the best of business interest. He always look compliance and control as a driver of business and not the show stopper.
Jayjit is a prolific speaker and a thought leader on various international forum.
About the Presenter: Jayjit Biswas CA , CISA
@jayjitbiswas
https://www.linkedin.com/in/jayjitbiswas