CSI Authorization Auditor instead of manual control

Due to pressure of local regulatory compliance issues and/or corporate governance demands there is a growing awareness of Governance Risk and Compliance among executive management. But what do we need to do to get (and stay) in control?

1.           What do we need to do to get in control?

First, get insight in the status of the current access governance: “Who can access which data and did they execute it? Who has broad access through different stages of the process and therefore segregation of duty conflicts and did they execute all activities within the conflict? Are all the backdoors secured? Are there inconsistencies in roles, user role assignments or in the rule set?” The questions are clear, but how to get to the answers?

1.1    Define overview and rule set with functionality and SOD conflicts that are business critical

First you have to define a company specific overview of all the functionality and Segregation of Duty (SoD) conflicts that are business critical. Once this overview is there, it must be translated into SAP technical authorizations. SAP authorization knowledge is needed for this translation and it will take many man hours to search and find the correct authorizations and transactions.

How CSI Authorization Auditor® 2014 can help in this step.

CSI Authorization Auditor® 2014 comes with a pre-defined rule set containing over 400 SOD conflicts and the critical functionality are already translated into authorization values and transactions (queries). This rule set is a real time saver. Instead of defining SOD conflicts from scratch, use the predefined SOD conflicts and decide which conflicts are critical for the organization.

1.2    Analyze the authorization concept

The bad news about analyzing the SAP authorization concept is that SAP does not support this process in their standard SAP system with user friendly reports or tools. The authorization data is stored in tables in the SAP database. Analyzing them manually is not recommended. It is a manual (returning) job, needs to be done in the correct way and is very time consuming. Problems with manual analyzing are:

·         Mistakes are very easy to make because of the numerous reports that needs to run with the correct credentials. If a mistake is made unnoticed people are looking at incorrect data that leads to incorrect actions.

·         Extracting the data is very difficult and can result in SAP system overloading and errors.

·         Only a limited scope can be taken into account because analyzing all the company critical functionality and SOD data just takes too much time.

·         SAP authorizations or even the rule set may change regular; therefore the check needs to be done recurring.

·         Not all aspects of access governance can be taken into account. SAP systems have many backdoors that lead to critical data. With manual analyzing these backdoors cannot be taken into account.

·         Company specific organizational levels are very difficult to include and maintain in the analysis.

·         Comparing results over periods is a separate activity that needs to be done as well.

·         Once the results are reported, an additional manual analysis needs to be done if SoD conflicts and access to access to critical functionality by users must be adjusted.

How CSI Authorization Auditor® 2014 can help in this step

Using CSI Authorization Auditor® 2014 will cut back the manual analyzing efforts that will take days (if not weeks) and reduce them to a couple of hours (and maybe less). CSI Authorization Auditor® 2014 helps getting insight in a fast and easy way of the current access governance. Who can access which data and did they execute it? Who has broad access through different stages of the process and therefore segregation of duty conflicts and did they execute all activities within the conflict? Are all the backdoors secured? Are there inconsistencies in roles, user role assignments or in the rule set? CSI Authorization Auditor® 2014 gives the answer using a multi layered analysis. The analysis will be done outside the SAP system and the data extraction can be scheduled. Therefore there will be no workload on the SAP system. Dashboards, reports and trending overview are standard available in CSI Authorization Auditor® 2014.

2.           What do we need to do to stay in control?

Once the access governance is clean and compliant the next step will be “stay clean & compliant”; Define the Business processes, risks and controls. Monitor the security concept and store the evidence. This can be done manually (for example in Excel), but once again will be very time consuming. Checks like the correct configuration table values need to be checked in the SAP system manually and evidence needs to be stored.

How CSI Authorization Auditor® 2014 can help in this step

Define the Business processes, risks and controls on the fly. Monitor the security concept and store the evidence in CSI Authorization Auditor® 2014. Stay compliant with your clean security concept using CSI Authorization Auditor® 2014’s user request functionality with pre SOD checking for the authorization and user changes. Monitor the risks and controls and document all the evidence in CSI Authorization Auditor® 2014 to prove you are compliant.

The audit committee can use CSI Authorization Auditor® 2014 stand alone with their rule set to check the authorization structure independently. Changes to the rule set in CSI Authorization Auditor® 2014 are logged automatically.

 Advantages CSI tooling:

