During this article we are going to review some of the most important IT (Information Technology) critical actions that could be included within a Risk RuleSet to be used when running risk analysis in SAP© GRC ARA module (Access Risk Analysis).
Introduction
First of all, it is important to understand the main concepts that are the basis of the risk analysis procedure.
Function
A function is a combination of one or more transactions and/or just authorization objects. The functions identify actions or tasks that a user can perform in the system. Example: Run jobs under another user ID.
Risk
A risk is defined as a potential issue, which could cause error or irregularities within the system. Example: Execute All Transactions.
Furthermore, within the risks, we can also identify three different types:
Segregation of Duties
Identifies an access that, by itself, implies a risk, so these are risk defined by only one function. In the article, we will go deeper in this type of risk. Example: client and system change options administration.
Critical Action
Identifica un acceso que, por sí mismo, implica un riesgo, por lo que son riesgos definidos por una sola función. En el artículo, profundizaremos en este tipo de riesgo. Ejemplo: administración de las opciones de cambio del cliente y del sistema.
Critical Permission
Identifies an object or permission that, by itself, implies a risk. Example: debugging with replace.
Risk Rule (conflict)
Each risk rule defines the possible combinations of transactions and permissions (authorizations that the user has within the transaction to execute actions) that lead into a risk.
Rule Set
The ruleset integrates the combination of rules, risks and functions that will be evaluated in the risk analysis. A company could have more than one ruleset and each ruleset could have different combinations of rules, risks and functions.
IT Critical Actions
Once we had defined the main concepts involved in risk analysis, we will focus on the critical actions risks that are related to IT.
These risks, as explained before, are actions related with IT that, by itself, implies a risk.
Besides, in this article we will bundle those actions in groups to make easier to understand the differences between them. The main groups that we have approached are as follows:
| ABAP | Actions related to ABAP development or ABAP analysis. |
| Authorizations | Critical actions related to user’s authorizations, including user administration, role maintenance or role assignation. |
| Jobs | In this group we can add any critical action involving the execution or administration of jobs in the system. |
| OS Commands | This group would be related to the execution or maintenance of OS Commands. |
| RFC | Includes actions related to RFC administration or the maintenance of RFC connections in the system. |
| Security Policies | Any action involving the modification or the assignation of security policies. |
| System Administration | Actions related to the administration of the system, including the modification of the system options or parameters. |
| Tables | Maintenance of all the tables in the system using different methods to achieve it. |
| Transports | The last group to consider would be related to transports, including actions that involve import transports or the maintenance of those transports. |
In addition, there are other IT critical actions considered too specific to associate it with a group, such as Idoc Processing, the direct Execution of Programs in the system or the Maintenance of SAP© Queries in Production.
To continue, in this article we are going to focus on the IT Critical Actions involving the authorization object S_USER_GRP (User Master Maintenance: User Groups), as this is an object very important regarding the security of user´s authorizations and is the key in some of the risks that we are reviewing. These kinds of risks would be included in the group Authorizations that we mentioned before.
It is important for the understanding of the risks and its implications to get deeper into the authorization object S_USER_GROUP. As an introduction, the object is included in the class Basis: Administration and has two authorization fields that must be considered when developing a role:
The first authorization field to analyze is the ACTVT (Activity). This field manage the different activities that a user with this object can perform, involving the user maintenance in the system. The main activities available in this field are the following:
- 01: Add or Create: provide the ability to create a new user.
- 02: Change: modify the authorizations or the master data of the users.
- 05: Lock: lock a user in the system so it cannot be used.
- 06: Delete: delete a user from the system.
There are other activities to keep in mind regarding this field, but this is not the topic of this article. Nevertheless, in the screenshot above there is a list of all of them.
On the other hand, the other authorization field to take into account is the CLASS (User Group in user master maintenance). This field provide a method to restrict the users that a user with this object assigned can act on them.
This object is very useful to restrict access to user master maintenance based on the user group that a user should be able to perform actions.
Due to the utility of this restriction, we must emphasize on the importance of maintain and define different user groups in the system based on their characteristics. One example of user group distribution would be to make a difference between:
- Internal users
- External users
In that example, with the combination of the definition of user groups and the authorization object S_USER_GRP we would be able to restrict the access to user master maintenance of some users to perform action involving internal user, for example.
To continue with the article, once we have introduced the authorization object S_USER_GRP, we will proceed to explain the relationship between this object and some of the main critical action risks in a system.
Password reset & lock/unlock users
The first critical action risk to analyze would be the access to reset passwords and lock or unlock users in the system.
This risk will be produced when a user has a combination of a transaction that allows the user maintenance, such as transactions SU01 (User Maintenance), SU10 (User Mass Maintenance) or EWZ5 (Lock Users) and has the authorization object S_USER_GRP with the activity 05 (Lock).
User administration
Other critical action to keep in mind related with the authorization object S_USER_GRP would be the User administration risk, which implies that a user has access to perform changes in the users of the systems and even delete or create new ones.
Regarding the structure of this risk, it will be produced when a user has a combination of a transaction that allows the user administration, such as transactions SU01 (User Maintenance), SU01_NAV (User maint. to include in navigation) or GCE1 (Maintain User) and has the authorization object S_USER_GRP with the activities 01 (Create), 02 (Change) or 06 (Delete).
In this case, a user with one of the transactions and the object S_USER_GRP with any of the activities described above would be enough to have the risk.
User mass maintenance
Finally, the last critical action that we are going to review in this article would be the user mass maintenance, which is like the one described in the last paragraph, but for mass changes in the users.
The authorization object in the combination would be the same, S_USER_GRP with activities 01, 02 or 06, but the transactions involved in this risk would be the ones that allows to massive changes in the user administration. Some examples of these transactions are SU10 (User Mass Maintenance) or SU12 (Mass Changes to User Master Records).
These changes are especially important to restrict, as a user can perform massive changes that could affect more than one user in the system, so the people that have this risk should be the minimum as possible.
Key Points
-
- A critical action risk identifies an access that, by itself, implies a risk, so these are risk defined by only one function.
- The critical actions related to IT can be divided into groups with similar characteristics.
- The main groups to keep in mind are ABAP, Authorizations, Jobs, OS Commands, RFC, Security Policies, System Administration, Tables and Transports.
- The authorization object S_USER_GRP (User Master Maintenance: User Groups), is related to some of the most important IT critical actions related with authorizations.
- S_USER_GRP object allows to restrict actions by User Group, which is very helpful to restrict access in the system.
- It is very important to maintain User Groups correctly in the system to allow this kind of restrictions.
- The main risks associated with object S_USER_GRP would be Password reset & Lock/Unlock Users, User administration and User mass maintenance.