(SOx) Governance, Risk and Compliance with CSI tooling

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. Use CSI tools to document all (SOx) governance principles on the fly, test and get insight in the status of the current access governance and remediate the risks.

 Get clean and compliant with documenting and testing

CSI Authorization Auditor comes with a pre-defined audit and segregation of duty ruleset with over 400 SoD conflicts. This rule set can be fully fine tuned to the organizations’ needs, like custom authorizations. The rule set can be centrally adjusted with all organizational values like company code, plants, sales organizations, et cetera.

 The organizations’ business control framework with all processes, sub processes, risks (incl. all risk information like risk indicators, descriptions, ..), control objectives, control measures with norms, SoD conflicts, et cetera is documented in CSI Authorization Auditor on the fly.

 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 (SoD) 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? Are the implemented compensating control measures taken care of? CSI Authorization Auditor gives the answer using a multi layered analysis.

 The customizing of the SAP system is checked automatically against the pre-defined control measure norms to speed up the testing process in CSI Authorization Auditor.

 All test results are stored in CSI Authorization Auditor, accompanied with traffic lights indicators to give insight in mitigated and remaining risks.

 When the insight in the risks is clear, it is time for the next step, mitigation and remediation. Mitigating critical access risks and SoD conflicts can be done via:

• Authorizations changes on role level
• Authorization changes on user level

 CSI Authorization Auditor gives insight how to mitigate the SoD conflicts based on the executed transaction information and the norm information that the business can maintain directly and by themselves.

Once the insight is there, it might be necessary to make changes in the current set up of the authorizations (roles, role assignments,…) to get solid access governance. This is fully supported by CSI Role Build & Manage with features like automatic role building and deriving of roles (using reverse engineering), consistency checks and pre SOD check of the roles. CSI Role Build & Manage speeds up the phase to get clean & compliant.

 Not all risks can be mitigated via authorization changes, some risks need to be mitigated by implementing compensating controls. The compensating controls are defined in CSI Authorization Auditor and will be part of the testing cycle. All test evidence for the compensating controls are stored in CSI Authorization Auditor.

 Stay clean and compliant

Once the access governance is clean and compliant the next step will be “stay clean & compliant”; keep compliant access governance using Automated Request Engine that provides functionality like pre SOD checking and workflow integration for all authorization and user requests.

 Granting users temporary broad access rights is handled and monitored with CSI Emergency request. This tool also has the unique functionality to get insight in the changes that were made for critical info types. This insight is required by law in countries like Germany.

 Prove you are complaint

Monitor and test the risks and controls and document all the evidence in CSI Authorization Auditor to prove you are compliant.  The organization’s business control framework is documented in one central place and includes all test evidence.

 The audit committee can use CSI Authorization Auditor stand alone with its own audit rule set to check the authorization structure independently.

 Changes to the rule set in CSI Authorization Auditor and roles in CSI Role Build & Manage are logged automatically.

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

SAP support packages keeping me busy

A patch is a code-correction for a specific version of an SAP product. Support Packages are a collection of one or more patches. We all have experienced the time and work that can come with implementing new SAP support packages. I would like to take the support packages that are related to transaction codes as an example.

It is possible that the implementation of a transaction code related support packages leads to changes in existing and creation of new transaction codes. 

If old transactions are removed from the SAP system and are replaced with new ones after you have implemented SAP support packages, it means that you have to make changes in the SAP security related items. Not only should the roles be changed, but you should also update your GRC rule set.

In my other Blog - who is doing what in the SAP systemhttp://www.csi-tools.com/metas-blog/who-is-doing-what-in-your-sap-system, you can read how you can analyze how you can get insight in the usage of the transaction codes in the SAP systems. Once this information is clear you can start by adjusting the roles that have the old transactions in them, and replace them with the new transaction codes. Sounds simple? Well, to be honest, it is simple.... even better... you can fully analyze the usage of transaction codes and roles and then automate the role updating and building task with CSI Role Build & Manage. Even if no changes to transaction codes is done it is still a good exercise to check if users are using the assigned transaction codes. If this is not the case, the  "need-to-know"and need-to have" principle can apply and the (critical) authorizations can be removed from the users. 

