(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