Transport GRC Risk Library or Upload - Resolving the dilema
Access Risk Analysis Process Overview:
- The fundamental principle of SoD is that the authority to initiate, approve, and review activities is not held by the same individual.
- By performing Access risk analysis, Organisation can detect SoD violations or performing Risk simulation organization can prevent probable SOD violations
- Organisation can use results of Access risk analysis to either remove the conflicting access or apply a control that mitigates the risk when the conflicting access cannot be removed.
- Typically Organisation may have hundreds of business function combinations that can be categorized as access risks.
Risk Library Overview
- Risk Library contains following things.
- Rule Set
- Access Risk
- Functions
- Rule Set is an identifier to group together Access Risks and Functions. SAP Provides default rule set “Global”.
- Access risk defines which function is conflicts with which function. For example, Approve Purchase and Post Goods Receipt are conflicting functions. So we can create Risk 1 by adding these 2 functions. Access Risk also contains other details like Business Process, Risk Type etc.
- Function groups together similar transactions. For example, in Function “Approve Purchase order” can contain PO approval transactions like ME28, ME29, ME29N etc.
Risk Library Maintenance
- Risk library maintenance includes any of the following activities performed in Rule Set, Access Risk, and Function.
- Create
- Change
- Delete
- For example, New Rule set, New function, Change in Access Risk, Deletion of Access Risk etc.
Process to be followed for changes
- As far as possible, we need to avoid Deletion. Reasons are explained in later part of this document.
- Instead of Deletion, one can change the status of the Object from Active to Inactive
For example, Inactivate Access Risk, Inactivate Function, Inactivate Individual Transactions in Functions, Inactivate Individual Authorisation Objects in Function etc.
- For every change, supporting documents must be retained.
- Testing should be performed to ensure that changes are working as expected.
For example, if we create new risk then we need to test whether;
- We can get risk analysis result for the same etc.
- If we Inactivate any object then check whether its appearing in Risk analysis result.
- GRC can provide change history for the risk library. So it can be reviewed together with Change management documents like Change approval, Testing results etc.
Deletion of Objects
- As far as possible, try to avoid Deletion of the risk library objects. We can use alternative approach of Inactivating the object
- Reason behind this is limitation in moving changes to QA and Production Systems. When we move or transport the changes then deleted object in source system are not deleted in Target system.
- 1. For example, If we delete 5 Access risks out of 50 risks in Development system then transport request once imported into QA system will not remove deleted 5 Access risks from QA / Production system.
- In case of deletion, SAP recommends first to delete all objects in Target system and then transport changes to Transport system. If we continue above example then we need to first delete all 50 risks from QA and Production system and then move 45 risks from Development to QA / Production.
- However, deletion of all objects from QA and Production system and moving objects from Development system to production system will require significant testing in QA and Production.
- It will also require system downtime as post transport we need to complete rule generation in target system. Rule generation takes considerable time. So in production system, unless rules are generated, user may not able to approve request as correct Risk analysis will not be available.
Moving Changes to QA / Production System
- There are 2 ways for moving changes from Development system to QA / Production
- Transport
- Download Risk library files and Upload in Target system
- Transport
- Transaction GRAC_RULE_TRANSPORT can be used to initiate transport of the risk library
- SAP recommends, deletion of risk library from QA and Production before transporting risk library from Development. It will require to regenerate the rules in QA and Production
- It will also require to put extra efforts for testing in QA as we need to delete entire data first and then transport entire risk library.
- In Transport, all risk library data gets transported. So it may also include test data created in development system like test risks, test functions etc.
- So if we need to use Transport option and also we don’t want to transport test data then follow following steps;
- Download risk library from Production system
- Upload in Development system,
- Generate rules in Development system
- Make required changes in Risk Library
- Perform testing and document the testing
- Generate rules in Development system
- Transport to QA
- Generate rules in QA
- Perform testing and document the testing
- Transport to Production
- Download and Upload
- Transaction GRAC_DOWNLOAD_RULES can be used to download risk library
- It downloads 9 different text files for each connector group as follows
- Business Process
- Function
- Function Business Process
- Function Actions
- Function Permissions
- Rule Set
- Risk
- Risk Description
- Risk Rule Set Relationship
- Steps to be followed in case of limited changes
- Perform changes in Development NWBC frontend
- Keep track of Connector group, Risks, Functions which are need to be modified
- After making changes, generate specific Risks in development system
- Perform testing and document the testing
- Download risk library (9 files as mentioned above) in txt format
- Login to QA System
- Use transaction GRAC_UPLOAD_RULES to upload these Txt files
- Generate rule in QA
- Perform testing and document the testing
- Download risk library (9 files as mentioned above) in txt format
- Login to Production System
- Use transaction GRAC_UPLOAD_RULES to upload these Txt files
- Generate rule in Production
4. Steps to be followed in case of Many changes
- Download risk library (9 files as mentioned above) in txt format
- Open blank Excel file and change the format of entire file from General to Text
- Open the individual Txt file and copy paste the contents into Excel file
- It may be required to move data from single cell to different columns
- Perform changes in excel file
- After making changes, copy paste content to new txt files (again create 9 diff files per connector group)
- After making changes, generate rules in development system
- Perform testing and document the testing
- Download risk library (9 files as mentioned above) in txt format
- Login to QA System
- Use transaction GRAC_UPLOAD_RULES to upload these Txt files
- Generate rule in QA
- Perform testing and document the testing
- Download risk library (9 files as mentioned above) in txt format
- Login to Production System
- Use transaction GRAC_UPLOAD_RULES to upload these Txt files
- Generate rule in Production
5. Advantages of Download / Upload Option
- Main advantage is we can avoid of moving test data from Development system by removing test data from upload files.
- Rule Generation will require less time as we can track and generate specific risks where we did changes
- In case of Transport, we need to generate entire rules.
Summary
- Deletion of risk library objects should be well planned to ensure smooth Downtime in Production
- As far as possible deletion should be avoided
- Instead of Deletion, objects can be deactivated
- While moving changes from Development system to QA/ Prod, care should be taken to remove test objects (eg Risks, Functions etc created for testing) from the Upload file
- In case of Transport, all objects from Development will be moved to QA/Production. To avoid this, objects created for testing should be removed from Development system, Rules should be regenerated and then rules can be transported to QA/Production.