• CSI Authorization Auditor® 2014 covers all aspects of access governance
• The audit committee can use CSI Authorization Auditor® 2014 PC based. Only they have access to the audit rule set and perform independent audits.
• Documenting the security process can take a long time. CSI Authorization Auditor® 2014 can simultaneous implement and document the business process with risks and controls step by step. Add any information about the security process CSI Authorization Auditor® 2014 and make changes on the fly. Use CSI Authorization Auditor® 2014 to document the security process in a fast way.
• Fast implementation time
•  Clear overview of SOD conflicts and how to solve them, results are on different views expandable.
• A sequence of dialog boxes leads the user through a series of well-defined steps (wizard). Tasks that are infrequently performed are easier to perform using the wizard. CSI Authorization Auditor® 2014 supports reporting the right results in the fastest way. Because of the use of the new interface and wizards, users are guided through the application with additional information on the screen, this reduced training effort enormously.
• CSI Authorization Auditor® 2014 comes with a large number of useful reports and dashboards. Is the report or dashboard not fitting the business requirements? Customizing is also possible to create new ones. End-users can define their own grouping of all data shown on screen and every view can be exported to different formats like xlsx, xml, pdf and accdb.
• All audit reports have the full causing information available with insight how these access rights are assigned to users. On every level an indication is given whether or not the user needs the role based on transaction usage information.
• CSI Authorization Auditor® 2014 gives a clear overview about the usage of SAP licenses. Reduce expensive license costs and pay only for the licenses and authorizations that are really being used.
•  Messages can be distributed according the RASCI matrix. Implement the organizations’ responsibility assignment matrix to automate the security task messages. People are informed automatically when they need to perform a task in the security process.
• Work simultaneous with multiple users on the same data to see the results in a clear overview, no more manual report distribution.
•  CSI Authorization Auditor® 2014 uses two databases; an application database and an archive database. All original SAP data and all previously produced audit results are saved in the archive. Previous audit result are immediately available if needed, the current audit results can be compared in detail with previous audit results.
•  New reports and dashboards make it possible to compare the audit results over periods. See if the security concept is improving.
• Analyze the correctness of role assignments with the use of role information and statistical data from the SAP system. CSI Authorization Auditor® 2014 also gives a clear view if access rights are accumulating in the security concept. This information can be used to clean up the authorization concept to get compliant.
•  All analyses are done separately on authorization level and transaction code level including executed information. The differences between these results give authorization managers an immediate insight of inconsistencies in the SAP roles and/or audit rules and/or in the access governance process.
• Useful user information can now be found in CSI Authorization Auditor® 2014: which roles are assigned to the user, which transactions a user can (and did) execute (even if the transactions are already removed) and which authorizations are assigned to the user in his/her user buffer.
• CSI Authorization Auditor® 2014 logs all changes made to the rule sets.

(C) Meta Hoetjes 2014 

CSI Authorization Auditor and CSI Role Build and Manage are registered trademarks by CSI Tools bvba

www.csi-tools.com

Reverse Engineering for the SAP security concept

How content is the organization with the current set up of the roles in SAP? Are your users happy with the assigned authorizations? If they are, the auditor probably is not happy with the assigned authorizations to the roles and users…..

Maybe there are already plans to redesign the current authorization concept…. How easy would it be if you can redesign the authorization concept with reverse business engineering? Instead of thinking and designing which authorization should be included in which role from scratch, just have a look at the authorization the users have and analyze the functionality the users have been using (or wanted to use) based on the executed transactions and assign these needed authorizations to the roles.

Example:

User John Smits is assigned to the composite role for system administrator S99-XXXX_SYSTADM. This system administrator role has 13 single roles assigned. In this overview the assigned roles are showed whether or not the user is using transactions from these roles. If transactions are used via the role, the executed colomn has a checkmark and the role is executed by the user (Figure 1).

Figure 1 Role details of user John Smits

If you double click on the role, you get the role details like the transactions, authorizations, executed transactions, if the transaction is locked in the SAP system et cetera (figure 2).

Figure 2 Transaction details of role

Let’s go back to the user John Smits. John wants to have broader access rights and was temporary assigned to a broad access role to solve an issue. This temp role was removed from the user after he solved the issue. Now let us have a look at the transactions of the user (figure 3).

Figure 3 Total transaction of user John Smits with executed and missing information

The transactions in red are no longer assigned to the user (also checkmark in column Missing (3)). The transactions in black are still assigned to the user. The checkmark column executed (1) means the user has executed the transaction. The column Frequency (2) shows the number of times the user has executed the transaction.