But how about updating the GRC rule set? If you focus on auditing on transaction code level first (and including the authorization objects with field values, off course). You can never be sure you a reporting and auditing the real risks. How do you know that your rule set contains all the correct and critical transaction codes. In this example, if the SAP support package makes changes to the transaction codes, you must make changes to the GRC rule set.

That's why I recommend to focus on the data elements, that is, the authorizations instead of the transaction codes. If you focus on the users having access to critical data elements it does not matter if the get this access via transaction code "A" or via transaction code "B" because they have access to the data, they just maybe cannot start it with the audited transaction code (and probably use another transaction code like a custom transaction code that is not being audited instead).

Using CSI tools you will get a clear insight in inconsistencies, not only in the roles or role assignments, but even in the GRC rule set. If a user is assigned to the data element (authorizations), but not to the transaction code, this can be an inconsistency in the role or the rule set.

If the user is assigned to the data element (authorizations) and transaction code, but is not using the transaction code, the access to the functionality can be removed from this user. (figure below)

So with CSI tools you will get clear insight in GRC rule, role and role assignment inconsistencies of your SAP systems and SAP support packages no longer keeps me busy :-)

Role building with (non) organizational values in SAP

All role administrators are familiar with the challenges that come with making a SAP role concept efficient and effective. Since organizations are always changing, the role concept must be easy to adjust to these changes as well. SAP has some features to help role building and maintenance like master – derived roles, single and composite roles.

Organizational elements can be used to restrict the functionality of a user to a specific organization.

Example use of organizational element: You have two plants in your organization, plant A and plant B. User1 needs access for goods receipt in plant A and create purchase orders in plant B. User2 needs access for goods receipt in plant B and create purchase orders in plant A. In this case you can define master roles for the two functionalities; goods receipt and create purchase orders. These two master roles can be derived for plant A and plant B. The derived roles have the same functionality as the master roles but are further restricted on the plant level; plant A or plant B. You will end up with 6 roles in total, two master roles and four derived roles.  These derived roles will be assigned to the users. User1 gets the role for goods receipt in plant A and create purchase order  in plant B while user2 gets the role for goods receipt in plant B and the role for create purchase orders in plant A.

Alternative you could have created these roles for plant A and plant B not via master- derived roles but manually. You would have four roles in total. But can you imagine the amount of work it will take if you have more than these two plants and these two roles to define?

Sometimes there are small differences in the roles when they are being used on different locations. For example different movement types are being used on different plant locations. When maintaining master – derived roles it is important that you maintain only the master role and do not make any changes into the derived roles directly, not only for consistency reasons. After changing the master (parent) role, the role changes will be inherited to the child roles automatically. Manual changes that where done in the child (derived) roles are gone when the master role changes are inherited to the derived ones.  

It is possible to promote authorization fields to organizational field (SAP note  323817 - PFCG_ORGFIELD_CREATE) . Almost all authorization fields can be promoted to become an organizational element. The two fields “activity” and “transaction code” cannot be promoted.

To solve issues when maintaining roles, promoting an authorization field to an organization fields seems to be a good solution, but you must be aware that promoting to an organization field is not always a good thing to do. Some authorization fields are used throughout the system and have different tasks here. If you promote the authorization field to organization field this leads to errors in the assignment of these authorizations.

Organization fields are not only useful for the master derived concept, using organizational elements in the role concept helps restricting access and preventing Segregation of Duty conflicts. During audits you should not only focus on the “what”, but also focus on the “where”. A combination of functionality might look like a segregation of duty conflict, but if the user is allowed to do the one thing in organization A and the other thing in organization B, the conflict is no longer there.

That is why we want to fully use the “Where” aspect in defining, building, maintaining and auditing SAP security concepts. 

