SoD risk assessment has become an essential and fundamental analysis to identify security vulnerabilities in SAP, and reduce the risk of fraud for internal control
19/05/2022
SEPARATION OF DUTIES (SoD) : COMPLETE GUIDE
7 minutes read
With the digital transformation and the increasing number of innovations, companies must ensure that they maintain an ever higher level of security to avoid manual errors, fraud, or any hacking attempt.
This is all the more difficult as the company will use more and more SAP systems that are subject to specific monitoring and maintenance.
According to a study conducted by Euler Hermes, the European leader in fraud insurance, in 2021, two out of three companies will have suffered at least one fraud attempt last year.
This has a significant impact on the company’s cash flow, which must be protected against this phenomenon.
To reduce the risks, it is in the company’s interest to implement an SoD (Segregation of duties) policy. This means involving at least two people in the execution of a critical process, one checking what the other is doing (and vice versa).
This process is usually included in a global process named GRC – Governance, Risk & Compliance. In the SAP ecosystem, the GRC leader to cover this process is SAP GRC Access Control, and at some level SAP GRC Process Control.
Whether you’re familiar with this concept or not, we’re going to cover SoD from all angles so that this term no longer holds any secrets for you.
What Exactly is SoD?
Understanding SoD with Payroll Management
In order to better understand what exactly SoD is, we will take a concrete example. To do so, we will voluntarily choose a task that could present a risk: payroll management.
What are the Main Risks of this Task?
Data risk: a payslip involves an employee being paid. There is therefore access to all the sensitive data of the latter
Payment risk: a payment default can quickly embarrass a company and lead to significant financial penalties
The risk related to fictitious jobs: it is a question of creating a phantom employee who has a contract with the company and who will therefore receive a salary and will even be able to claim unemployment benefits after a real/false dismissal.
How to Apply the Separation of Duties in this Specific Example?
Quite frequently, there will be two people: one employee responsible for the accounting part and another who will sign the checks, or approve the wire transfers or payments.
Most of the time, a company will set up an SoD for the most vulnerable and critical tasks. For this purpose, the most suitable method at the moment is the RBAC method (Role-Based Access Control).
This role-based access control allows the management of the user access of an entire company. Sometimes, this process is summarized by a process called User Management or more often Compliance Identity Management.
Schematically, it could be represented with an inverted pyramid where we find :
- The company
- The subsidiary
- The department
- The position
- The employee
For each step, access rights are assigned. Thus, some access rights will concern all the companies while others concern only one department for example. This allows you to have an overview of the access rights and to ensure that there are no errors.
Which Tasks aren't Incompatible?
A task, whatever it is, can be broken down into several stages:
- The authorizations that will give access and involve the company
- Business Data storage in multiple SAP tables
- The recording of accounting years, financial reports
- The control, that is to say, the different audits that are done within the company
- The rule is very simple and means that no one in the company has to carry out all of the above steps in the performance of a task.
The RBAC Standard
The principle of SoD is based on the Role-Based Access Control model, which enables the management of authorizations. It is built around two features:
- Set up an authorization-based model for all individual resources, applications, etc. In the SAP environment, it is mainly around the different SAP roles (Business Roles, Composite roles, or single roles), with a main organizational concept called Master & Derived roles for each location scope and perimeter (Region, Country, Business Unit, or Brand. and Zone location).
- Manage its model using different roles and therefore different access rights
RBAC roles act as intermediaries between users and authorizations. To better understand this principle, we will go back over each term.
Authorization is the right to perform one or more actions within an item in SAP solutions, principally used as “Transactions, Fiori tiles, webdynpro applications” or any other way of executing a business task.
The usage of these tasks is particularly based on the SAP application we have rolled out in our organization, each solution has its own way of triggering the tasks.
The new SAP solution as S/4 Hana will mainly be based on Fiori tiles, and technical authorization, while other SAP cloud applications will be more permission or action based as SuccessFactors or SAC (SAP Analytical Cloud).
The previous version of SAP was ERP ECC (with SRM, CRM, SCM, and MDG) all there own way of building their access rights based on Business Partn,ers, Portal access rights, or very specific restrictions.
The role is a set of authorizations. The role will therefore be assigned to a user who will receive certain authorizations corresponding to this one. Most of the time, the role will have the same name as the business user (“GL Manager”, ” Supplier Accountant”, “Procurement Agent, …
What Does the Implementation of an SoD Consist of?
We will analyze the different steps to put in place to have an efficient and effective SoD system.
Define your Segregation of Duties Matrix
The first essential thing to do is to identify all the stakeholders who will or will not be involved in the SoD process on a daily.
We will therefore have a list of all the company’s different job profiles with their characteristics (department, position, etc.) as well as those who will be directly involved in the segregation of duties (Business Process Owners, IT department, internal controller, etc.).
Then, it is necessary to make a list of all the tasks that will be performed by the different employees. But the most important thing is to link them in order to highlight the existing risks and incompatibilities.
For example, task A could be considered without risk. But associated with task B, the risk must be classified with a severity (Low, Medium, High or Critical).
Task 1: Raise a Purchase order + Task 2: Approve a Purchase order = High risk
Task 1 : Raise Purchase Order + Task 3: Receive Supplier Invoices = Low Risk
Task 4 : Change Vendor Bank Details + Task 5 : Validate Payment Vendors = Critical Risk
All these tasks are in SAP and categorized as SAP GRC Access Control functions.
Audit Organizational Risk
This internal task is essential and should lead to the creation of a list of the company’s risks. Risk mapping (also called heatmap) is one of the most used and effective tools.
On the ordinate, we find the severity of the risks, which we scale from minor to catastrophic, while on the abscissa we have the probability.
Although many companies have specialized internal auditors, it is important to involve people at all levels of the company who will probably have very different views.
Finally, it is not a matter of simply naming the risks: they must be clearly understood. Indeed, highlighting a risk without any action behind it will not be of any use. It will be necessary to think about the causes of the risk as well as the consequences if it happens.
This methodology must be applied to all the SAP landscapes and architectures, the remediation process has to be clear for every key player in the risk management process. Each stakeholder must be able to easily identify the SoD risk, apprehend it, and take a valuable decision to address the risk.
The target is to “Get clean” at the first stage of the remediation steps, and “Stay clean” to avoid any risk issues across the entire organization.
Determine the Different Roles
Only by knowing the risks can the different roles be determined. It is, therefore, necessary to identify the company’s stakeholders, list their functions and their needs in order suggest job profiles with SoD-free risks, and be compliant with the SoD principle.
It should be noted that a balance between efficiency and cost must always be maintained. Indeed, a company may tend to overprotect itself and give only a few authorizations to its roles and therefore constrain users from doing their daily job correctly.
However, users must be able to perform all their tasks without being restricted by a lack of organization. Today, some solutions allow you to give exceptional access rights to certain roles/users for a limited time through PAM (Privileged Access Management) tools like SAP GRC EAM or FireFighter.
But as the name implies, this must be exceptional and a user who constantly asks for SAP authorizations that he does not have to do his job would lose productivity.
Automate and Analyze these Operations to ensure Maintenance
The SoD is sustainable over time and can evolve. It is therefore necessary to set up a continuous control of the model to stay clean. This will be done by automating the controls and setting up workflows.
This may seem logical, but a study conducted in 2017 by KPMG shows that 77% of all respondents said that less than 10% of their controls are automated.
The dashboard will be the most used tool to highlight ineffective controls or even failing entities within your organization. Note that automation can also pave the way for the robotization of controls.
SoD Conflicts, SoD Violations, and Critical Access
An SoD conflict can materialize in several ways. The most common is a situation where an employee will possess more access than their job or position requires.
As a reminder, the company must follow the Principle of Least Privilege (PLP), which consists of giving the SAP end-user access to only the amount of information and SAP roles needed to perform his or her various tasks, no more and no less.
The second type of possible conflict is a conflict within a function or position. Indeed, as we have already said, certain tasks that are incompatible and that the same person should not perform in order to reduce the risks of fraud within the SAP landscape.
It is necessary to clarify that a conflict is theoretical. It is more about anticipation than reaction. Most of the time, conflicts are detected but not exploited. It is therefore necessary to set up a thorough analysis of the SAP transactions carried out to rule out the risk of fraud.
Indeed, we can also talk about critical access within SAP. Here, it is the action performed that is sensitive and that constitutes a risk, regardless of the person concerned or the access they already have.
For example, access to expense reports or pay slips can be considered critical because it involves direct access to the sensitive data of other employees in the company.
A famous example to illustrate this is that of Jérôme Kerviel, the former trader of the Société Générale. According to the latter, he fraudulently entered data into an automated system in order to take massive positions (to the tune of about 50 billion euros).
For its part, Société Générale was also condemned for ” a serious deficiency of the internal system“. Without taking sides, we can consider the situation as follows:
- The role that Jérome Kerviel had had two authorizations that caused a conflict: the fact of being able to introduce data into an automated system and of being able to take a position.
- This conflict should have been highlighted. According to the SoD principle, these two actions should have been dissociated into two distinct roles.
- The fraudulent action performed turned this conflict into a violation: we went from theory to practice.
What are the Different types of SoD?
In addition to the task separation we have been discussing since the beginning of this article, we can distinguish three other types of task separation that can be applied depending on the type of business, its complexity, and size:
Privilege separation: this technique involves limiting the privileges granted to a user so that they can only access what is strictly necessary for their work. For example, a system administrator should not have access to sensitive company data except when strictly necessary. Privilege separation can help limit the risks of abuse of power and data compromise
Environment separation: this method involves separating development, testing, and production environments to limit the risks of bugs or vulnerabilities spreading from one environment to another. Test environments should not be used for production activities, and production environments should not be used for development or testing.
Task rotation: This technique involves rotating tasks among different people to prevent one person from being in charge of a given task for too long and becoming too familiar with the process. This can reduce the risks of error or fraud and can also help improve collaboration and communication among team members.
Why is SoD so Important?
As we have seen since the beginning of this article, SoD is now a must for all companies. It allows the improvement of compliance, the limitation of risks, and above all an increase of trust in the company, and SAP access rights.
Various laws such as the Sarbanes-Oxley Act impose more and more financial transparency and particular attention to data processing. But it’s not just a matter of evading a law to avoid sanctions, it’s really about improving the productivity of the company.
It would be utopian to think that the company of the future will be free of conflicts and SoD violations. Nevertheless, it does everything possible to identify conflicts and resolve them in order to anticipate any violation.
This proactive work is not the result of one-off actions but of regular automated monitoring that will lead to better productivity for all.
SAP GRC Access Control, leader des Solutions SoD
GRC Access Control is an application that allows you to manage the various accesses to resources and applications in your SAP or non-SAP environment. With a real-time overview of SoD risks and conflicts, you can detect possible fraud and reduce the cost and time of compliance.
Our GRC solution consists of several ads on :
- Access Risk Analysis (ARA): provides the ability to analyze risks, and simulate access to address risk occurrences based on the analysis results. We have also developed other applications to bring more functionality to the standard tool
- Access Request Management (ARM): Allows you to create and validate access requests for SAP systems and authorizations to perform tasks. You can create access requests for yourself, another user or multiple users more easily and quickly via our VASPP applications
- Emergency Access Management (EAM): Enables the effective management of emergency access management. Those responsible for compliance can perform periodic usage audits to monitor the proper use of privileged access.
VASPP also has an add-on to enhance this process with self-service access and a web application format
- Business Role Management (BRM): this allows you to customize the role management process to match your requirements. This feature also introduces the notion of a Business Role, providing greater flexibility in terms of access management
- User Access Review (UAR): provides the ability to initiate a periodic access review process that is defined, and deploy throughout the organization according to your guidelines. We also have a complementary offering with our FIORI applications to address this need for end users
VASPP Dashboard for SAP GRC Access Control
To meet the needs of many SAP GRC Access Control users, we provide a suite of dashboards for monitoring and managing risk within your organization.
Get a quick overview of all your internal control processes and SAP accesses with our Compliance Analytics solution:
- Control your risks and stay compliant with Risk Analytics
- Improve your identity and access management with Request Compliance
- Secure your privileged access with Emergency Insight
Discovers more VASPP articles
What is an SoD Report ?
The SoD report is a key element in the internal security audit of companies. It allows you to update, ensure and improve your Segregation of
How to Manage Risks in Companies?
Risk management requires a great deal of work in identifying and evaluating risks. All companies are confronted with risks of all types, it is important
What is GRC (Governance, Risks and Compliance
All the challenges of risk management, compliance and governance in businesses. Our article presents the tools and best practices for implementing an effective GRC strategy.
