- May 17, 2017
- Posted by: selva
- Category: GRC Software, SAP Access Control, SAP Audit Management
SAP Access Control in General
Access Control in SAP is looking at access within a user or a Role to figure out if the user can perform transaction within the SAP System to harm the system or defraud the company. Since access is the first entry point into the system most of the auditing firms tend to focus on this area to see if the users are restricted properly.
Quickly Auditing your SAP System:
Generally they run a query using SUIM and see how many people can do sensitive transactions in Security like SU10 or PFCG, Basis like SM59, STMS, and Finance like F110 etc. This will give a good sense of the SAP Security Posture / Design in the SAP System.
Process for Securing your SAP System
Access control risk can be reviewed multiple ways in the SAP System. This could be securing the default password, properly configuring the system parameter or following best business practice when you are creating custom programs or custom tables
Different Type of Risks in SAP System
SAP SOD Risk: Users or roles having two conflicting transactions. This could be Maintain Customer billing document and post Journal entry.
Sensitive Risk: Having one powerful transaction this could be any mass change transaction which could destabilize the system
Object Level Risk is having a particular object like access to debug or basis object which can let you fire operating system commands from sap
Some of the Pain Points when implementing SAP Access Control Solution
Understanding the SAP GRC report:
One of the main pain point most of the customers are facing is understanding the risk report which comes out the system. The report could be 100 K lines or more and making the Business owner understand what needs to be done is a very difficult. They want a clear logic on why this issue is happening.
Option of Role Removal
One of quickest way to fix the SAP SOD violation is to remove the role from the user. But this not easy to do. There is always a push back from users saying they need the role. Then there is the approval process we have to go through to remove the role from user which is time consuming and cumbersome
SAP Transaction Removal:
Here is a bigger problem to handle. Most of the SAP SOD Issues could be resolved by removing the transactions from the role. But before removing the role a detailed analysis has to be performed to understand who all are having access to the particular transaction. Now you will to get approval from all the users / business owners for you to be able to remove the transaction. There is the issue of impact to the training and testing. So you have adjust the training and testing document to reflect the new role design
SAP Role Redesign:
This solution will cost the company time and money. This will involve starting the role design from scratch. This means you have to involve the functional Business and technical lead to get involved in the project. More over the training documentation and testing scripts have to be complexly re written
The Push Back from Business and Functional Leads:
Normally when you go tell process owners that they need to remove roles or access from users they really do not like this solution. They generally will resist any changes made to the access as it could potentially affect their support.
There is also some logic in their push back. Because SAP ECC is the transactional system and the company could solely rely on the SAP ECC system for their back end operation. They cannot lose their access and incur huge loss. Any CIO or CFO will not agree upon a plan unless it has good mitigation option
Look at process Control for SAP as a better option. With Process Controls you can clearly see all the fraud which is happening in the system and this could be the justification for access removal from the users. More over the Auditors only need to take actions on the fraud happening in the system not on fraud which could happen.