With this information you can search the single roles that have the missing transactions and analyze if the user should be assigned to this single role(s). If you double click on the transaction, a new screen shows the information about the transaction and the roles that have the transaction assigned. For this example we want to add transaction MB03 so we double clicked on the transaction MB03. The transaction is assigned to 2 single roles Display Material Documents Inv – S99MXXXXMADID and Display Material Documents Purchasing – S99MXXXXMADPD (figure 4).

Figure 4 Detail information about transaction including roles that have transaction included

SOD simulation

For this example we want to add the single role S99MXXXXMADID to the composite role S99-XXXX_SYSTADM of the user. To keep a compliant security concept we use the SOD simulation functionality of the CSI Role Build & Manage (RBM) tool (figure 5).

Figure 5 SOD simulation for role requests

Running the SOD simulation gives the overview “before” and “after” adding the single role to the composite role. In this case, no new SOD conflicts will be created by adding the role (Figure 6)

Figure 6 Results of SOD simulation for role request

And the request can be send automatically via workflow and email to the approver. After the request is approved by (all) the approver(s), it is even possible to have the change implemented in SAP directly, no longer manual role changes need to be done in the SAP system

Use reverse Business engineering to redesign of the complete role concept

The above example is just one way to use reverse Business engineering to redesign the security concept for just one user. Off course this is also possible for a complete redesign process. Instead of looking at one user, you look at the total usage of transactions of all the users and assign these used transactions with the correct authorizations to roles. (Figure 7).

Figure 7 User vs (executed) transaction overview

And the functionality for reverse engineering goes even further. The used organizational levels can be read from the existing roles and documented in the central codification functionality of CSI RBM. Usaging of the deriving functionality of CSI RBM you can automatically derive all the roles, both single and composite for the new role concept for both organizational (like company codes) and non organizational (like movement types)values.

©

©

©

©

(C) Meta Hoetjes 2014 
CSI Authorization Auditor and CSI Role Build and Manage are registered trademarks by CSI Tools bvba
www.csi-tools.com 

How to perform critical authorizations and SoD checks in SAP systems

This blog describes how you can set up the Segregation of duties (SoD) analysis for the SAP security concept. I compare 2 methods, The first one is using the standard SAP report RSUSR008_009_NEW and the second one is using CSI Authorization Auditor 2014.

Method 1 Using Standard SAP report

It is possible to use the standard report RSUSR008_009_NEW to set up a basic SoD analysis in the SAP system (figure 1).

Figure 1: Report RSUSR008_009_NEW

With this report is it possible to get an overview of users/roles having access to critical authorizations and/or critical combinations (SoD conflicts). Before you can run the report, you need to define the rule set first. The rule set contains critical authorizations and critical combinations. The critical authorizations must be defined and after this is done, you can define the critical combinations. In this example I will create a simple rule set for the critical authorizations to maintain customer master data finance view. The transaction and corresponding authorizations are defined (figure 2).

Figure 2: Set up of critical authorizations in report RSUSR008_008_NEW

After the critical authorizations are defined, the report can be run and the results (users/roles having access to the defined critical authorizations) are shown on the screen. A drill down functionality to see how the user gets the access to the critical authorizations is unfortunately not possible (figure 3) and the information if the transaction was executed by the user is also missing.

Figure 3: Results of critical authorizations user level

The report shows the assignment of the critical authorizations and does not show you the SoD conflicts. To report the SOD conflicts, you have to define the critical authorizations first, followed by the critical combinations. A critical combination (SOD conflict) is one or more critical authorizations combined with AND logic (figure 4).

Figure 4: Definition of critical combinations in report RSUSR008_009_NEW

After the rule set with critical combinations is defined, the report runs and the users are shown. Once again, a detailed analysis how a user gets the authorizations is not possible with this report and the information if a user did really use the transactions of the SoD conflict is missing (figure 5). The Definition of SOD conflicts is only using AND logic.

Figure 5: Results of critical combinations user level

Is it a useful report?

If the rule set if defined correctly, the report will give the overview of users having access to critical authorizations. The critical authorizations can be defined with or without S_tcode value. However, there are many cons why you should not want to use this report:

