Segregation of Duties in SAP

The purpose of SoD (Segregation of Duties) is to ensure that only persons deemed eligible can perform "sensitive" transactions; it is therefore necessary to break the process so that a user does not pose a risk of fraud.

A technical model for dealing with segregation of duties involves the use of the following two sets:

• The duties library, which are transaction families (business actions in SAP. For example: create a purchase requisition, make a change to the material data, etc..).
• The risk library, i.e. the conflicting duties between them

A DUTY (or function) represents a certain set of transactions that make up a part of a process. In other words, duty represents, as already mentioned, a certain business activity performed in SAP (creation of suppliers, issue of blocked invoices, creation of sales orders, etc.)

The risk library defines the process parts that conflict with each other. The following image shows an example of acquired process risks. In the case of SAP, in addition to the standard activities envisaged, all customer customizations must also be considered, i.e. all custom transactions that have an impact on processes declared as sod relevant.

We therefore see that in the Table Conflict List (Risks) we find the risk called RISK01 which consists of two parts of the acquisition process: PR Creation and PR Release.

These two duties in turn contain the set of activities (technical transactions in SAP) that allow you to carry out that certain functionality within the application. What are the terms used in the management of the Segregation of Duties?

• Ruleset or Matrix
  
  • Represents the set of risks or rules (in the case of SAP's SAP Governance Risk and Compliance, Access Control tool, the SoD matrix is called ruleset).
• Process
  • Identify a set of tasks SoD relevant
• Risk
  • It is a set consisting of pairs or more of conflicting functions
• Function/duties
  • Represents a set of tasks that form a business process
• Action/Permission
  • They are the technical detail of the activities (transactions) and authorization objects used in sap environment to be able to carry out a business activity within the system
• Mitigation controls
  
  • Define a sequence of actions used to verify and control real-world evidence of risk

What are the management steps of the Segregation of Duties?

• The steps for managing the SoD are in fact the following:
  • Definition of the Risk matrix
  • Risk Analysis
  • Remediation activity
  • Mitigation activity
  • Definition of Continuous compliance procedures

Of fundamental importance is the process scooping phase. Right now, you need to identify the SoD-relevant processes involved, which are those that have a direct impact on your balance sheet.

For each process defined in the scooping phase, it is necessary to identify the risks of fraud within it.

One of the classic examples is as follows: a user cannot at the same time create or modify suppliers and start a payment to them. In this case, you could define a fictitious supplier by moving money illegally as a result.

It is important not to overdo it in the initial definition of risks within the various processes. Moreover, while it may seem premature, defining risk owners can be a strength for subsequent steps.

The construction of risks can also involve pairs (or ennuple) of conflicting functions or duty. Be careful, again, not to overdo it: better to use pairs or at most triplets of conflicting functions to describe a risk situation.

The concept of risk can be declined in several types:

• Business risk or SoD Risk: When you expect multiple process parties to merge to carry out fraud or damage
• Information Technology (IT) or Critical Actions (IT) Risk: When it expects that only a specific part of the process is sufficient to carry out a fraud or damage
• Technical risk or critical permission: When it provides that only a specific technical authorization is sufficient to carry out a fraud or damage After the matrix definition phase, it is necessary to analyze the system or systems involved.

Risk analysis tools

In the case of very small volumes (users and roles defined in the system), risk analysis could be carried out, albeit without a few difficulties, manually. In most situations, however, it is necessary to have an ad hoc instrument. What are the main tools?

• SAP Governance Risks and Compliance – Access Control (SAP)
• SAP Identity Access Governance
• SecurityWeaver
• Security Analyzer (Talia Security)
• IBM IGI (Identity Governance & Intelligence)

It is important to note that the choices made when defining the array will affect the outputs produced by the tools. It may happen that unwanted or unexpected results are caused by technical errors of the matrix. In this case, the array itself must be corrected. Some of the above tools have a starting "standard" matrix inside them, to be used as a reference. Customer customizations must be analyzed and integrated into the matrix if they have SoD impacts.

The result of SoD risk analysis can be of two types:

• No risk detected (a very rare situation)
• Risks to be managed (a most likely situation)

The subject analyzed must be both the user and the SAP technical role. In the event that there are risks to be managed, a remediation plan must be defined.

How to make remediation of risks?

This phase can be addressed in two steps:

• No business interaction
• With business interaction

Often, in the first case, the removal of everything that has never been used alone can reduce the number of risks that emerged during the analysis phase. While in the second case, where there is an interaction with the business normally carried out following the first step, action is taken by modifying organizational aspects.

Let us remember that changing the organizational aspects is never immediate and often difficult to achieve.

If it is not possible to proceed at a technical or organizational level, it is necessary to maintain the risk situation but to control it. This can be done by defining a control process.

How to manage the mitigation phase?

At the end of the 'cleaning' phase, there may remain cases of risk that cannot be eliminated, either by technicality or organizationally. This is the case, for example, with a small branch with a limited number of people operating on all processes.

In these cases, it is necessary to define a compensatory control or mitigation control which represents a test to be put in place to govern the occurrence of one or more risks. Controls can be mainly of two types:

• Preventive – That is made in advance
• Detective –That is, carried out after the event

Preventive checks are more difficult to carry out than detective controls which generally account for most of the compensatory controls adopted. In very complex contexts, naming compensatory controls can also be especially important. Often, corporate software already exists as a compensatory control repository.

If the analysis and remediation phases has not been carried out properly, the definition of compensatory controls may be too great an obstacle to overcome. It is important to stress that the definition of mitigations represents a cost in terms of monitoring and maintenance: they often have to be created from scratch and also concern customized processes. The latter are normally more complicated to manage.

At the end of the remediation and mitigation phase, any risk has been removed or placed under control. It is essential to remember that the management of the SoD does not end with the definition of compensatory controls.

For example, transactions are created or modified every day, if they are SoD relevant, it is important to manage them in the array. New users can join the staff or be removed or moved. Periodic re-validation of access and risks plays an important role.

It is therefore essential to establish a series of procedures to ensure that changes to the system comply with the requirements of the Segregation of Duties.

How can Aglea help you simplify the management of Segregation of Duties?

We have defined many segregations of duties matrices over the years. These can be used as a starting point to adapt them to business reality.

We can help you verify that the matrix conforms to business processes, limiting the number of false positives. Often the result of risk analysis, being very technical, is difficult to read. We are able to produce reports that allow us to understand who needs to do what and in what order, giving a clear and precise view of the result of risk analysis.

In the remediation phase it is often unclear where and how to start. Aglea has defined a remediation management model that can be applied to small companies (where segregation of duties is more complicated to manage), but also for very structured industrial groups.

The definition of compensatory controls is always a critical point of the project, which is often not addressed. The definition of mitigations involves the knowledge of business processes (not only standard but also custom) and the functional and technical implementation of mitigating control. For this reason, Aglea has defined a library of compensatory controls to be adapted to the reality of customers, without having to start from a blank sheet.