by Sükrü ilkel Birakoglu, Senior Director
Segregation of Duties (SoD) is an internal process which is designed to prevent error and fraud by ensuring that at least two individuals are responsible for the separate parts of any task.
SoD involves breaking down tasks that might reasonably be completed by a single individual into multiple tasks so that no one person is solely in control of a business-critical system. Payroll management, for example, is an administrative area in which both fraud and error are high risks. A common example of segregation of duties for payroll is to have one employee responsible for the accounting portion of the job and someone else responsible for signing the checks.
Although it improves security, breaking tasks down into separate components can negatively impact business efficiency and increase costs, complexity, and staffing requirements. For that reason, most organizations apply SoD to only the most vulnerable and the most mission-critical elements of the business.
Applying the right SoD in ERP Systems like SAP adds more to this complexity taking into consideration all the business-related tasks which can be executed within an SAP System. This necessitates continuous monitoring of SoD conflicts and execution of business processes related to these conflicts to prevent fraud in SAP Systems.
When SAP Systems are taken into consideration, an individual should not oversee more than one of these transaction components: Authorizing transactions, booking transactions, and handling the related assets. For example, a person who can approve purchase orders should not be responsible for processing payments.
To follow SoD principles in SAP Systems, you need to carry out 4 processes:
- SoD Design
- SoD Implementation
- SoD Assessment
- SoD Remediation
In SoD Design Process, companies should set up an organizational structure where the business roles of every employee type are outlined. These business roles (e.g. an account manager, buyer, seller) should consist of certain functions such as creating a vendor or customer master, creating a payment order, approving a payment order etc.
Each of these functions can be mapped to transactions, services, remote function calls or other system related actions and APIs in SAP Systems. For that reason, it is important to determine which actions belong to which functions and apply them using SAP technical roles in the system in a correct way. SoD Design is a long and complicated process which is open to errors due to complex nature of business processes run on SAP Systems.
In SoD Implementation Process, you map your business roles to technical roles in SAP Systems. Technical roles hold the transactions which can be executed in SAP Systems. You can than assign the technical roles to SAP Users who will execute the business transactions on SAP Systems.
SoD Assessment is the most complicated process even if the SoD Design and SoD Implementation phases are properly fulfilled. You need to monitor your SAP Systems to check if everybody follows these requirements during any change. This is where SoD Tools come into play.
SoD Tools check if users can execute critical transactions or their combinations in the existing organization structure since there is a risk of fraud. The word existing indicates that most companies don’t even have SoD Development and SoD Implementation steps in place.
SoD Tools can be quite handy when it comes to obtaining the list of users with access to critical default transactions, which exist almost everywhere (e.g. SU01 – user transaction, SE16 – table reading). This alone can save a lot of time and give a high-level understanding how bad our situation with the role management is. If we see many users in an SAP System who can run critical transactions e.g. SU01, SM59, SE16, there are multiple issues at the SoD Design stage regardless of company’s business processes.
On the second level, we can get a list of users with access to typical combinations of critical transactions such as creating payment orders and approving them. Business process level Assessment is also a quite complicated task in SAP Systems, a continuous monitoring and reporting solution must be in place here, like Logpoint BCS for SAP.
With our SoD Assessment and Monitoring Solution, it is possible to find out users who have been assigned conflicting roles, so to say, the SoD Authorization Problems. We can also detect actions in SAP Systems which can lead to SoD Conflicts.
On one the dashboards of our solution, we are showing SoD Conflict situations that can occur according to the current Roles Assignment in SAP System. The number of users having roles that lead to SoD Conflicts are also listed.
List of SoD Violations in an SAP System and List of Users with corresponding roles leading to SoD Violations
On other dashboards, we give more detailed information about real usage of roles which lead to SoD Conflicts are shown. For example, if a user who has created a purchase order and also changed the condition master data related to this purchase order, this action is being caught in real-time and displayed in our Logpoint SIEM.
List of actions leading to SoD Violations in an SAP System
In SoD Remediation Phase, you correct the SoD Conflicts in your SAP Systems based on your findings in SoD Assessment Phase. Logpoint BCS for SAP solutions provides you with a lot of information about SoD Conflicts in your SAP Systems and this information is used as input for the SoD Remediation Phase.
If you need more information about our BCS for SAP Security and Threat Detection Products, you can send an e-mail to my e-mail address: [email protected]