• Creating the rule set for critical authorizations and/or critical combinations is very hard. If you want to extend the rule set with your organizational values it will become very hard to implement and can lead to thousands of rules. The rule set is local to each client so you have to define a rule set in every single client. The rule set can be transported, but the rule set you want to use in the development system will be a different one compared to the one in the production system. Therefore you should not use the transport option; it will overwrite your rule set.
• No pre-defined rule set can be used. You have to implement a rule set beginning from scratch.
• Defining the rule set will be more time consuming and cost more than buying existing external tooling.
• When you apply support packs you don’t get updates for the rule set.
• Running the report can take up a long time and is additional workload for the SAP server.
• Creating the rule set is very hard, but maintaining the rule set will even be a more complex task. Change management must be set up to the rule set maintenance and the authorizations to do this must be restricted to the authorized users.
• The results of the report are only useful for high level reporting. In order to analyze how a certain critical authorizations or combination can be removed from a user, drilling down will not give the needed information.
• Documenting remediation, exceptions and compensating controls to mitigate the risks are not possible.
• The report will detect the issues from existing users; it will not prevent unauthorized authorizations when assigning roles to users.
• Who is responsible for the rule set and who is authorized to make changes to it?
• SOD conflicts are only created with AND logic between critical authorizations.

 Method 2: Using external tooling: CSI Authorization Auditor

I will use CSI Authorization Auditor 2014  show how an external tool can be used for SoD checking. CSI Authorization Auditor comes with a pre-configured rule set with all critical authorizations and over 400 pre defined SOD conflicts. Therefore the definition of critical authorizations and SOD conflicts from scratch is not needed. This is a real time saver. The rule set can be adjusted to company values, like customized transactions, authorizations, organizational levels, locked transactions, deactivated authority checks et cetera.  The organizational values like company codes, sales organizations, plants et cetera can be easily added and used across the analysis. If you already have a pre defines rule set for the SOd conflict and critical combinations, this can  be imported into the tool as well.Changes to the rule set are logged and can be restricted for changing. Additional information regarding the critical authorizations like the risk, control objectives and suggested controls can be added to the rule set as well. THe SOd conflicts can be defined with various logics like AND, OR and even NOT logic.

Figure 6 is an example of a pre defined critical authorization query, containing the critical authorizations to maintain customer master data in the finance view. The query is defined with the transactions (in the tab transactions) and the authorization values (in the tab authorization values). You can also adjust the pre defined queries and create new ones if you would like.

Figure 6: Pre defined critical authorizations set up

Running the queries will show the users/ roles that have access to the defined critical authorizations. The result also gives more detailed information like how the users get access, via which profiles and/or roles. In the example picture below the yellow circles shows via which profiles/roles the transactions are assigned, the blue circles in figure shows via which profiles/roles the authorization values are assigned and if the user has executed the critical authorizations (red circles in figure 7). In this example the user not did execute (any of) the transactions for customer master data maintenance: XD01,XD02, XD99, FD02,FD05 or FD06.

Figure 7: Results critical authorizations with detailed information

To do the SoD analysis, a pre defined SOD rule set can be used or a new SOD rule set can be defined from scratch. Defining the SoD ruleset from scratch is very simple. Every critical authorization query is stored in a library and via drag and drop you can add queries to a SoD conflict. Additional information like the risk, recommendations, compensating controls, organizational levels that are applicable, et cetera can be added as well (figure 8).

Figure 8: Definition of SoD conflict in CSI Authorization Auditor

After the critical combinations are defined, the audit can be done. The report will show the users/roles having the SoD conflict together with very useful additional information; Is the conflict executed by the user, via which role(s), profiles does the user gets the SoD conflict, is the conflict in the role itself, et cetera.

Drill down detail reports (figure 9), high level reports, dashboards and trending reports are also possible to get a clear overview of the progress of clean up (getting and staying compliant) . Because the analysis is not done in the SAP system there is no additional workload for the SAP server.

Figure 9: Results of SoD conflict with detailed information

Conclusion

Defining the report RSUSR008_009_NEW will be a very time consuming and expensive job even if your SOD rule set is quite basic.  Running the standard SAP report will take quite some time and will be additional workload for the SAP server. In the end it will be cheaper to buy an existing Security concept analyzing tools that offer more value because of the analysis functionality to get in compliance. Therefore I recommend to use external tooling like CSI Authorization Auditor.

(C) Meta Hoetjes 2014 
CSI Authorization Auditor and CSI Role Build and Manage are registered trademarks by CSI Tools bvba
www.csi-tools.com