CSI tools has unique features to use all advantages of the Where aspect. During role building and role maintenance the organization values and non-organizational values are used while deriving roles. Furthermore, besides deriving the single roles, CSI tools makes it possible to derive the composite roles as well. These features  makes it possible to create a role concept fully automatically: All authorization field values, like organizational values as company code AND non organizational values like a release strategy and movement types for example, are document in one central codification sheet. After the codification sheet is complete and contains all correct values, the single roles and composite roles can be derived fully automatically- talking about time saving!

It is even possible to fill this codification sheet via reverse engineering. In this case, the application takes the values that are already defined in the SAP roles and fills the codification sheet with these values.

Not only building and maintaining the roles are important, how about auditing and analyzing them? Make sure that the roles are set up correctly and do not lead to unwanted access. Analyzing the Where aspect is fully covered by CSI tools. During night jobs all roles are analyzed to verify for example if a Belgian role gives only access to Belgian data, if a display role does not accidently give a small update access, if a European role give access to all European countries and not more! Especially for multinationals that have vertical integration, display access to only one operating company is crucial, since this ensures the “competition” with the group.

All this is integrated in the solutions of CSI tools; CSI Role Build & Manage makes it possible.

(C)Meta Hoetjes www.csi-tools.com
The podcast of this blog can be found here: http://mhoetjes.podomatic.com/entry/2015-03-25T03_02_57-07_00

  

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

Who is doing what in your SAP system?

People who are using a SAP system all known the term transaction code. SAP data is restricted using role based access controls. Users that get access to the SAP system via a Graphical User interface (I include portal-like functionality just to keep it simple) and the restriction of SAP table data for the users is managed by the assigned authorizations of this user.  If users want to have access to functionality in the SAP system, the transaction code is the front door to get access to this functionality.

STAD data

SAP systems keep track of the transaction codes that were started by the users. This data is stored in the so called STAD data. STAD data can be used for monitoring, analyzing, auditing and maintaining the security concept. When analyzing the access restrictions to SAP functionalities and Segregation of Duty conflicts, STAD data can be used to answer questions like:

·         Who has performed a certain critical functionality? And When?

·         If a user has a critical Segregation of Duties conflict, did he actually perform this conflict?

Also for maintaining and monitoring the security concept the STAD data can be very helpful. It will give the overview of the functionality (transaction codes) that a user did use. This information can be used doing Reverse Business Engineering to decide which functionality the user does and does not need.

SAP systems only stores a limited period of STAD data. The number of days/weeks/months that the data is stored can be managed in the SAP system itself. The larger the period of the STAD data is defined, the more storing capacity the server needs. To downsize this capacity it is possible to make regular downloads of the STAD data and store this somewhere else. If this download is extended to the same database every time, you can have a large period of STAD data which is very valuable information.

Example of download STAD data

STAD data can be extracted from the SAP server(s) using the CSI Xtractor for example. This tool uses a Remote Function Call connection from the computer to the SAP server and the user logs on with his own SAP logon credentials (figure 1).

Figure 1 – Logon with user-id and password to make RFC connection to SAP system

After selecting the period, the tool makes the downloads and you have a STAD database with all the STAD data from the SAP system (in this example I have created the database in Microsoft Access).

Figure 2  - example of used transactions per user

Figure 3 – Example of transactions being used

This downloaded STAD data can be used by own reports/analysis. It is also possible to included this database and data in detailed SAP security analyse tools like CSI Authorization Auditor to analyze which transactions in a certain role were used by the user (figure 4) and of SOD conflicts were executed by the user (figure 5)

Figure 4 – Example of transactions being used in CSI Authorization Auditor

Figure 5 – Example of SOD conflict with Executed (STAD) information
(C) Meta Hoetjes 2014 
CSI Authorization Auditor and CSI Role Build and Manage are registered trademarks by CSI Tools bvba
www.csi-tools.com